Ground Truth Odometry&IMU vs. Generic Odometry&IMU

[TaoChenOSU]

I walked across this problem with the odometry and IMU in the simulation.

There is one generic odometry sensor in the file mav_generic_odometry_sensor.gazebo. And then there is another one in the crazyflie2_base.xacro, which is the ground truth odometry sensor. There are also 2 IMU sensors. One is the MPU-9250 IMU and the other one is the ground truth IMU.

The problem I had was that when I disabled the ground truth sensor, the vehicle became unstable. However, I couldn't find anywhere in the code where the ground truth topics were subscribed.

The strange thing is when I changed the ground truth topics to arbitrary names, the vehicle remained stable. But as long as I remove the sensors, it became unstable.

Also, when I removed the generic odometry sensor, and subscribe to the ground truth topics directly instead of 'odometry_sensor1', the vehicle became unstable as well.

Somehow the genraic sensors and the ground truth sensors are interconnected and I couldn't find the connection.

I notice that the childframes of the two odometry sensors are different.

I am wondering if I missed something that's going on internally using the ground truth odometry and IMU. Thanks!

[welcome]

Thanks for opening your first issue here! Make sure that no other issues on the same topic have already been opened!

[gsilano]

Hi @TaoChenOSU, thank you for opening up an issue about using CrazyS. I hope it can also be useful for other CrazyS users. First of all, I suggest you visit the publications section on CrazyS Wiki. Perhaps, something that it is not clear enough by inspecting the code could be more comprehensible by reading that contents.

Regarding your question, in CrazyS both the ground truth odometry sensor (without bias and noise) and the Crazyflie IMPU MPU-9250 are described by using the macro defined in the component_snippets.xacro file, available in rotors_description/urdf folder. In this file, all sensors that can be used in RotorS (the ROS package used as a base for CrazyS), those you can chose to use to simulate an IMU, a pressur sensor, a camera, are defined. For parameters meaning, please also take a look at the reference publications and the RotorS simulation framework, as well. A reference publication is also available here.

The file (the one I mentioned earlier) contains a full list of sensors, but sensors that will be used during a vehicle simulation (the Crazyflie 2.0, the Parrot AR.Drone, or other) are defined in the appropriate .xacro files (crazyflie2.xacro, in the Crazyflie 2.0 case).

As described in the papers, the Crazyflie control architecture was designed using (as in realty) a part of information from the ground truth odometry sensor and part of the information from the on-board IMU of the Crazyflie. If you decide to overwrite or delete one of theese, the controller will be unstable because it will not be able to compensate for errors to track the reference signals.

All topics used during the aricraft simulation (both with state estimator and not) are defined in the position_controller_node.cpp file, available in the rotors_control/src/nodes folder.

[TaoChenOSU]

Why is the generic odometry sensor used, as defined in the mav_generic_odometry_sensor.gazebo file?
In the launch file crazyflie2_hovering_example.launch, the odometry topic was remapped to odometry_sensor1/odometry, which means the node actually uses data from the generic odometry data, not the ground truth sensor. Did I misunderstand?

[gsilano]

In RotorS, the ROS package used as a base for CrazyS, the macro that describes the behavior of a generic odometry sensor is implemented in the mav_generic_odometry_sensor.gazebo file. This macro is employed for any aircraft into the virtual scenario, from the Parrot AR.Drone to the Ascending Technologies Firefly (the hexacopter depicted on the RotorS's Wiki home page). Whereas, in the component_snippets.xacro file, the macro is customized (with noise and bias terms) to simulate the behavior of a specific IMU (e.g., IMU-95250 or ADIS16448 in the case of Crazyflie and Firefly, respectively). Every customization is indicated with a short name (e.g., crazyflie2_imu, default_imu, etc.) to invoke it into the appropiate xacro file that descrbes the aircraft sensors list. For more information on how RotorS works and how sensors have been modeled, I suggest you to take a look at the RotorS repository. There you will find all information you need. Moreover, the already opened issues will give all the details you are looking for.

The remapped function has been reatained to create as much as possible a similarity with the launch files in RotorS, e.g. mav_hovering_example.launch, with aim of integrating the developed code in the RotorS repository (a pull request was opened but no one revised it yet).

Finally, as you can see in the position_controller_node.cpp file, the Crazyflie controller node is subscribed to the mav_msgs::default_topics::ODOMETRY and mav_msgs::default_topics::IMU (only if the state estimator is enabled) topics. Therefore, you are right: no ground truth sensor is in the loop, but if you take a look at the crazyflie2_odometry macro into the component_snippets.xacro file, you will see that the macro has no bias and noise terms. The values obtained by the sensor are exactly the same that would be obtained by using the ground truth sensors, but the sensor working frequency was fixed according to the control architecture. Again, for more information on how the control architecture works I suggest you see the related publications.