coneblog

I’m stumped. The Skycam flies, but something is wrong. Worse yet, something is wrong in the Software, which is my baby. I’ve spent fourty five minutes running the system around, trying to find a pattern in the line length errors in order to then deduce the nature of the problem. Either that, or start going through the code line by line, because I have no clue. The rest of the crew has ceased to watch my scurrying and measuring. Then John Seitz speaks up.

John is a strange, tousle-headed electronic-genius type that did the electronics for the motor controllers. He and I exchanged specsinorder toget the computer to control the winches. John asks what number am I using for the Drum Circumference?

As we were still early in development, I had parameterized everything that I thought might change, which included all physical parameters. In addition, because my system resolution was limited to the line length units that would fit into a sixteen-bit register (no sissy floating point here, mate), I set up the system with a flexible relationship between a bit in my line length count and the length of Cable that that represented.

That was the main job of the central computer- to re-calculate a new set of four line lengths in response to control input, and to send the delta line length off to the motor controllers. And to do that cycle fast enough to deliver smooth movement to the video camera payload.

So, I had a 60 line parameter file that I read in at initialization. One of the parameters was the drum circumference. The computer controlled the winches in terms of “chops” of rotation, with 120 chops to a revolution. So I needed the drum circumference to translate line length change into Chops.

While I was collecting data, John had pondered what was unique about movement at the center? Vertical movement at the center of a symmetrical pattern resulted in the same line length change being sent to each motor. So this is the one spot that a difference between the computer model of the system and the real-world system would not show. Deep down in John’s brain, this relationship was made. Thus the problem must be with one of the parameters that defined the real-world to the system. Hence John’s question about the drum circumference.

With John, I recalculated the circumference. The outside drum diameter plus a bit for the average cable wraps times two Pi gives me drum circumference in cm. And I’ll be damned – it is different than the value in my parameter file by about 20 percent. I was letting out 20 percent too much line with each drum revolution.

What does this tell us about debugging? The current trend in debugging code is trial and error. With fast processors and easy-to-use development environments, the tendency is to try something and to see if it works, or at least gives you more data. I have watched young coders try five different builds in the space of five minutes.

I come from a different background. In my first programming job, I got one turn-around a night, so that I had to do 95% thinking and 5% trial and error. But in either case, there is no substitute for that moment of insight like John Seitz had. That moment is one of the deep pleasures of coding.

The result? I changed my parameter file, and re-started the application. Brakes off, sticks live. Z-up and down is vertical and smooth, with no slack. Plus-X is level and straight, with no slack. Plus and minus Y axis is the same. Then the acid test – I made a diagonal move deep into the corner of the pattern. Level and straight, no rising, and all lines tight .

I handed the controller over to Garrett, who put the system through it’s paces. Side to side, up and down, swooping diagonals – the system was perfect. Garrett finished up by navigating to a point directly over the hoop of the basketball goal, and gently dipping the payload into the hoop. The crowd went wild.