Number 5 is Alive!
First, apologies for those people who don’t like the movie “Short Circuit”, the past few weeks have felt like that.
I’ll cut right to the chase: the robots work. Not as cool as we had hoped, yet, but still very cool.
After the last post, we where working on getting the optical mouse to tell us how far we’d gone. Initial tests where positive. The mouse was reporting change and such. But after mounting the mouse to the underbelly of the car, the mouse wouldn’t report data reliably. We suspect that it was something to do with the car going too fast. It might be that we where traveling out of it’s field of vision within it’s 200Hz sample rate. But even making the car drive slowly (which wasn’t easy) on carpet barely improved the situation.
So, with the accelerometer down, and the optical mouse down, what do we do? Well, with time running short, we turn the mouse upside down and use the wheel! This setup finally got us measuring distance reliably. very hacky, and not as cool looking, but functional.
I then worked up some TCP code that would have the cars talking to each other. The idea here was that there would be a lead car that would calculate how to drive, then share it with the other cars. To test, we set the one car we had built as a following car, and a router as a lead car, then adjusted the code so that the lead car wouldn’t try and go and wouldn’t hold up the other car. This setup showed that the one could tell the other how to drive. The following car seemed to drive accurately, too.
So we go on and try and do a full test of this. And then the car stops being controllable. The router still works. The microcontroller still works, but the car keeps trying to go forward. Apparently we are now down to two cars. So we build up car number 3. But my partner tells me he blew out the final car a while back. Dont’ ask me how, but he did. One car isn’t a swarm. We could do the router-car swarm, but that isn’t much either.
So with one working car, we continue to test accurate driving. My partner works out a replacement board for a broken car. We think the car’s board is a simple H-bridge, as it seems to work like one, but we couldn’t find the parts to fix it. He built a new h-bridge finally, but it drives weakly. But it will do. On my end, I find out that the turning code is off. It isn’t always registering turns accurately. I add in code and find a whole bunch of math errors. Most of them involved the fact that our angle is always between PI and -PI radians (-180 to 180 degrees). This causes issues when the angle jumps from -3*PI/4 to +3*PI/4 (a turn of 90 degrees over that jump). I finally figure out an equation that compensates for that.
Now we finally have two cars to drive. I set it up so that one car still just sits there and the other car get’s it’s instructions, then goes. But it just sits there…. Turns out that my TCP code for that part shouldn’t have ever worked. It assumed that my TCP stack would tell me there was data even if I had already read it, so that if I got 3 instructions in one burst, I’d only read one of them and ignore the rest until I got another packet, where I’d read one more, and so forth. So how the code was working before was a mystery.
I fixed that bug, and it seemed to work again. I adjusted the code so that the lead car would drive and then tell the other car to go. The lead car (however slowly due to the H-bridge) would go, then say it was passing control. The other car would then crash. I added debugging and saw it crashing between two lines of code that it wasn’t crashing on before. I added more debugging to see if maybe I had a Null pointer in there. And it stopped crashing. I do more tests and it starts crashing again at random locations. This is a pain. I suspect what happened was that the lead car would send the go command repeatedly, and the follower would fill up it’s TCP buffer and segfault. So I made the go signal send once and it fixed the problem. Rather, I made the go code send once, and it fixed it, so I think that was what the problem was.
At this point we where suppose to demo it to the professor. We have it working in tests, but when he showed up, it stopped working. it would drive off into walls and not go and such. Not going and driving randomly seems to be noise in the serial line. So we filter that, and we send commands multiple times. Running away in a turn seems to indicate more turning math problems. Multiple passes through finds most of the math errors, but seems to cause more harm than good. Now it doesn’t turn correctly at all. I measured the compass data over a complete revolution and put it in excel and saw that the angle was always within a small range pointing mostly to the drive motor. Moving the compass to the front fixed it somewhat, so I measured the bias and just fixed it the rest of the way in software. Add in some noise filtering and it’s good to go.
More testing and a lot more time finally gets one car to do about the same thing as the other. It’s about a week latter than the demo date, but the professor said he’d still like to see it, even if it is late. I made a video of it on my camera, just in case, then show it to him. It finally worked right and it’s done.
Yes, that’s a long summary of about 3 weeks worth of work, but it’s done. When I get a chance, I’ll upload the video and some pictures to this post, so check back. I’ll also upload all schematics, code, and the final paper at a later date. The whole project will be under some open license so that people can make use of it. I don’t know about support or updates, as I don’t know the interest, but at least people can make free use of it.