Two major bugs turned up in the micromouse Decimus 2 since yesterday afternoon. Each was fatal. The maze solver bug was a surprise, the other was an example of the stupidity that I can manage when I put my mind to a problem…
Everything was going quite well. I felt that the motion controller was doing its job and that error correction was sorted out. Development thus far was by placing the mouse into wall following mode. I recommend this when dealing with the tuning of turns, edge detection and so on. Essentially, the code works exactly like the exploring phase except that, for each cell visited, the walls are examined and a simple table tells the mouse which way to turn depending on whether it was following the left or right wall. The mouse was doing a good job. Repeatable and reliable. I was quite pleased.
Maze solver taking too long
Then I thought it was time to use the solver instead of a table to solve the maze as I go and perform a proper search. Disaster. My carefully planned and tuned turns were late, the mouse kept crashing and would give up altogether after a few cells.
The only thing I had changed was to add the solver code and that was one of the few things I had not changed in the re-write. It took a while to work out what was happening but, thanks to the trusty bluetooth transmitter and a lot of diagnostic messages, it was clear that the solver was taking as much as 110ms to run. That is a very long time. The mouse would have travelled 40mm or more when it only had 15mm to get the job done.
It turned out that the new controller code is quite processor intensive. It was written with the STM32 in mind and so everything was left with 32 bit quantities. That is not very efficient on the dsPIC. Coupled with that was a known-to-be-poor technique for reading the sensors. Each is read twice inside the main interrupt code so that each sensor takes about 55us to read. Add all this together and the mouse was running at 75-85% load while exploring and there was not much power left for the solver. If it did not give back an answer in time, the mouse had missed the turning point and was doomed to crash. Some small changes to the sensor reading reduced the time spent there and made it possible for the solver to complete in 25-50ms. Still not good compared to the 7ms or so it takes when nothing else is going on but enough to be sure of having time to execute the command.
The sensor reading code now needs a major update. The controller will be OK when it gets onto the STM32. Even if nothing else changes, the STM32 has a four times faster clock and can do 32 bit sums.
Measure twice, cut once
Well, that was the evening gone but, feeling quite pleased and before going to bed at about 2AM, I had the mouse do a full search and run in my mini maze. Another disaster. Now the mouse could not do diagonals. It was not at all clear what was happening but the sound of it crashing into the walls was going to have the household awake and me in big trouble so I had to leave it until getting home this evening. After a few experiments, I could see that the mouse was travelling much further than it should when doing diagonals.
A bit of a hunt through the code revealed a remarkably stupid mistake. When re-writing the profiler, I changed the parameters of many functions to millimetres so that the numbers made more sense and changed some of the conversion macros that converted from millimetres to encoder counts. When I did that, I wrote down the distance across a diagonal as 255mm, overlooking the fact that diagonals are run from edge to edge, not corner to corner. Foolish. Once changed to 127mm, everything behaved properly again.
There are still plenty of issues but I think they are now relatively minor. Where have I heard that before?
