Three weeks ago, I got a basic implementation of The Hubble Telescope Nebula Challenge working, which made Mini Mouse’s code “feature complete” from the point of view of entering all of the autonomous challenges.
Honestly, I was pretty darn happy. All three challenges were working well enough to be “competitive”, and with more than a month to go until the competition, all that was left was optimisation. So, I spent a week doing rapid-fire blog posts .
Come the weekend, I was ready to have a bash at improving the Hubble performance, and retrieved the ‘bot from the shed (I don’t keep my LiPo batteries in the house), and found that the glue holding the camera had become “un-stuck”. I didn’t think much of it, glued it back in place, and headed to Makespace for a Saturday of coding.
Then things went South. Trying to implement a “controlled arc” routine, where the robot will drive a specific accurate distance along an arc1 by counting wheel rotations, I found the motion control code had a couple of bugs, present from the start. Firstly, I’d introduced a factor of two error in the code which calculates angular velocity. Secondly, the code which is meant to keep wheel speeds within the physical capabilities of the motors wasn’t doing the right thing in some cases.
I fixed both bugs - with the net effect that all turns became twice as fast. This is a problem, as it means that all of the autonomous code may need re-tuning for the new turn rate.
When I tested the straight line course, the result was disastrous. The robot
oscillated wildly, and didn’t track the line at all. I reverted the code to the
old “buggy” version (
git is a superpower.) and it didn’t help one bit. I spent
effectively the whole day trying to get any kind of performance, to no avail.
To make matters worse, neither of the other autonomous challenges would work either. Clearly, re-mounting the camera caused some issues. I still don’t fully understand what’s gone wrong. No matter how I adjust the camera, the outcome doesn’t seem to come close to what was working before. The most maddening thing is that I never put any effort into putting the camera in a “good” position in the first place, I just stuck it in. I also never previously put much effort into tuning the line-following code. I just ran what I had already tested on my small test course and it worked right away, even after doubling the speed.
The rest of the Mini Mouse posts have been fairly rosy - written after the respective problems had been solved; but getting thrown back to the drawing board, without really understanding why or how to fix it was a significant blow.
I took a week “off”, working on a different project making an open-source toolchain for Garmin GPS turn-by-turn navigation (to be written up later), and replacing my bicycle’s drivetrain.
This week, I got back to the robot, and at this point have just accepted that whatever is wrong with the line following can’t be easily fixed. Based on old snapshots from the camera and constants in the code, I’ve re-mounted the camera (to the best of my knowledge) back how it was, but the line following is still badly broken.
At this point, I can’t explain it. The computer vision is working fine, so the issue is purely in the motion control. I must have got insanely lucky the first time around, that the camera positioning and motor control was just right, but incredibly sensitive to any disturbance. The net result being, I can’t reproduce it.
Still, I’ve got the maze code back to some level of decent performance, and the Hubble code is working OK (minor tweak needed - I think it was originally written with the camera “half unstuck” and pointing upwards).
So, I’ll persevere, but I expect I’ll be going to the competition with a much, much slower line run.
Even after implementing the controlled arc code, it’s terrible. I think the amount of wheel slippage makes it totally inaccurate. I found some papers discussing the issue, but I haven’t tried implementing anything to improve it. ↩︎