For a few weeks now, I have been struggling with strange behaviour on the micromouse. This version is Decimus 2C. It is the build that ran (poorly) at the UK contest in the summer of 2012. It did not do well so I have been trying to get it all tidy for the Taiwan contest next week.
For a while now, the micromouse would just do strange things. Particularly at start up, it would sometimes veer off to one side. Whenever I tried to find out what was wrong, it would behave just fine. Then, it would sometimes just crash into a wall for no apparent reason. Now, all the clues were there but I had forgotten the most basic of fault finding rules and overlooked the hardware. A close inspection of the board soon revealed the cause:
A classic dry joint on the motor connector. Normally, there is some opaque teflon tape over these pins so I had not noticed it before. It seems incredible that a pin could get all the way through that tiny gap and fail to make contact but it did. It didn’t take long to put it right:
Now, of course, everything that I did in the software to try and find and eliminate the error is suspect and I may have been doing more harm than good.
While looking for data to support the odd behaviour, I recorded the mouse position, profiler speed and the speed as recorded by the wheel encoders. A record is taken on every control cycle. That is every millisecond. position is in mm. Speeds are in encoder counts per millisecond. The encoder speed is just the sum of the left and right encoder counts taken straight out of the counters. Acceleration is set to 3m/s/s and the position is the where in a cell, the mouse is. So, after one cell of travel, the position resets. It does not go to zero because of the way I do things. That is not the problem. Have a look at the data:
For some reason, whenever I reset the mouse position at the end of a cell, I get a glitch in the encoder counts. I have no idea why but it is not going to be good. Looks like another late night.
Incoming search terms:
- strange contest in taiwan (1)