search

osrf / subt

This repostory contains software for the virtual track of the DARPA SubT Challenge. Within this repository you will find Gazebo simulation assets, ROS interfaces, support scripts and plugins, and documentation needed to compete in the SubT Virtual Challenge.
Other
305 stars 98 forks source link

X4 warning: failed to meet update rate #274

Closed osrf-migration closed 4 years ago

osrf-migration commented 4 years ago

Original report (archived issue) by Hector Escobar (Bitbucket: hector_escobar).

I am running the sim using catkin using the following command

ign launch -v 4 tunnel_circuit_practice.ign worldName:=simple_tunnel_02 robotName1:=D1 robotConfig1:=X4_SENSOR_CONFIG_2

And immediately after, I see the following warning repeatedly:

[ WARN] [1574678810.559301273, 30.684000000]: Failed to meet update rate! Took 0.020000000000000000416

On the Tunnel Circuit we had issues where the air vehicle was not completely behaving as we had seen before. It seemed like it had slower response and that affected our attitude estimation and control and maybe this was the cause?

Could you explain this warning?

‌

I also noticed that this warning was shown when the nodes start:

[Dbg] [EntityComponentManager.cc:627] Using components of type [7808403688689644833] / [ign_gazebo_components.ExternalWorldWrenchCmd].
[Wrn] [Component.hh:144] Trying to serialize component with data type [N8ignition4msgs6WrenchE], which doesn't have operator<<. Component will not be serialized.

Thanks,

osrf-migration commented 4 years ago

Original comment by Hector Escobar (Bitbucket: hector_escobar).

osrf-migration commented 4 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

osrf-migration commented 4 years ago

Original comment by Hector Escobar (Bitbucket: hector_escobar).

Hi @azeey ,

Are you able to see this message?

osrf-migration commented 4 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

What all nodes are you running? That error message could be either from your controller or the subt_rotors_controller. It’s nearly impossible to distinguish without more information though.

‌

Also, if the update rate of that control loop is 50 Hz and you get an update that took 0.020000000000000000416 seconds I would not be too worried. There needs to be more analysis done before we look into this much further. A quick search through the rotors package did not return any hits on grep -ir “Failed to meet” so I don’t think it’s coming from the controllers employed from the simulator side.

osrf-migration commented 4 years ago

Original comment by Hector Escobar (Bitbucket: hector_escobar).

Arthur Schang (Arthur Schang) , I am not running any other node than calling the simulation with

‌

ign launch -v 4 tunnel_circuit_practice.ign worldName:=simple_tunnel_02 robotName1:=D1 robotConfig1:=X4_SENSOR_CONFIG_2

And in that single terminal I see the warning. This seems to be related to issue #208 but I see it on X4.

‌

osrf-migration commented 4 years ago

Original comment by Malcolm Stagg (Bitbucket: malcolmst7).

I am seeing this issue too, with no other nodes running. It seems to occur with any of the X4 sensor configurations.

osrf-migration commented 4 years ago

Original comment by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

I do see these messages. The "Failed to meet update rate" message is from the ukf_localization_node, which is part of the robot_localization package. This node creates odometry messages for use by the UAV controller by fusing IMU data. The target update rate is currently set to 250 Hz which is in sync with the simulation time step. I believe the error message is printed when the CPU has a high load (from running the simulation) and the localization node is unable to do its computation within the allotted time. In issue #208, the simulation was running at higher than 1x which made it impossible for the controller and localization nodes to keep up. The fix was to slow down the simulation back to 1x.

I'm currently testing out a way to avoid using ukf_localization_node by generating odometry messages directly from IMU messages. In the mean time, if the UAV is not behaving as expected, you can try slowing down the simulator with the updateRate command line argument of the launch files. The default updateRate is 250 Hz. You can try with 125 (updateRate:=125) and see if the reduces the error messages. Note that since each vehicle gets its own AWS instance, this should not be a problem on Cloudsim unless your solution is CPU intensive.

The warning "[Wrn] [Component.hh:144] Trying to serialize component with data type [N8ignition4msgs6WrenchE], which doesn't have operator<<. Component will not be serialized." is related to distributed simulation, which is not being used by SubT. You can safely ignore this.

osrf-migration commented 4 years ago

Original comment by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

I believe this is resolved by the new UAV velocity controller.