Author Topic: Micro Mouse Robot (Read 10126 times)

Mysion · « **on:** February 13, 2019, 03:18:00 pm »

Recently I began working on the design of my second robot for the micro mouse competition. I designed V1 during my freshman year and now that I'm a Junior in college I figure it's time I take a second swing at it.

For those of you who don't know what micro mouse is it's a student robotics competition. Each run of the robot has two stages. In the first non-timed stage your robot maps the maze. Then in the second stage your bot it timed in how fast it can reach the center, now that is has mapped the maze.

Version 1 pictured bellow had a few major short comings. The biggest is the lack of encoder resolution. It only gets an encoder tick every 1.1 cm. Over time hardware was added to the bot to try and improve the situation. A I2C gryo was added underneath the robot and the IR distance sensors were replaced with ST time of flight sensors. I feel as if I've taken this robot as far as it can go and it's simply time for V2.

Originally the project did not include the raspberry pi strapped to the back of the robot. This was a late a addition. The idea here was that other team members would be able to code maze following code in python instead of C. While awkward this did work.

When planning V2 the most important part is the encoder selection. The robots that compete in the extremely competitive Japaneses compitition use expensive Swiss Faulhaber motors. Thankfully Pololu makes a motor with an encoder that will be almost as good.

These little guys will get me twelve tick per motor revolution which will then be multiplied by the gear ratio. With a 50:1 motor that's 600 ticks per wheel revolution! Far better than what I was getting before.

This time around I'm also planning to move away from AVR and give ARM a chance. I've got a STM32 dev board so that will probably be my pick.
Now that I know what motors I plan to use I can get started with CAD. I'm going to complete the mechanical design and then hopefully the circuit will fit in the area available.

This is what I have so far. There's a ball caster holding up the front. The distance sensors will be attached with vertical daughter boards similar to V1. This time I'll use connectors instead of soldering the boards together.

I'll post more updates as I work on the CAD model. Today is a snow day so time to make the best use of it!

Doctorandus_P · « **Reply #1 on:** February 13, 2019, 03:40:11 pm »

Where do the yellow CAD wheels come from?
Are they real, or can you make them yourself?

These motors are relatively expensive from western "hobby" shops and a lot cheaper from Ali / Ebay / China direct.
Model is N20 and they come in different gear ratios and with or without encoder, or even with wheels.
https://www.aliexpress.com/wholesale?SearchText=N20+encoder

Also, for real competitive Micro Mouse acceleration becomes an important factor and a low center of gravity becomes important.
You also want to keep as much of the weight on the driven wheels during acceleration and braking, and not on the coaster wheels.
Your first version is not so good at this, try to factor this in in your next design.

Mysion · « **Reply #2 on:** February 13, 2019, 03:57:25 pm »

The wheels are JSumo wheels available here https://www.robotshop.com/en/jsumo-slt20p-steel-silicone-wheel-set-33mm-20mm-pair.html

There nice since the overlap the gear box, this add width while keeping the robot small.

Thanks for the link. I didn't realize they were available so easy on aliexpress. I may still go with Pololu due to shipping times but I haven't crossed that bridge yet.

The placement of the wheels is a challenge. The only way to do away with the caster completely is to use a 4 wheel design. I did play around with using gears on the Pololu motors for 4 wheels but then the bot ends up far too wide. I really want to keep the width at or bellow 80mm. I am concerned with the front pitching up during acceleration so the battery will be placed there to add weight.

The new one will be far lower to the ground with only 10mm of clearance this time around and far more compact.

alanb · « **Reply #3 on:** February 13, 2019, 04:53:19 pm »

Great project, I would love to see more pictures.
What type of batteries do you use? are they located underneath to keep centre of gravity low?

Whats the resolution like for the time of flight sensor and what is the minimum distance that they can detect?

Good luck with version 2.

Mysion · « **Reply #4 on:** February 14, 2019, 02:27:31 am »

Good questions!

The TOF sensors have a minimum range of 3cm and go out to almost 200cm. When you are closer than 30 they have a nice failure mode and just keep reading 30. In practice this should be okay as 30mm is too close to a wall. I won't know how close, just too close but good enough.

The battery will be mounted in the front like in the image bellow.

All the red parts will be 3D printed. The bumper is in the rear to allow the robot to push up against rear walls to align it's self. It shouldn't need to but more options are good.

I've been thinking about my goals and Doctorandus_P is right this design will never be able to compete on an international level but that's okay. It's not my goal. (Nor do I have the funds)
This robot, if finished in time will compete in the IEEE east coast competition made up of college students. The previous robot was slightly above average so V2 should blow away it's expected competition.

In addition to the micro mouse competition it should serve as a fun little platform to work on my robotics skills and toy with Freertos.

alanb · « **Reply #5 on:** February 14, 2019, 08:53:36 am »

You are rekindling my interest in the topic. I abandoned my attempt a few years ago as I couldn't get reliable wall detection with IR leds. I'm tempted to order some ST VL53 modules and have another go.

CJay · « **Reply #6 on:** February 14, 2019, 09:13:19 am »

