I wanted to share what I worked on this past season.
After an eventful 2017 year when Team 1014 first deployed a swerve drive bot, we spent months trying to iron out all the kinks. Logging every possible metric we had access to helped tremendously but resulted in some pretty hacked together code. It became clear that we needed a better system that would not only gather data reliably but also allow us to visualize it, and most importantly make it accessible to all team members. So, with memories of matching corrupt CSVs to match videos still fresh in mind I started working on a fix: badlog. In short, we get dynamically generated HTML versions of our data logs. Details and source code are available in the whitepaper.
So what makes badlog good?
Despite having a slight bit of a bias I can confidently say that using badlog as a user in the 2018 season made life easier as a programmer. We set up badlog once at the start of the season, and since then within seconds of every match we get intimidate visualized data. It never broke; it helped catch countless problems, big and small, at every competition; and is as risk-averse as you expect any logging system to be. All of these logs for the season are available online here; as they were during our competitions. Describing a visualization system with text doesn’t do it justice, so that last link is a good example of the system.
Badlog has greatly helped our team by being a compelling alternative to conventional FRC logging. It provides useful information, as shown in the examples, and does this well, as shown in the whitepaper. Team 1014 is also making this available to other teams and is more than willing to provide assistance if needed, and with any luck team 1014 won’t be the only ones showing off our logs this upcoming season.
We’ve been doing time-series logging for the past couple years and it’s repeatedly proved invaluable at finding root cause of issues, and even predicting issues before they happen!
For disk space issues, we log to a 16gb usb drive that we attache to the RIO. Has the added advantage of being able to pull it off the robot to download the log files, though we usually are just using a python script that does an scp operation.
Do you make use of the actual bag files or only the CSVs?
We’re working on a similar approach but running into issues with bag files due to the size of the ones output from ROS. (even with compression we’re in the multiple GB range)
Just CSVs, but we don’t call them CSVs in case someone tries to open them in excel and gets errors when it finds JSON in the header. Calling them bags is really just because other names were taken from ros and rosbags are the closest thing to this.
As far as disk space goes we didn’t really have any trouble. CSV with truncated decimals is really space efficient even without compression. We created files just under 2MB per match, so we could easily push 50+ matches without any worry. At one point had two separate competitions on the Rio at once and we had 147MB to spare.
So if you log around as much as we did (35-40 data topics) that ends up being around 4 hours to get to 150MB. Since we cut the rate down to 4 updates/s when disabled we can go around two full days on standby.
Huh, looks like my last response got lost but a later one went through. Yeah they are all CSV files (with a JSON header), but not called that in case someone tries to open them in excel or something. Badlog takes a lot of its names from ros and since rosbag is the closest thing we ended up calling them bag files.
If you do happen to decide to choose a new file extension in the future for your json+csv format, may I suggest “.badbag”, purely because it’s fun to say?
mmk, I was going to be VERY shocked if you’d flat out stollen the bag file format. Woulda made me happy since it would have just let us drop in our rosbag files
Thanks for posting Dominik! As he said, Dominik’s work here really helped us in diagnosing problems quickly. In 2017 he and I spent a lot of time trying to time sync large data files and writing quick Java, Python and MatLab programs to visualize. Sometimes at a pace that meant we were playing our next match before the data let us figure out what was going on. In 2018 there were several times that problems cropped up and we were able to eliminate potential issues in minutes, identify the problem (whether mechanical, electrical or programming) and fix it rapidly. I was a very proud and much less stressed out mentor as a result.
I am very interested in this, but it looks like the ChiefDelphi update has lost the whitepaper. Do you have that somewhere else, or know how to find it here on the new CD?
Thanks for the interest. Yeah the CD update hit this pretty hard, sometimes the link doesn’t work, and when it does the download link fails. Here is a link that will stay online. It’s also a little newer since I discovered the example had an error.
Thanks! Sorry for dumb follow up questions, but where does the log file go, and how do you get the log files off the robot?
Also, the topics are currently limited to numeric data, is that right?
If I just wanted to write string messages out, would that have to be extended?
That’s our current problem now, is just seeing the messages we want, w/out being obscured by all the junk that driverstation and wpilib outputs to the main log 50 times a second.
No problem. The log files go wherever you set the path to. Here is what we did last year (timestamps didn’t work because the Rio doesn’t have accurate time until driver station connection). Badlog itself can log any string data, but badlogvis doesn’t support non-double type data (It might work with the ‘hide’ attribute). It could probably be extended really easily though.
