You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am also interested to know why it was removed actually. When I am using the ROS2 RTPS bridge and the sensor_combined_listener example for instance, ros2 topic hz /fmu/sensor_combined/out shows around 230Hz, while uorb top shows that it is published at 250Hz. It seems like once every so many messages, one gets lost/dropped and this causes the lower publish "rate" (in fact the rate is around 250Hz, only some messages seem to get lost along the way).
I am looking for a way to see where this message is lost..
The text was updated successfully, but these errors were encountered:
It was removed from uorb top because the numbers often didn't make sense with consumers like logger only grabbing a subset of messages.
Instead we've started monitoring it from the Subscriber side. If there's a particular case where you can't tolerate any gaps then you can check the generation before and after an update.
@dagar Thanks, that is very clear and makes sense. I will look into checking the generation. @hamishwillee, I could definitely make a picture, but my terminal does not have the same graphic settings as the one in the docs. An example output for me is as follows:
Also in the simulation environment I have a lot of instances for some topics as you can see in the picture above. Is that normal, or might this suggest something is wrong?
I assume this has been removed in an update but it has not been removed from the documentation (https://docs.px4.io/master/en/middleware/uorb.html)
I am also interested to know why it was removed actually. When I am using the ROS2 RTPS bridge and the sensor_combined_listener example for instance, ros2 topic hz /fmu/sensor_combined/out shows around 230Hz, while uorb top shows that it is published at 250Hz. It seems like once every so many messages, one gets lost/dropped and this causes the lower publish "rate" (in fact the rate is around 250Hz, only some messages seem to get lost along the way).
I am looking for a way to see where this message is lost..
The text was updated successfully, but these errors were encountered: