マイクロマウス | 마이크로마우스 | MICROMOUSE
This is a personal project of mine to design, build, and program a new micromouse that will be internationally competitive. I have designed a few for fun using off the shelf components and development boards. This one will be designed on custom PCBs to make better use of space and weight. This section is to document the parts and the thought processes behind it. As the project progresses you will see more and more added with links to the PCBs and code.
Many people have not heard of a micromouse. It is a robot designed to solve a maze, like a mouse is often portrayed doing. It is actually the worlds longest running robotic contest introduced by IEEEin 1977. There is are two main micromouse divisions, classic and half size. Regardless of the division each mouse is required to solve the maze completely autonomously. As the mouse navigates the maze it locates and records the locations of the walls. This allows the mouse to solve the maze and pick the shortest, or fastest path to the objective.
Classic micromouse, often just called micromouse, where the robot has to solve a 16x16 grid of cells. each cell is a 180mm square. The walls of the maze are 50mm high. The mouse starts in a corner and has to make it to the central objective, a 2x2 area centered in the maze. The mice themselves must be able to fit into a 25cm square. There is no height limitation for the robot.
Half size micromouse is the newest form of the competition. It was introduced for the 30th All Japan Micromouse Competition in 2009. Unlike classic micromouse this form has a 32x32 grid of cells. The cell dimensions have also been reduced by half to a 90mm square. The size of a half mouse is limited to a 12.5cm square while still having no height restriction.
One of the things that can drastically speed up the search time of a mouse is by using a smooth turn as it rounds corners. Green Ye has two videos that show case the difference this makes. This is a Pivot Turn that is the easiest to implement. This is a Smooth Curve Turn which helps the robot keep its speed up throughout the maze.
Another thing to drastically speed up search time is to speed up through cells that have already been discovered. Green Ye again has a nice video demonstrating speeding up through known cells.
I would also like to implement faster straight away speeds greater than 1.2 m/s and have curved speeds greater than 0.8 m/s. By having different speeds for different actions I can reduce the time of searching by playing to the robot’s mechanical and sensor design strengths.
To help speed up the fast run and also the search I would like the mouse to take a diagonal path through a zig zag. On the speed run this allows the mouse to reach a higher top speed for a longer period of time. On the search run it will only take a diagonal if it has already discovered those cells previously.
To make testing of future sensors and hardware the majority of the parts should be designed to make modifications easier. For example adjustable tow for the wheel alignment, and adjustable angles for ToF sensors.
This has been a big deciding point for me. This whole project is really because I want something to experiment on. I am also a fan of STM32 boards due to information and support available for them.
Current Selections is a:
Traditionally the use of quadrature encoders is what the majority of mice use. Mine will have encoders for each drive motor. I am also interested in playing with optical flow using a laser mouse sensor.
Traditionally in micromouse walls have been detected using Inferred LEDs. I am going to be a rebel and use something different. I also would like to experiment with looking just barely over a wall to detect the next row and drastically reduce search time.
Current Selections is a:
This is a Time of Flight (ToF) sensor that measures the time it takes light to bounce off a object and come back. Unlike a IR sensor that measures the amount of light reflected. These sensors are much more precise and not prone to the problems that plague current robots that perform differently just by changing the ambient light.
In my testing I have been able to run multiple of these sensors, side by side and crossing paths, at once with no interference. They reliably run at a 10 hz sample rate. By tweaking the “READOUT__AVERAGING_SAMPLE_PERIOD” and the “SYSRANGE__MAX_CONVERGENCE_TIME” you can see a 100 hz sample rate.
readout__averaging_sample_period:
The internal readout averaging sample period can be adjusted from 0 to 255. Increasing the sampling period decreases noise but also reduces the effective max convergence time and increases power consumption: Effective max convergence time = max convergence time - readout averaging period. Each unit sample period corresponds to around 64.5 µs additional processing time. The recommended setting is 48 which equates to around 4.3 ms.
sysrange__max_convergence_time:
Maximum time to run measurement in Ranging modes. Range 1 - 63 ms (1 code = 1 ms); Measurement aborted when limit reached to aid power reduction. For example, 0x01 = 1ms, 0x0a = 10ms. Note: Effective max_convergence_time depends on readout_averaging_sample_period setting.
Current Selections is a:
No current descision these drivers are currently options
Right now my tire selection is based solely off of others recommendations. Considerations when selecting a tire are grip, outside diameter (affects odometry), inside diameter, width, and most importantly availability. These require a 19.5 mm rim giving a final diameter of 24 mm with the tire on.
Current Selections is a:
Up to 22 timers and watchdogs:
Timers TIM2 and TIM5 have 32 bit resolution and will be used for the wheel encoders. Page 42 of documentation
Using an external chip to save information seems like the best way to go from a normal development standpoint. But the EEPROM library from ST is similar to bloatware with all sorts of extra and complicated stuff. A large number of competitors use the MCU’s internal flash to store the map data. In order to use this you have to include eeprom.h from the ST libraries.