[Astronouth7303]

Originally Posted by Tom Saxton

Last fall, our team invented a mini-challenge which involved building a FIRST-scale robot for practice. (We're a rookie team and didn't want the six-week build period to be our first robot-building experience.) It was tremendously useful and greatly improved our performance on the real FIRST competition. You can read about our practice challenge on our web site http://www.issaquahrobotics.org/challenge/index.html

I would be intereted in looking at it.

Originally Posted by Tom Saxton

Anyway, one thing this made pretty obvious is that the software team doesn't get much time to program. So, while we were waiting for the robot to get built, we programmed some with a little EduKit robot. To try out some algorithms, I wrote a simple 2-D simulation in C++ which abstracted the playfield, sensors and motors. It ran the code in user_routines.c from the IFI code without modification (except via changing the header files), although it would be difficult or impossible to simulate the bugs in the PIC compiler. I didn't fully simulate the PIC hardware, so analog inputs and PWM outputs worked, but I didn't do things like interrupts.

That's easy to do in an object-oriented language.

Originally Posted by Tom Saxton

Later, more for fun than anything else, I built 3-D model of the 2004 play field and our robot using OpenGL. I like OpenGL better than DirectX since it runs on multiple platforms. After I got it working on OS X, it was very quick and easy to get it running on NT/2000/XP. Porting to Linux should be equally easy, only the code that puts the OpenGL display into an OS window and the event code has to change. Of course if you do a good job of keeping your physics, rendering and event code separated and limit OS-specific code, it's not too hard to port to another platform.

That is one of the questions: build for what? Win32? MacOS? OS X? Linux? Java?

Originally Posted by Tom Saxton

I did not do any physics modeling at all. The 2-D simulator would stop whenever the robot crossed any of the playfield boundaries, but the 3-D model didn't do any hit detection at all, much less physical interactions.

Writing a 3-D physics engine is a LOT of work. I worked at a game company that created such an engine for creating Nintendo and PS2 games. It took many person-months to get it working with a specific set of objects interacting, on the same order of magnitude as what you'd need to turn a reasonable variety of robot designs on a given playfield. It's easy to get a sphere bouncing on a flat rigid plane. It's even pretty easy to get a spinning top to work correctly from pure physics principles without writing "spinning top" specific code. But, simulating friction and having multiple objects interact correctly is quite difficult. For example, having a bunch of blocks jumbled into a pile and behaving correctly is incredibly hard.

Friction probably won't come 'till version 5. And a robot won't interact with itself.

Originally Posted by Tom Saxton

One of the most interesting challenges in writing real-time robot code is dealing with flaky sensors, non-linear motors, uneven friction, squishy wheels, chain slippage, and lumpy carpet. These things are all difficult to simulate realistically. It's easy to write a line-following algorithm with perfect sensors; it's much harder to write one that works with sensors that give uneven and inconsistent results and sometimes just flat-out lie.

Like I said, the first couple versions will only do what's expected, not what will happen. Our bot uses a CIM and a drill motor for driving each side. but w/o the drill, it can't spin on carpet! in v0.5 of this, it would.

But the sooner v0.1 is made, the sooner we can get v5 made.