Oh my, those motor/gearbox/encoder assemblies are nice, cheap too!

I can see a father/offspring project in the near future.

Mysion · « **Reply #7 on:** February 14, 2019, 11:05:32 pm »

Alanb glad to get you interested again! The only down side to these sensor are the maximum 50Hz update rate and the minimum range of 3cm.
They are also an absolute bitch to solder. If you plan to hand solder them you have to get a stencil made.

I've got half a mind to use IR sensors in combination with the TOF sensors. I have the board space. I may order an evaluation board just to see how bad/good they are.
Do I even need distance sensors with a faster update rate? Then again if I have the board space it doesn't add much cost.

CJay glad to have helped bring the motors to your attention!

Doctorandus_P · « **Reply #8 on:** February 15, 2019, 12:21:19 am »

Handsoldering the vl53l0 without microscope & experience will be quite a challenge indeed.
But if you're not upto that chalenge you can easily buy them on breakout boards with breadboard friendly 0.1" headers.
It's up to you where you want to get them from

https://www.adafruit.com/product/3317
https://eu.mouser.com/Search/Refine?N=1323043&Keyword=VL53L0
https://www.aliexpress.com/wholesale?SearchText=vl53l0xv2

Mysion · « **Reply #9 on:** February 15, 2019, 03:56:53 am »

This time around I'd like to use switching power supplies instead of linear. 3.3V for the logic and 6V for the motors. They will be powered from a 2S lipo.
The last bot killed 2 lipo's after they were left in for two long. I did add code to beep when the battery gets low eventually but I still want a hard ware shut off this time.

I found a LVC IC on digikey I plan to use. (NCP308SNADJT1G) All it will do it disable the switching regulators when the battery voltage hits 6.2V (A charged battery is 8.4V)

For 3.3V I'm using (AP65111AWU-7) and for the 6V 3A supply (AP65402SP-13). I'm following the recommended circuit and layout found in the data sheets.
I figure it's best to test the supplies on there own first so I plan to order a test board.

Here's the finished schematic.

U3 and U4 are current sense IC's. These will output an analog signal to the micro. My hope is by constantly taking a reading I can get a good idea of total current draw from the battery. Not sure how well this will work, it's a bit of an experiment.

alanb · « **Reply #10 on:** February 15, 2019, 09:51:30 am »

Quote from: Doctorandus_P on February 15, 2019, 12:21:19 am

Handsoldering the vl53l0 without microscope & experience will be quite a challenge indeed.
But if you're not upto that chalenge you can easily buy them on breakout boards with breadboard friendly 0.1" headers.
It's up to you where you want to get them from

https://www.adafruit.com/product/3317
https://eu.mouser.com/Search/Refine?N=1323043&Keyword=VL53L0
https://www.aliexpress.com/wholesale?SearchText=vl53l0xv2

I'm going to use cheap breakout boards from Ebay together with cheap motors with encoders for the intial prototype. I'll leave the soldering of the vl5310's until the second version. The first version will be a development test bed, it won't be entering any competitions so size, weight and speed at this stage don't matter.

Mysion · « **Reply #11 on:** February 16, 2019, 07:00:41 am »

Alanb sounds like a good plan! You'll have to use a library to interface with them. The data sheet's don't expose the inner workings and most of the library's come from reverse engineering ST's official C library for the sensors. Bit of a bummer but not too bad.

I spent some time looking around and found an IR sensor I like on digikey. https://www.digikey.com/products/en?keywords=336-5135-ND
They look like they should be better than the VNCL4020's I've used before. More importantly they allow for changing there I2C address same as the VL53. This means no dam I2C splitter chip.

It's a simple enough schematic and it didn't take me long. To disable the IR sensors I'm simply tying a N channel MOSFET to the logic power line. This way I can disable all some of them and reprogram the I2C address.

Mysion · « **Reply #12 on:** February 16, 2019, 07:50:38 pm »

I went though a few revisions on the sensor daughter board but I finally made one I liked. Here's the finished PCB design and a 3D render straight from diptrace.

The small mosfet is to turn off the IR module so that I can change the I2C address at start up. If all sensors power up with the default address they will create collision on the communication bus. This way I can keep all but one powered down. This way I can change the I2C address one at a time.

I've been working on the PCB for the power supply test and that should be done soon and ready to send off.

Mysion · « **Reply #13 on:** February 17, 2019, 02:54:05 am »

With the sensor step file exported from dip trace I mocked it up on the cad model.

With this many sensors I practically have a primitive LIDAR system! Not sure I need this many but why not!

The main schematic for the main board is almost done. I was worried the circuitry wouldn't fit but it will. Might just be a bit snug.

Mysion · « **Reply #14 on:** February 19, 2019, 02:21:41 am »

I finished the layout for the power supply test PCB. It's drop 8.4V to 6V and 3.3V. For the motors and microcontroler respectively. I think it looks good for my first SMPS. I used a 4 layer board and kept every thing close together.

