watchdog / battery monitor

[billtyler]

It looks like we have access to battery status from the roboclaw. I think we should either create a standalone watchdog node, or build it into another node to monitor the battery and e-stop if there are any issues detected:
over/under voltage
over/under current
temp?

We could extend the functionality a bit to include things like over tilt to prevent a roll using the IMU data or other general precautions.

Maybe this would be the what monitors the bumper sensors as well?

[jcicolani]

One of the reasons I'm a fan of the Roboclaw and, more to the point, the serial connection. Yes, we should use the voltage and temp features. My plan was to pass them through the nomad_drive node and have them post to an appropriate status topic.

The tilt and bumper readings I was thinking of posting on an appropriate sensor topic. If the IMU is passing through the arduino then it would be one node, but I'm not sure what standard topics we can use.

The nomad_control node is intended to be the one that controls direction and reaction. So decisions based on the bumper or tilt would be executed there. This would put those "reflex" type controls in the same place as the directions for the driver (nomad_control publishes the twist messages consumed by nomad_drive).

At the same time, the navigation node can subscribe to the sensor topic to incorporate that information into its calculations. I also imagine there would be a higher level governing node that would basically be a glorified state engine. It would determine higher level goals based on current state and would consume the status messages. So, if it's low on voltage, it would send the command to find power or shut down. It could also determine behavior by state. If it's in a "competition" state, then it would push the power to it's safe limits to complete the competition. Otherwise it may go into a power search mode (future enhancement).

Thoughts?

[billtyler]

We'll have to play with the various abstraction layers as we get more experienced with everything but in general that sounds good.

My thought here is that most of those features are a ways off in the future. The watchdog/e-stop is a short term mechanism for protecting the hardware until these more comprehensive features are in place. As well as a general status mechanism. For example, even with a new battery, I still cannot drive the motors. So rather than (or in addition to) having to troubleshoot these issues externally, we can have the node perform diagnostics and report issues. W can have the node expose a service(?) which when called, queries the device and publishes the diagnostic info.

The IMU, as I have it configured, is USB connected. It has an on board Arduino and and has a driver which outputs rosserial to a listening node. It could be serially connected to the Arduino but that seems redundant. The code has been added to the project here and includes the original documentation.

[billtyler]

I have added a RoboclawDiagnostics service into the node. It can be queried for a number of the settings and the error code of the roboclaw.

[jcicolani]

The issue of the watchdog battery monitor has become more crucial for a couple of reasons, not the least of which being shutting off the MC when there is a loss of power to the main board. The other crucial justification for this as a separate system is to control the activation of the Jetson. The Jetson board requires a double pressing of power button to enable. There is a jumper to accommodate the remote location of the button outside the case for this purpose, I plan to leverage this jumper along with the an Arduino and a relay board to turn on the board. The advantages to this are one of monitoring and control.

The relay board will allow the control of power to multiple systems throughout Nomad, including the Jetson board as well as the Roboclaw. There is already an Arduino Mega on board for controlling the sensors, servos, and additional systems as they're added. This board can also monitor the serial feed from the Jetson and, should an interruption be detected, cause the shutdown of the MC.

I plan on using a separate Uno as the watchdog circuit. It will be connected via a pin to a pin to the Mega. The Mega will send an occasional ping on that pin. If the ping is not received by the Uno within a time out period, the Uno will then shut down the MC and go into a stand-by mode while waiting for the all-clear signal to resume. If the signal is not received within a period of time sufficient for the Jetson to have self-corrected, it will initiate a re-boot of the Jetson. The Uno can also control an RGB LED, or series of them, to indicate status.

I am also considering adding a small Nokia LCD to provide more information about the status. In order to get the most out of that, I would need to initialize the communication between the boards using the one-wire protocol. At that point I could provide a serial string to the Uno that would include the voltage coming off of the MC. If I could further get the voltage being provided the Jetson (I've isolated the power sources for the motors and the electronics), then I'd have a more complete picture.