runtime data collection

[Ether]

As an off-season programming project, I've been thinking about asking some programmers to figure out a way to write 50Hz runtime data (like motor commands, motor current, and wheel speeds) during each match to a memory buffer in cRIO that could be downloaded from the cRIO to a laptop for analysis after the match (or even at the end of each day).

Has anyone tried this? If so, was it fruitful?


~

[BigJ]

Team 1675 is working on a new version of Autoflex that kind of does this, or could be extended to do this. Autoflex was a program designed by a former mentor for the IFI control system that recorded 15 seconds of certain inputs into the controller's EEPROM and played them back as a 15 second autonomous mode.

We record inputs, but it could be easily changed to record returns from any function or method, I think, and be extended to any time period. We are using the file system on the cRIO and I think that's where they are running into problems at the moment.

It's not really done yet (psh, who wants to build and program a robot anyway). We dead-reckoned our autonomous this year.

I'm not totally up to speed on the progress on our new version (in C++ anyway) so I'll see if i can convince one of our other programming mentors to make a post.

[kamocat]

If you do this, make sure to do it in Periodic Tasks.
I tried logging the status of the robot (for field diagnostics during matches), but found it slowed the code down to 150 to 230 ms per iteration. (That's a lot of lag for a driver.)
It's possible that it had to do with the string processing functions I was using, but I have a feeling that the cRIO has slow memory writes. (Why else would it take several minutes to transfer your code?)

[Ether]

Originally Posted by kamocat

It's possible that it had to do with the string processing functions I was using

I wouldn't use string processing functions for what I had in mind. I would just write the data in its native format to the buffer. Less memory usage, less processing.

[kamocat]

That's an interesting idea.
I think that would be the "temporary data directory" you're referring to.
In the Functions palette, look under Programming > File IO > File Constants.

[gvarndell]

Originally Posted by Ether

As an off-season programming project, I've been thinking about asking some programmers to figure out a way to write 50Hz runtime data (like motor commands, motor current, and wheel speeds) during each match to a memory buffer in cRIO that could be downloaded from the cRIO to a laptop for analysis after the match (or even at the end of each day).

Has anyone tried this? If so, was it fruitful?
~

Wind River already has it, now if we can just figure out a way to get them to include it for the FRC teams.
It's called data monitor (used to be called StethoScope).
Very easy to set and enable/disable monitor points, configure the sample frequency, set the buffer size, upload to host and (are you ready for this?) graph the data in Workbench.
This is exactly the kind of thing one hates to see programmers reinventing.
But if Wind River won't let you use it, and you need it, then you probably will end up doing it.
Yes, it will be fruitful/

[Ether]

Originally Posted by gvarndell

Wind River already has it, now if we can just figure out a way to get them to include it for the FRC teams.
It's called data monitor (used to be called StethoScope).
Very easy to set and enable/disable monitor points, configure the sample frequency, set the buffer size, upload to host and (are you ready for this?) graph the data in Workbench.
This is exactly the kind of thing one hates to see programmers reinventing.
But if Wind River won't let you use it, and you need it, then you probably will end up doing it.
Yes, it will be fruitful/

This is exactly what I want. And no, I'd rather not re-invent it.

Teams with "overheating CIMs" could gain great insight using a tool like this, I would think, especially if they glued a small temperature sensor to each CIM. (Or if they were capturing motor current and voltage and speed, they could calculate winding resistance whenever the motors were stalled).


~

[BigJ]

Originally Posted by gvarndell

Wind River already has it, now if we can just figure out a way to get them to include it for the FRC teams.
It's called data monitor (used to be called StethoScope).
Very easy to set and enable/disable monitor points, configure the sample frequency, set the buffer size, upload to host and (are you ready for this?) graph the data in Workbench.
This is exactly the kind of thing one hates to see programmers reinventing.
But if Wind River won't let you use it, and you need it, then you probably will end up doing it.
Yes, it will be fruitful/

Ooh. Yeah, forget about what I said for this stuff.

[rrossbach]

This very easy to do using ordinary file I/O in Java or C/C++, several teams already use this for runtime feedback. Just write your data to a CSV file, grab it with ftp and open with Excel for whatever analysis you want to do. Just be careful not to exhaust available cRIO memory.

...but I have a feeling that the cRIO has slow memory writes. (Why else would it take several minutes to transfer your code?)

The several-minute transfer/deploy times seem unique to LabView. Deploying Java for example is usually < 1 minute. One of the many reasons our team switched from using LabView last year to using Java this (and future) years.

- Ron
Team #2607 controls mentor

[Tom Line]

Originally Posted by rrossbach

This very easy to do using ordinary file I/O in Java or C/C++, several teams already use this for runtime feedback. Just write your data to a CSV file, grab it with ftp and open with Excel for whatever analysis you want to do. Just be careful not to exhaust available cRIO memory.



The several-minute transfer/deploy times seem unique to LabView. Deploying Java for example is usually < 1 minute. One of the many reasons our team switched from using LabView last year to using Java this (and future) years.

- Ron
Team #2607 controls mentor

Our code in labview transfers in less than 1 minute. Now, building that code on the programming laptop may take up to 3 minutes in bad cases.

[gvarndell]

Originally Posted by kamocat

If you do this, make sure to do it in Periodic Tasks.

Yes, with an easily configurable sample rate.
You wouldn't want to sample data at 100Hz if the data only changes at 1Hz.

I tried logging the status of the robot (for field diagnostics during matches), but found it slowed the code down to 150 to 230 ms per iteration. (That's a lot of lag for a driver.)

You were logging the data to a file no doubt.
If so, you were writing to flash file system and there's your SLOW.
Ideally, you would want to log raw binary data -- not formatted strings -- and you'd want to store into a RAM buffer.
The Wind River data monitor does exactly that.
The size of the buffer, whether it's a wrap-around buffer, and the upload-to-host threshold is configurable from Workbench.
If you must log to a file (because the buffer management/access functions are more work than you want to do) then look into creating a RAM disk just for the logging.

It's possible that it had to do with the string processing functions I was using, but I have a feeling that the cRIO has slow memory writes. (Why else would it take several minutes to transfer your code?)

When you transfer code, it's going to the flash file system.
Writing to flash memory is always SLOW.

[apalrd]

If you want to see the progression of a variable during testing, LabVIEW has a nice graph control.

I had to save some data during a match once, so I bundled the data into the Dashboard packet and saved it on that end. Since I bundled a Teleop Elapsed Seconds and Robot Mode in there, I can stamp everything based on that, so the lag dosen't matter. I saved the camera images at crucial autonomous steps too, so I can review them later and tell the drive team how to adjust the position for the next match.

[Ether]

If I log 10 single-precision floats at 50Hz for 2.5 minutes that's less than a third of a MB. The cRIO has 64MB RAM.

[ayeckley]

Originally Posted by BigJ

Team 1675 is working on a new version of Autoflex that kind of does this, or could be extended to do this. Autoflex was a program designed by a former mentor for the IFI control system that recorded 15 seconds of certain inputs into the controller's EEPROM and played them back as a 15 second autonomous mode.

2252 has that capability now using plain-old LabVIEW (the basis for our Innovation in Control award at Buckeye). We're taking snapshots of the control inputs and writing a record to the the cRio filesystem vis-a-vis an .xls file every 50ms with no appreciable impact to the balance of the control system. There's a little bit of jitter reflected in the timestamps associated with each record (a couple of ms typically), but the error is non-cumulative. Playback offers no particular challenges since we load the file data into arrays during Disabled mode instead of in real-time. I plan to write a whitepaper about it in the offseason if anyone is interested. We hope to do a useful demonstration on the Curie field as well

[Ether]

Originally Posted by ayeckley

I plan to write a whitepaper about it in the offseason if anyone is interested.

I'm interested.

~