Trackin fool

Refactoring to allow for testing is sooooo a good thing.

I finally had the brainstorm. I'd been developing two separate projects for this. One is down-n-dirty, get 'er in. Test it out. Oops..that's ugly but it works.

And one "nice, pristine, how it's supposed-to-be".

I'll let you guess which one actually made progress. For a while.

The pretty one was essentially used as a testing ground for nunit. And therefore has a nice bunch of unit tests.

And then it happened in the "real" project. Ka-blam. Hit a wall. Why isn't this working?!! It should work. The logic is right. Those d!$#m gremlins are getting in between the parsing and compiling stages. I just know it.

Deep breath. Back off. Put the mouse down. Take a walk.

Then it hits me. I'm having so much trouble (partially) because I'm having to do so much crufty liberal insertion of system.diagnostic.debug.writeline.

(true confessions, here)

And it's a PITA to debug. Because...well...things are so tightly coupled I'm not quite sure WHERE to put in the debug statements and even when I do I'm making assumptions about other pieces working and that leads to...

Well, we all know what happens when you assume.

So in a fit of brilliantly obvious inspiration, I did two things.

1.) I ported the unit tests over to the "really/working but somewhat crufty" implementation.

2.) Did some decoupling. Specifically there were two pieces:

• determine which way way I'm supposed to go based on where I am and the target is
  
• issue a command to move the robot ( myrobot.moveright() )
• translate the moveright into actual motor directions (move motor b @ 70% power in the left direction)

The third had already been isolated. But I was doing 1 and 2 in the same function. I pulled them apart. Now a parent function says "where should we go?" and the fxn returns a "left, down" or somesuch.

NOW we're cookin. Unit tests were written for each of 4 quadrants, like so:


// $ = target point (where to move to)
//
// --------------------* < -100,100 (max rot values)
// | quad 1  |  quad 2 |
// |         |         |
// |         |         |
// ----------$----------
// | quad 3  | quad 4  |
// |         |         |
// |         |         |
// *--------------------
// ^(100,-75) min rot values

And as the french say, "voilia!" (literally, "let us eat cheese!")

In the end all was happy. Except tracking was much less precise than I'd like. Gear slop and imprecision in initial calibration were affecting things far more than I'd like.

So...where are we at?

The laser tracking worked best for precision...but it suffered from light refractions and went somewhat nuts in anything but a nice, lowlight environment. Oh, and if the beam was scattered or at an angle (think: shining a laser pointer on a table at a steep angle), things went wonky. Chasing butterflies.

Dead reckoning isn't particularly precise...but it's kinda/sorta "in the neighborhood".

Can I combine the two? Maybe limit the search radius for the laser pointer to within x pixels of the estimated dead reckoning solution? It's a thought.

But regardless, it'll be integrated and tested. =^)

In Mechanical news...

The gearing has been reduced and reworked for both pan and tilt. Of course, this adds to the gearlash problem, but it was necessary for precision reasons.

("Slow 'er down!" everyone said.)

(Well, not everyone.)

(Ok, maybe just me.)

Anyway.

But it's working. Back to "das blinkinlights" working.

But now we've got

• boundary checking (no more chasing butterflies and grinding gears)
• Four shot rotary magazine
• Smaller tilt cradle footprint (geez. I should be in marketing. No...no, actually. I shouldn't)
• A cool "fah-WOOSH!" sound when the missile is fired. (put that in for the kids)

Now it's time to put in code to track values returned from the sonar (ultrasonic) sensor. Fire when the target is within...oh...let's say 50cm.

Ok. Go to it.