Thread created automatically to discuss a document in CD-Media.
Using a Virtual Robot Model – Testing and Debugging Autonomous Code Through Simulation by: Chris Hibner
Why wait until you have a robot before testing your autonomous code? Fully test and debug your autonomous code using simulation.
A method for testing and debugging autonomous code was created using LabVIEW. This paper explains the simulation environment and how to use it to test your autonomous code. The LabVIEW VIs for the simulation are contained in the zip file.
We started using simulation to test and debug autonomous code since the first year autonomous mode was introduced. Way back then (in 2003), we designed and implemented our autonomous control in Simulink+Stateflow (kind of similar to LabVIEW, but from The Mathworks instead of NI).
Using Simulink, we were able to create a nice simple robot model to fully test and debug our autonomous code. We then auto-coded our autonomous code directly from the Simulink/Stateflow models, just like what what teams are doing today with LabVIEW.
Now that FIRST is using LabVIEW, we ported the same simple robot model concept over to the LabVIEW framework. Thanks to simulation, our autonomous code is now fully debugged and working even though we don’t have a robot yet.
Simulation is a great tool, and not just for FIRST. This is the way it is often done in the real world. I hope this is useful to some teams.
Chris, you rock. This is a really cool idea, thanks for sharing. The combined power that is Wings of Fire has been scary all fall… it just got scarier.
Chris,
The content of this paper proves that you’re an engineering ninja. You taking the time to write and post it proves you’re a class act. I already knew both of those things…
Are you trying to prove to your mechanical team that you have too much time on your hands and they should hurry up and finish the robot?
Thanks for sharing. Hope everything is going well for you guys up there.
I can’t wait to see what happens when you cross a Huskie with a Chief.
I urge everyone to take a look at what Chris has posted. Mathematically modeling FRC robots is an interesting topic, and to see it implemented practically is very cool.
On behalf of Mechanical Designers everywhere, I want all programmers to do this… maybe then, they’ll stop bothering us. "The robot will be ready when it’s ready!"
With computers, every once in a while you see something that makes you think “I could have done this, why didn’t I think of it? It would have made my life so much easier.” Now is one of those times.
Yesterday was our day to get the autonomous code dialed in, so I figure I would post a follow up to report how it went, and how the simulation-based testing and debugging panned out.
Prior to yesterday, here is what we did:
About 8 hours spent coding our autonomous sub-VI.
Using the simulation tool, about 4-8 hours spent testing, debugging, and tweaking the autonomous sub-VI.
Then at various stages, another 4-8 hours for coding, testing, and debugging various “good ideas” we had pertaining to autonomous (all via simulation).
Yesterday, we finally got to test it all on the real robot. Here is what we did:
about 1 hour was spent dealing with issues in Disabled.vi because we didn’t initialize everything correctly.
about 15 minutes spent in PeriodicTasks making sure calculations were being performed correctly.
about 20 minutes of testing to be sure the signals were all in the correct orientation (i.e. postive went the proper direction, and negative went the proper direction).
That was all setup in order to start the autonomous subVI testing. In our Auton2010.vi, here is what we did:
about 1 hour was spent dialing in control gains for all of the various PID loops and controls calculations (and there are quite a few for us).
about 30 minutes spent running some simple autonomous scripts to verify the robot performance against the simulation.
about 15 minutes spent writing and testing an autonomous script for use in the competition, which worked flawlessly the first time.
Summary:
During robot testing, we made ONLY two changes in the auton2010.vi:
Control gains
I removed a feature that I thought was a good idea, but decided it was ill-conceived.
Everything else regarding auton2010.vi was done in simulation. As it was in the past, it was a huge success again this year.