I also got my first bit of code running on my STM32F070RB dev board! A simple freertos example that passes button input to another thread blinking an LED. It's a start!

I'm using atollic as my IDE. I'm still getting used to it but it seems good so far.

Mysion · « **Reply #15 on:** February 24, 2019, 02:09:06 am »

Turns out that cortex M0 cores don't support ITM, the arm debugging protocol. Pity I was looking forward to using it. I ordered a uart to usb converter on amazon instead.

I also want to post about a maze simulator I created about a month ago for the competition. It's coded in python and it's intended to help with creating an algorithm to solve the maze. It was designed for use with mouse version 1 and it won't do any of the fancy moves such as cutting across multiple corners but it will solve the maze. For version 1 I was worried about how much time it would take to solve the maze. There is a ton of room for optimization on mapping. With the simulator I tried 4 different approaches. All the comparisons in this post are too different maze mapping methods/algorithms.

Picture of the program in action

Do note that in all the approaches un mapped squares are treated as fully open with no walls until they are mapped.

Approaches
1 Chase Center: In this method they bot is hyper focused on finding the center. It will always follow the current best case path to center assuming the un-mapped squares are empty.
A major weakness of this method is that the bot can flip flop between multiple paths. When a route is discovered to be more difficult than an alternative it will re-route to map that route. Also it uses the path from the starting square to center as the path it follows. The local route to center difficulty is ignored.

2 Map it all: In this method the bot simply seeks out the closest un-mapped square. This was the worst by far.

3. Local Chase center: In this mode the bot makes getting to center is number one goal and does not consider the path from the starting point to center. Starting the path finding from it's local position it gets to the center. Then it will back track and map any squares that are needed for the map from start square to center. This method can still have some flip-floping issues but the scale is smaller than for method 1. Also it tends to end the mapping near the start square and this saves time getting back to start.

4. This is built on top of method 3 and is an attempt to limit flip-flopping. If a new faster route it found it's distance from the current position of the bot is measured. If it's above a threshold the bot hold's it current route and attempt to find the center. In some cases this would add 10 or so cycles to the previous method. However on one test maze it saved almost 100 cycles.

Picture of the raw data.

I tested these methods on 7 mazes I found online. They were all past competition mazes. Using method 1 as a base line method 2 was 11% slower and method 3 was 19% faster. Method 4 was the clear winder at 13% faster.

I'll post the source code on the Hack IO page for the project soon, I'll be sure to mention when I do.

Siwastaja · « **Reply #16 on:** February 24, 2019, 07:02:13 am »

A great inspirational thread, thanks. Add a few sensor modules more and you have a great sensor subsystem capable of doing actual localization and mapping and obstacle avoidance! If you have a well working and calibrated gyro running, to give you a heading that doesn't drift on a small time scale (seconds), you may even implement a "drunk mode" which scans the environment by oscillating the heading while moving, filling the dead angles of the sensors.

For routeplanning, I have good experience in implementing A*, or more specifically, the theta* variant, with added twist of testing whether the robot can turn, in addition to line-of-sight tests. If your robot isn't round and can hit obstacles during turning, this is of course important. For a robot that is bigger than one "pixel" in the grid, and can possibly turn, I found out that a good optimization is to use a 1-bit lookup table for the robot shape, for example, for a 32*32 pixel robot area, rotated in 16 different directions would be const uint32_t shape_lut[16][32] and accessed like shape_lut[direction][y] |= (1<<x). Now you can do comparisons to your map with a single bitshift and single AND operation, and compare 32 spots at once. On my theta* routeplanning, this optimization alone brought around 20x speedup IIRC.

I don't know if A* or Theta* is the most efficient or simplest for a tight and complex maze, it probably isn't; however it works great for real-world routeplanning where following a wall tightly would result in a long and stupid route, and it's simple to implement, the pseudocode widely available by googling actually works.

But routefinding and solving the maze is always the easy problem, by orders of magnitude, when you compare it to the problem of creating an accurate map with your sensor data and localizing in it. If you want to work on the maze solving first, make those corridors wider than 1 pixel, use some non-zero dimensions for the robot, and add some "noise" so that the walls are jagged.

GopherT · « **Reply #17 on:** February 24, 2019, 12:56:51 pm »

For your programming logic, look up "flood filling"

And a bigger simulation...

Mysion · « **Reply #18 on:** February 24, 2019, 04:12:43 pm »

Yep that's exactly what I'm using! Should have specified in the last post. The little numbers in each square if from the flood fill. The small colored squares show if a tile has been mapped. Red means it hasn't been visited and blue means it has been.

Surprisingly easy to implement. I have some extra logic in the flood flll that increases difficulty if the robot has to turn to go around a corner but other than that it's straight flood fill.
With regards to the mapping methods all of them use flood fill to find squares. The method just varies the immediate goal and sets thresholds.

coppercone2 · « **Reply #19 on:** February 24, 2019, 05:19:32 pm »

you might want to call the sensor 'failure mode' a heuristic or span feature if you document this for employer, it is a bit confusing and improper


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Micro Mouse Robot (Read 10126 times)

Share me