Emulation

| | Comments (0) | TrackBacks (0)
I've been volunteering as a mentor for FIRST robotics team 2809 (one of the many reasons for the deafening silence in these parts of late) and one of the things I'm working on at the moment is a better emulator for the FIRST C++ interfaces.

I got into the whole mentoring gig without thinking too hard about it, and it turned out to be both vastly more fun and vastly more work than I could have possibly imagined.  2809 is only two years old, and most of the high school students who were on the team graduated last year, so while we are extremely fortunately in our university mentors, it was a steep learning curve for a lot of people, myself included.

I have robotic programming experiencing going back a long way.  I worked for a while as on a robotic weather station project as a grad student, and my last post-doctoral gig involved development for the robotic calibration source manipulator for the Sudbury Neutrino Observatory.  Since then computer assisted/image guided surgery has been a big part of my professional life, so I've always been close to the hardware, and one of the first things I typically do when working with hardware is create an emulator:  a software system that mimics the API of the hardware lib.

This has a number of advantages:  it frees the software development process from the hardware development process, and as I've found that unlike software, hardware deliverables are sometimes quite badly late, this is a good thing.  It also lets you examine software failures, which do happen from time to time, in a strictly reproducible environment, and it lets you study the effects of various non-idealities, hardware failures, and so on.

So all in all having an emulator is a Good Thing.  I put one together for the FIRST system quite late in the game, but it was still useful for debugging and testing various coding ideas.

My goal at the moment is to beef up the emulator so it can be used by people who aren't guru-level C++ coders.  The learning curve for the FIRST C++ environment is such that it is very tough for the kids to deal with practical implementation issues.  Having a better emulator will let me teach them enough in the off-season that by the time the next competition roles around we'll be in vastly better shape to cope.

My original emulator was strictly command line, but I'd like a prettier front end on it, which in the current case I'm writing in wxPython, mostly because it reduces the amount of time I have to deal with Eclipse/CDT.  I've thought about driving everything off of Visual Studio, which would certainly make life easier for the kids, and have to confess to still being a little tempted in that direction.  But they'll need to deal with Eclipse during build season, and familiarity breeds fluency.

As of tonight, I have the wxPython front end talking to the emulator back-end, and am about to strip out all of this year's code from the robot with the exception of the low-level drive stuff.  Our drive system doesn't change much from year-to-year, so I want to keep that base platform intact, and then once the kids are up to speed with it start throwing them some problems of sensors and effectors and seeing what they do with them.


0 TrackBacks

Listed below are links to blogs that reference this entry: Emulation.

TrackBack URL for this entry: http://www.predictivepatterns.com/cgi-bin/mt/mt-tb.cgi/9

Leave a comment

About this Entry

This page contains a single entry by Tom Radcliffe published on April 9, 2010 8:15 PM.

Metaprogramming: the goal was the previous entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Categories

Pages

Powered by Movable Type 4.1