Exploration is a critical task for a micromouse. The maze must be explored quickly, thoroughly and without error. Any mistakes made during exploration are likely to completely ruin your chances in any of the contests where there are search time or mouse handling penalties. In the Japan event, you don’t get very long in the first place so wasting time by restarting the exploration is not good.
Ideally, the micromouse will not stop moving unless it enters a dead end. Any turns other than that need to be very smooth and accurate. Possibly the most difficult formation to explore is a series of 90 degree turns one immediately after another. Here the mouse cannot use the side or diagonal sensors to reliably correct any forward errors and there is only a few mm of travel to correct any angular or lateral errors. In fact, corrections started by the side/diagonal sensors may simply put the mouse off course as the next turn comes up.
Attempting to run the entire exploration run by dead reckoning is difficult as errors can accumulate. More than a few cells and the errors may soon become uncorrectable. That said, if there is no wall ahead and the mouse has to turn, then it must do so based only on its internal estimate of position.
If there is a wall ahead in the cell where the turn is to take place, corrections can be made from that. The sum of the readings from the two forward-looking sensors give the distance to the wall and the difference gives the angular error. Using these values to correct forward positional errors and as feedback for the rotation controller can be very effective in making sure that the turn happens exactly where it should. Naturally, the walls in any maze vary so the turning position may also vary by a few mm but, done right, these errors should average out.
Part of the preparation of Decimus 4B for the Taiwan 2014 contest is fine tuning the exploration. The video below shows Decimus 4B performing a search with one key difference. Instead of examining the maze to determine the best route to the goal, the mouse just makes a random turn. The maze here has only posts except for the bounding walls. Corrections can only be performed when a turn has a wall ahead of it. Otherwise, they are all done by dead-reckoning.
This Post Has 11 Comments
Looks like you are ready for the version of the competition where you do the run without any walls!
Well – they do just get in the way.
great job done! Did you increase the turning radius in order to make a faster turn or you switched to sinusoidal profile already?
It is using a sinusoidal profile. The turn radius is about 85mm effective but the minimum radius is around 55mm. I cannot use a target speed higher than 700mm/s for the turns because there are occasional errors that do not allow the mouse to slow down enough for the turn so I leave a margin for error.
If the 85mm effective radius is the ideal radius, then the 55mm radius isn’t the optimal solution for sinusoidal profile at all. It is making the angular velocity much higher than it is supposed to have at this speed level. It can go about 67mm min radius based on your way and the T1/T3 are 60ms, T2 is 74ms, max angular velocity at T2 is 600 deg/s. (All at 0.7m/s)
The angular velocity may be higher in my profile but the angular acceleration is smaller. It is always about compromises. Out of curiosity, I tried your parameters and I would have to start my turns a bit earlier to get them to work out as reliable.
In general, I would like to star the turn as soon as I cross the threshold but I need to make a few other changes for that to be possible.
How fast are you running your search turns?
the spec I gave you was just the rough estimate from my profile
0.9m/s stable at 80mm ideal radius.
I ran 0.8m/s at APEC
Since you make the radius to 85mm, do you think you have sufficient straight part before turn to make the search algorithm to finish calculating for the worst case?
The time taken by the solver is a possible worry but it takes about 700us to flood an empty maze. While searching, I do nothing but flood. No attempt is made to generate or optimise a path. I do need to do that but it should not make the whole process take more than a few ms. I figure that, so long as I can get 10mm of travel, I will be fine. The turn always finishes well short of the cell boundary because of slip and I could alway start the solver before the turn has finished, as soon as I am straight enough to see the walls in the next cell.
Since I use floodfill too, I remember at 2013 APEC there was a cell takes about 6ms since that cell caused a long detour when I was doing the simulation on computer. However, that is fine for you case(0.9m/s straight)
The way you are mention at the end is what I am trying to do for my next mouse, by angling the side sensors more to the front in order to detect side wall earlier. As a result, Turning radius can be easily increased to 90mm by read wall 10mm ahead than normal way. Thus a stable search turn at 1.0m/s will be possible.
BTW I am trying to optimized the floodfill to be able to flood 2 mazes at same time(both departing and returning), I will need to full 10mm straight before turn for make sure it can be finished on time.
Hello, I was wondering if anyone could point me to some resources that explain the sinusoidal turn profiles? I’ve read the trapezoidal turn profile resources from Project Futura, but I’m having trouble finding anyone else using a sinusoidal profile.
Here is the short version. If you need more, please ask.
It rather depends on how you execute your turns. I make the accelerating part of the turn take place over a fixed distance. During that phase, the distance travelled is converted into a fraction in the range 0 to 1. Or 0-255 if you prefer. The fraction is used to look up a value in a table of sines. That give a number between 0 and 1 which is then multiplied by the desired maximum angular velocity to give the desired angular velocity for that point on the acceleration phase. The same thing is done while decelerating back to a straight line except the fraction decreaes from 1 to 0.
If you don’t do the table lookup, the fraction can be used directly to scale the angular velocity.