What’s going on with our robot??
One issue we come across every season, is coming back from a match to have the drive team say something like “I tried to turn, but it was struggling to move”, or “I pushed the button to intake, but nothing happened”, or ” I had to use the override, because the limit switch wasn’t pressed or something”. Similarly, LEDs being blamed for drawing too much current, or wondering why things just aren’t quite working as you expect, is all things that happen too regularly.
Seeing this too often, mentor Steve this year tasked the controls subteam to add code to log every event, input and output, that happened on the robot. He wanted to be able to see what the robot was sensing, what the drivers were trying to do, what the robot was being told to do by software, and what was really happening, all together.
This needed to be logged to a file, and preferably offboard to free up the RIO, to something like an SD card that could be removed after the match, so the log could be viewed on a computer without tying up the robot in case work had to be done. Given the ability in the new PDP of current monitoring and other data, the aim was to be able to view key inputs and outputs together, so that we could identify what had really happened if an issue had occurred.
Introducing WildLog
Our solution to this was 3 parts.
1. The Data Logging
Our robot software gathers the state of every input that we read and every output value that we calculate and send a signal to, every cycle of the code. With additional information now available through the PDP such as battery voltage and current draw for each channel, we can now capture and log this as well. We gather this roughly once every 20ms. The entire state is buffered, and in batches written to an output stream – in this case, to a listening server over a network connection.
2. The Log Receiver
We wrote a small server application to receive the log data over a socket. This runs on a BeagleBone Black, which was convenient due to its built in networking and its micro SD card slot. We had originally intended to use the BeagleBone black for additional off-board IO and vision processing, but did not do that this year.
The other advantage of doing this off-board is that it frees up the RoboRIO to spend its time running robot code, and not doing file IO work. Also, this can generate quite a lot of data, and we didn’t want to fill up the RoboRIO file system.
3. The Viewer
Where the magic really happens, the log viewer allows us to view multiple input and output values together and correlate the data that is logged, getting a complete picture of the robot over the course of a match or practice session.
An example – our lift
This year, we have a winch to raise our tote lift. It uses two Banebots 550 motors, has a ratchet under the winch pulley, and a pawl on a piston. The pawl must disengage before the lift can move, or bad things happen (mostly called ordering more Banebots…). There is a potentiometer driven by the gearbox to measure the lift position. The lift gear ratio was calculated to give us 36″ travel in around 1 second, and the aim was to draw no more than 20-25A per motor. After testing, we decided it was best to not move the lift at less than 70% motor speed, so once the manipulator joystick value is above 70%, the lift will move.
Once we added logging to our robot code, the logs gathered can be opened in the viewer, and inputs or outputs of interest selected for display. Here is a screenshot showing what happens when we lift a full stack of totes, while not driving. The values shown are:
- The Winch PWM output value sent from software to the speed controller
- The pawl state (engaged, or disengaged)
- The Lift potentiometer value
- The current drawn by each of the two motors
- The manipulator joystick input value
- The total current draw
- The robot battery voltage
From this one view, we can see the manipulator joystick was moved, and once it was above the threshold, the pawl was disengaged, the winch output PWM value increased, the potentiometer value increased, the current on the two channels increased (24A and 21A), and the battery voltage dropped to 10.95V temporarily.
By hovering the mouse at any point (as shown), a line is drawn to correlate the points, and the current value of each channel is shown. Graph maximum and minimum for each channel is also adjusted according to the maximum and minimum values in the current view, and are shown on the left.
By clicking and dragging the mouse, you can zoom in on the graph over any time range in the log file.
Future plans
This is an incredibly useful tool for debugging issues. Currently this is for Java only, and we are really still testing it through the season to make sure it is useful, efficient, and not too much of a burden on running robot code. So, really, it’s in closed beta.
We are working on packaging up the viewer and log receiver portions to make them easy to deploy, and are planning a different data model to be language independent. But our hope is to get this out and into the hands of other teams prior to next season, and hopefully the off-season so that teams can start experimenting with it. Once we are past Championships and get a more certain plan and timeline in place, we will release some more details, which may also involve opening it up to contributions, if you feel so inclined.
In the meantime, if you are interested in it, or like what you see and have some ideas for it, feel free to let us know! Get in touch by emailing controls (at) wildstang.org