Move Blocking
I guess this is the official term for when you slow down other components to your slowest thing.
Used this concept when running RRT on the F1TENTH, because the scans from the /scan
topic were coming in much faster than the rate at which the car could run RRT and actually apply the steering inputs.
This should reduce the oscillations.
#serendipity Hemal Shah talks about how
- In Foxglove, nothing gets dropped, which is why we have issues with large data streamed over websocket like large images, and laser scans
- With NVIDIA’s internal GXF, we have a
DownstreamReceptiveSchedulingTerm
that checks that the subscriber is ready to receive the message, so the publisher is throttled - In ROS, the publisher is responsible
ChatGPT
Q: in ros2, I subscribe to the /scan topic. However, if my scan topic publishes at 30hz, but my function can only run at 10hz, what happens?
What happens when your callback function is not able to keep up with the rate at which messages are published?
- The message queue will start to fill up, potentially leading to dropped messages and reduced performance.
- Ex: If the /scan topic is publishing at 30Hz but your callback function can only process messages at 10Hz, the message queue will start to fill up with messages waiting to be processed. Eventually, the queue may reach its maximum size and start dropping messages.
Solution: use a technique called message throttling limit the rate at which messages are processed by your callback function
- Implementation: use a timer to trigger the callback function at a fixed rate
Example of implementation for message throttling
what's wrong with just letting the queue drop messages? i have a queue of 1
It’s generally better to avoid dropping messages and try to ensure that your system can keep up with the message rate by using techniques like message throttling or increasing the processing speed of your callback function.
Dropping messages can indirectly contribute to delays and jitter by disrupting the timing of the message processing.