Robot data acquision and calibration software options?

Hello Chief Delphi! 4th year mentor of team Icarus 2081 here with a question.

Does anyone know if there is a data acquisition, analysis, and calibration software package for FRC robotics? Barring that, has anyone written a driver or interface module for the RoboRio that would allow one of the industry standard software packages to interface with an FRC robot?

Some background:
Professionally, I’m a vehicle control systems engineer and use ECM (electronic control module) calibration software such as Vector’s CANape, ETAS’s INCA, and ATI’s Vision on a daily basis. Every vehicle company uses one of these programs or something similar to them. For anyone not familiar with them, they are commercial software suites that communicate with an ECM’s processor to read and write data from main memory in real time and display, record, and analyze it over an industry standard datalink protocol.
The exact mechanism that the data is collected by is not important in this case. What’s important is the ability to dynamically command (at runtime) the RoboRio to transmit any variable in the robot software and having the ability to record and display that data easily.

Options I know of now:
Driver station data logger/viewer - I’m aware of the data logger/viewer in the driver station and it is fine for troubleshooting common problems like wireless connectivity or battery brownouts after the fact. As a software development and calibration tool, though, it leaves a lot to be desired. It’s not real time and has no ability to transmit data back to the RoboRio. It’s quite slow. Adding channels is difficult and data display options are limited. All off these add up to make it unsuitable for analysis and calibration.
Smart Dashboard 2.0 - The smart dashboard is useful for some of these functions, but it has no data recording or analysis ability, configuring its layout and display is frustrating to say the least, and it requires the robot code to be modified to add/remove data channels. This is what I’ve used for the job in previous seasons, but it leaves a lot to be desired.

In short, I’ve been spoiled by the software tools available to me at work and was hoping someone had developed or was aware of something similar available for FRC robotics or robotics development in general. For those who know what I’m talking about, a CCP/XCP driver and ASAP2 generator would be perfect. If not that, a software package that fills the data acquisition/calibration role.

I’ve always fantasized about getting CCP implemented on the RIO. The main roadblocks I know of:

  1. Raw CAN interfaces do not appear to be easily accessable from java (the language we’re in).
  2. Java isn’t kind to raw addresses for data, so the mapping has to become arbitrary (Address 1 = this variable, Address 2 = this other variable, etc.).

To get around these limitations, we ended up rewriting our own form of smartdashboard in a website format, hosted on the roboRIO:

We’ve got a calibrations, state data, driver dashboard, and real-time plot view available, which is everything I could functionally think we’d get out of ATI-or-similar software… There’s some work required in the robot software as well to get it to work (extra .jar’s, custom ant build target to deploy the resources to the robot, and the need to set up objects in code to represent each piece of state data, driver dashboard, plottable variable, etc.). Not perfect, but so far has been getting us where we need to go. It doesn’t fulfill the arbitrary-access you mentioned, but it does force students to really think through what they’ll need to see to debug.

We based ours off of 254’s from a few years back, and I know multiple others have done the same thing.

I’m wondering if, at least for Java, there’s some way to hook to the robot with the debugger and stream data using that. I’m sure there’s some way of doing it, just not sure how. This could get you the arbitrary-access you referred to in your post.

Edit: was reading too fast, missed your team name before I typed this reply. I probably showed you this in person. Sorry for repeat info :slight_smile:

So more thoughts, rather than another edit. All this is my present understanding of how these tools work, and I am by no means an expert…

XCP/CCP/ASAP2 are built up around the concept of referencing data by memory address, and the association of memory addresses to meaningful variable names is done by an offboard tool. Java and Python tend to hide this memory-address mapping from the user, so I wouldn’t go down this path if using any of those languages on the robot. Labview has its own set of mechanisms for doing this sort of calibration (See the measurement and calibraiton toolkit - not sure if anyone’s tried this on a robot yet… I haven’t). So, this leaves us with C++.

XCP seems like a better choice since it wouldn’t require an extra set of CAN wires going to the robot. However, from what I can tell, XCP isn’t exactly an open standard - you have to be a member of various automotive firms to see the full implementation standard I think. Therefore, making an open-source driver yourself would probably be frowned upon? I can’t seem to find anyone who’s done it already. Any usage of a closed-source library would require they compile for the RIO architecture (not sure if anyone does), and would probably require approval by the powers-that-be around XCP. So, until the standard is opened up, XCP is probably out.

So the followup becomes - what features are you looking to get out of your toolchain? I know at least ATI supports a large number of protocols, so there might be some alternate one available? The key would be finding which end tool you like, and seeing if any of the alternate protocols support something more friendly to the roboRIO and open-source development side…

As an alternate, I’m currently looking into using the Java debugging API to get arbitrary variable access from a standalone application (which could theoretically also plot time-changing values or write cals). I’m sure something similar could be done with GCC + debugging symbols. I think the key difficulty here will be that C++ likes to be very address-centric at debug-time, while Java and Python remain fairly symbol-centric at debug-time…

Again though, if anyone has different tools they like I am all ears as well!