The current implementation requires modules to define a status_level basically indicating whether or not they are working properly and a status_msg with useful debugging information in the case that something is wrong. Operating with the ROS plugin in with real hardware with a significant number of sensors, we have found it too expensive to transmit status messages for every module, so we would like a way to convey the same information in a more compact form for transmission from the Arduino to the Raspberry Pi.
I propose we add an additional field status_code which will be an 8-bit integer value with some module-specific meaning. A code of 0 should always mean that the module is operating normally, and there should be a lookup table in the module.json file with the meaning of all other error codes. This would render the status_msg field obsolete, and we could probably remove it later once all of the modules have been modified to use status_codes instead.
For the ROS plugin, this means we will have to create a new message type that is a lighter version of DiagnosticStatus to publish from the Arduino and a software module that can convert from the new message type back to DiagnosticStatus messages for integration with the ROS diagnostics stack.
If we deprecate the status_msg field, the CSV plugin will have to be rewritten as well. For ease of debugging, it seems very useful for the error messages to be transmitted directly on the serial port instead of error codes. Thus, we may have the plugin generate Arduino code that converts the error codes to messages on the Arduino before that information is sent over.
LeonChambers
commented
7 years ago
The current implementation requires modules to define a
status_levelbasically indicating whether or not they are working properly and astatus_msgwith useful debugging information in the case that something is wrong. Operating with the ROS plugin in with real hardware with a significant number of sensors, we have found it too expensive to transmit status messages for every module, so we would like a way to convey the same information in a more compact form for transmission from the Arduino to the Raspberry Pi.I propose we add an additional field
status_codewhich will be an 8-bit integer value with some module-specific meaning. A code of 0 should always mean that the module is operating normally, and there should be a lookup table in themodule.jsonfile with the meaning of all other error codes. This would render thestatus_msgfield obsolete, and we could probably remove it later once all of the modules have been modified to usestatus_codes instead.For the ROS plugin, this means we will have to create a new message type that is a lighter version of DiagnosticStatus to publish from the Arduino and a software module that can convert from the new message type back to DiagnosticStatus messages for integration with the ROS diagnostics stack.
If we deprecate the
status_msgfield, the CSV plugin will have to be rewritten as well. For ease of debugging, it seems very useful for the error messages to be transmitted directly on the serial port instead of error codes. Thus, we may have the plugin generate Arduino code that converts the error codes to messages on the Arduino before that information is sent over.