Heartbeat line dead driver#

The heartbeat messages in a lidar driver node as I see it can tell the following: Is the heartbeat a simple boolean capturing all of this diagnostic information for a higher level system wide health monitor? Or is this a simple “I’m still here” message, and the above diagnostic work would still need to be performed? Are the LIDAR points within spec | valid?Īt the perception level, is the sensor blinded? Is a soda can or plastic bag covering the LIDAR? Is the LIDAR casing covered in snow, or grease? Basic errors in the data itself.įor sensor data, is the sensor producing data in spec? Did a HW component fail report any errors. We could break this down into sensor interface, sensor data, and perception.Īt the sensor interface level, there are errors in communication of the data from the LIDAR to the compute platform running ROS. To be concrete, there are multiple levels of perception failures from a LIDAR. What are your opinions on this Heartbeat message?Ĭan you expand on how the “heartbeat” message verifies the sensor is working as expected? One question remains: where should this message go? diagnostic_msgs would probably be a good place. We can now also create “stripped” bag files which do not contain the large sensor data (so they are 1 GB instead of 40 GB), while still having an idea whether the sensor worked as expected at a given time point (thanks to the heartbeat messages). We have already implemented a custom Heartbeat message to our Ouster lidar driver and used it during the SubT challenge to verify the sensor is working as expected. But that’s for future, now I’d like to concentrate on adding the Heartbeat message itself. This naming convention could be further utilized in e.g. sensor publisher on topic /scan would also create the heartbeat publisher on topic /scan/heartbeat. The heartbeat publisher could be automatically created with a standard topic suffix, so e.g. The publish() call on the sensor publisher would automatically call the heartbeat publish, too. Taking the idea further, NodeHandle could provide a method like advertiseWithHeartbeat() that would automatically set up and control the heartbeat publisher in addition to the normal sensor data publisher.

And there is of course no unnecessary CPU or network load. Also, writing diagnostic analyzers for this would be pretty easy and there could even be a generic one usable for all heartbeat greatly simplifying setting up the diagnostics. The postprocessing step is then made super-easy if you record the heartbeats.

Heartbeat line dead code#

A code path that publishes the sensor data would just copy the header of the message to the Heartbeat message and publish the heartbeat right after publishing the sensor message (or before it?).

The idea of the Heartbeat message is that it has the following definition: Header header is not good at all for large sensor data, where you create unnecessary CPU and network load just to check the frequency. Also, to find and check the rate of the node in postprocessing, it requires going through all diagnostics messages and parsing them to find the relevant reports. is almost good, except it’s usually a lot of lines of code to set up diagnostics for a node. Subscribe to the output topic of the sensor and check the delays/rates on the subscriber end.Use TopicDiagnostics on the publisher and publish whether the expected rate/delay is okay to /diagnostics.Why: If you have some system diagnostics that checks your sensors are running, you basically have two options now, none of which is easy and good: I’m about to open an issue/PR in ROS repos asking for adding it, but before that I wanted to collect some ideas here. Hi, I’ve been missing a Heartbeat type of message for quite long in ROS (talking about ROS 1, but this probably also applies to 2).