Oops (or, "why can't Brian count?")

Jim tried out my program and promptly discovered I had been lazy and not actually tested it... at all (that's right folks, always remember to make your mistakes big and in the blogosphere...). The problem was that the loop counter was counting "0 - 1 - 2" just like computer do, but Brian was thinking of it as "1 - 2 - 3". As a result, the sound didn't synchronize and the numbers displayed weren't quite right. The solution Jim found was simple: use a Math block to add one to the loop counter before wiring it into the Number-To-Text block and the Switch. Problem solved!

Brian Davis

Brian Davis


To give Brian some credit... he didn't actually have the bot to test it on, so I cut him a LOT of slack :)

Also, considering that all I did was add in a MATH block to his elegant program, I think he's being a bit too harsh on himself, too.

I hope you've enjoyed watching our little back and forth improvements on both hardware and software.

Matthias is up next with his LDRAW contribution. He might be convinced by some reader comments to post some "working" images as he designs...

Unknown said…
May I?

Buddy, you were supposed to keep my back free instead of knifing me! ;-)

Ok, let's wait what people will say...

*Still laughing*,
Matthias Paul
Unknown said…
As for testing, that certainly is one of the most crucial points with distributed development - how can participants test their software on hardware (= actual version of robot) they don't have at theirs' disposal?

One solution could be some kind of "Extreme LDrawing" (XL): LDraw files frequently updated by the robot building team as a means for providing hardware information to the software team (yet, the overhead might be not negligible).

After all, Jim, we should try to come up with some "Distributed NXTing: Lessons learned and best practices" document, shouldn't we?

Matthias Paul
A best-practices document, huh? And Matthias pulls out his knife! :)

Looks like more writing in my future...

Seriously, though... Matthias has a good idea. This project was fairly simple (relatively speaking) - Brian had my original code and a few images, so he knew that I was using 3 motors, each controlling an item.

The difficulty is when the right-hand doesn't know what the left-hand is doing. Collaborative design doesn't mean we divide up the work and then go work in secret... it was very important for all of us to keep in contact. This was especially important during the test phase - I kept hearing the bot say < blank > 1, 2... it wasn't programmed to say ZERO because it was programmed to recognize 1, 2, and 3. Since the program loops start counting with zero, it took me a few minutes of staring to figure out the problem... a quick email to Brian about my thought to add an increment (MATH block) and he confirmed it would work.

It was also important to keep all the work public (via blog) so Matthias could start thinking about what would be involved on his end.

Next, we take Matthias drawing(s) and incorporate it into a design document that will show someone how to build RaSPy and how to program it.
Anonymous said…
In the beginning there was nothing...

Applies to events of biblical proportions, array indexing and variables that initialize to zero. :)
Brian Davis said…
> Collaborative design doesn't mean we divide
> up the work and then go work in secret...

Agreed. Collaboration must involve communication of some form. Here, we did it on-line so everyone could watch. This weekend, a friend of mine built a NXT robot that fired little spheres, and I write the program while he built.

Brian Davis

Popular Posts