How can I catch errors in rosserial publish() ?
Simple really - I have a robot that uses an arduino to control the motors. It gets velocity commands from a cmd_vel topic, either from a Raspberry Pi that runs the ROS master, or when it detects radio control signals on three pins and publishes to cmd_vel itself.
I assume that if the Pi crashes for some reason the ROS stack will collapse and I won't be able to publish these messages. In that case I'd like to stop the robot and revert to manual radio control, writing the received pulses to the motor controller directly instead of generating the messages.
Is there a way to detect that the publish() has failed ? I can't find anything that points to return codes or anything, so it seems that ROS messaging is 'fire-and-forget' only. Is this the case ?
Thanks for any help,
David
Perhaps you can use the
connected()method on the rosserial NodeHandle?Where would you want to detect that "publish() has failed exactly"? On the Pi, or the Arduino?
In any case: would it not be possible to do this with timeouts? Keep track of when the last
Twistwas received and start your countermeasures whenever the timeout is reached.That would be true for publish-subscribe, yes. There are no guarantees (not on reception, processing at all or timely processing by clients). If that is not what you need/want, you'd have to use a different interaction pattern.
These are good ideas and questions. I'll check out connect(), should have thought of looking at the node handle for clues :)
Ideally I'd do the detection on the arduino as it's less likely (I think) to become "unavailable" as it's powered through the same circuit as the motors and motor controller. If the main circuit breaker trips then everything stops. However the Pi (which normally would issue the automated move commands via cmd_vel) could go offline separately. In that case I'd want to be able to control it manually from the radio controller to stop any runaway.
I think the timeout point is critical too. I've moved to a "send move commands every 100ms and just stop if nothing is received for 200ms" as a safety check after the robot headed at 10km/h towards a double plate glass door, and luckily hit a ...(more)
A mobile base driver without a command timeout is asking for trouble.
That should be there, regardless of fail-over to a radio input.
Couldn't agree more :)