Author Topic: Micromouse robot project. (Read 19734 times)

hazzer123 · « **on:** January 01, 2008, 03:12:02 PM »

Hi guys,

It has been a while since i have had time to visit this forum and do robotty things, but now i do so I'm back.

I decided a while back that i wanted to enter a competition called micromouse - link http://www.tic.ac.uk/micromouse/. It's one of the only robotics competitions i have heard of in the UK. Basically, each contestant must have a robot which autonomously navigates and finds its way to the centre of a 16x16 maze.

My plan -
Use 2 1.8^o stepper motors to drive the robot. 200 steps/revolution means i can move the robot in increments of 0.5mm.
A 9.6V Ni-Cd RC car battery to power it.
A PIC18F4525 for all the computation etc. This chip has plenty of on board memory for maze storage and logging.
Reflective IR sensors to detect walls.

Hardware progress -
I designed the robot in the CAD software Pro/Desktop. The two levels on the top of the robot are for carrying 2 layers of circuitry. The white block behind the motors is the battery.

I then had the parts made out of acrylic cut with a CNC laser cutter. The accuracy was fantastic so i have a good solid base.

I designed the wheels to have 10cm circumference, so that i had a nice round unit to work with when doing the navigation maths. I need to find a better material to make the wheels out of though, since the acrylic gives no traction.

Electronics progress -
I have so far created a simple driver board for the motors, and another board housing the microcontroller and in circuit debugging hardware. So far i have had the motors turning well with the battery.It had a sufficient amount of torque.

Software progress -
To start to understand the theory behind the algorithms used to create and solve mazes, i used the MATLAB software. I managed to create some routines which solved the mazes well. Here is an example of the maze generated and the solution.

The routine could only produce mazes which had precisely 1 solution from top left to bottom right. To test the maze-solving algorithm on more complex mazes, i deleted a few walls from the maze. It did find the best solution afterwards.

So yeah thats it so far...
Please leave any comments/criticism

Have any of you guys ever done a similar projects? Any hints/tips? What is an easy to use, cheap material i could make the wheels out of?

Thankyou

Hazzer

airman00 · « **Reply #1 on:** January 01, 2008, 03:25:32 PM »

the only drawback i see in your project for other people is that you used a CNC laser cutter

many people do not have access to that

but the project looks very interesting

hazzer123 · « **Reply #2 on:** January 01, 2008, 03:37:33 PM »

Hey
Hmmm yeah u have a point. In the tutorial i will mention how to cut and drill acryllic accurately without such a machine. Paper templates laid over the sheet of acrylic will suffice.

Thanks

airman00 · « **Reply #3 on:** January 01, 2008, 04:53:09 PM »

im interested to see the maze algorithm in pseudo code ( not in C or BASIC, in regular english)

ddemarco5 · « **Reply #4 on:** January 01, 2008, 07:29:06 PM »

why don't you glue thin strips of rubber onto the wheels. Or just make new wheels made entierly out of rubber.

hazzer123 · « **Reply #5 on:** January 02, 2008, 05:14:34 AM »

ddemarco Yeah i suppose i could do that... i guess id need to remake the acrylic wheels with a slightly smaller diameter to account for the extra thickness of the rubber, but its a good idea. Thanks

airman00 - Here is the pseudocode for my 1 of my maze solvers

Start at the starting square (1,1 in this case)

(1) while we aren't at the finishing square
Check if you can go north
If you can go north and repeat loop (1)
Check if you can go east
If you can, go east and repeat loop (1)
Check if you can go south
If you can go south and repeat loop (1)
Check if you can go west
If you can, go west and repeat loop (1)
You can't go anywhere so return to last visited cell and repeat loop (1)
end

Checking if you can go somewhere --

if the cell doesn't exist
stop checking
else if there is a wall between current cell and the cell you are looking at
stop checking
else if the cell you are looking at has allready been visited
stop checking
else
store the current cell coordinates
update the coordinates to the destination cell
mark the new current cell as visited
stop checking

Its pretty inefficient and doesn't necessarily find the shortest path.

The other one i tried was outlined in Admins tutorial

I chose the first algorithm at first because i knew that my robot wouldn't know where all the walls are when it was placed into the maze, something that i thought the wavefront algorithm required. But if you just have the robot do the algorithm with the wall it knows, and pretend there are no other walls, then it still works, provided you repeat the algorithm everytime you find new walls.

hazzer123 · « **Reply #6 on:** January 02, 2008, 11:47:36 AM »

I found an awesome video of a micromouse that won a Japanese competition. It is scarily fast...
[youtube]N2fp6apH5Rw[/youtube]
I love the way it takes the diagonal routes in the maze so quickly. It would be great if i could implement smooth turning on mine, but i won't count on it.

I don't think speeds like that can be achieved with steppers. They are bulky and don't have the rpm.

Rebelgium · « **Reply #7 on:** January 04, 2008, 05:47:17 AM »

holy shid !
that's fast

, to anyone doubting to watch this movie: watch it!

Ziga · « **Reply #8 on:** January 04, 2008, 12:29:14 PM »

So you will make a tutorial about this robot that you're building?

hazzer123 · « **Reply #9 on:** January 04, 2008, 02:49:17 PM »

Yeah. Im entering it into the SoR competition so im obliged to make one!

ed1380 · « **Reply #10 on:** January 04, 2008, 04:20:46 PM »

ive seen people make their own tires for their robots out of some silicone. it was for robt sumo, so tractioon was necesary

Del · « **Reply #11 on:** January 04, 2008, 04:58:14 PM »

Quote from: airman00 on January 01, 2008, 04:53:09 PM

im interested to see the maze algorithm in pseudo code ( not in C or BASIC, in regular english)

I'd actually like to see your Matlab program code.

(I've got to put my copy of Matlab to some kind of use, since I never seem to use it

)

hazzer123 · « **Reply #12 on:** January 04, 2008, 06:19:56 PM »

Ive just moved to linux, so im gonna have to get MATLAB for unix before i can make is comprehendable. I have a really bad habit of writing in an illogical way if it takes less time

Give me a couple of days and ill post it.

paulstreats · « **Reply #13 on:** January 04, 2008, 11:10:23 PM »

Most undesigned code starts out illogically. Its a luxury to make it optimised.

You can start your code by using some kind of xml which is a very basic type of psuedo code and is easier with a notepad and pen, then develop it into a psuedo code and then to real code.

It sounds easy, but I am the type of person that will sometimes sit and develope code properly, and other times just start writing it from scratch - Admittedly, when i make it correctly with xml/psuedo code the results are better but you dont get the real coders satisfaction

Admin · « **Reply #14 on:** January 20, 2008, 05:19:26 PM »

Quote

200 steps/revolution means i can move the robot in increments of 0.5mm

actually, you can do better without changing the hardware

set up a timer on your PIC, and keep a variable that stores stepper steps per second. this is your 'velocity' . . .

now, by using the time since the last detected step multiplied by the known velocity, you now have a good estimate of the distance your robot is from the next step.

if done right, this software method will improve your stepper accuracy by a decimal point.

hazzer123 · « **Reply #15 on:** January 25, 2008, 04:38:05 AM »

Exams are finished now so i have time to do some more work on my micromouse.

I have just finished the CAD for my stripboarded circuit using Eagle. I used this tutorial to make a board that would work when transferred onto stripboard.

This method makes it much easier to create compact circuits using stripboard. Without it, my circuits are really messy.

The big capacitor, btw, is because this board supplys the power to the stepper motor driving board.

hazzer123 · « **Reply #16 on:** January 26, 2008, 07:06:04 PM »

I have finished the main board!

I didn't keep totally to my design which i did on eagle, since i decided to use I2C to interface with my stepper motor board as i am going to with the LCD. Also, since i didn't have an LCD or the money for one yet, I stuck a 7 segment LED display on for debugging. Its currently displaying the reading from the Sharp IR.

Im really happy with this board, i think that CADing it first made it easier and i have saved so much space on the board.

Next - stepper motor driver board. I purchased some ULN2003 darlington transistor array chips today, so they will go on along with a PIC16F628A i think.

hazzer123 · « **Reply #17 on:** February 03, 2008, 04:28:03 AM »

So i made the driver board. I used a PIC16F876A instead of a PIC16F628A because it has I2C hardware. It seems to work well,

Heres a video testing how fast i can get the bot turning. There is no acceleration with the motors, they go from 0 to moving a constant speed. Acceletation is desirable, because at some of the slightly higher speeds a few steps are missed at the start.

It is half-stepping, I tried full stepping, but the robot vibrated too much and skipped more steps.

[youtube]0Ax3JvDPET8[/youtube]

PS - The funny sound that you hear when the bot starts going wrong, thats the camera. It aint the bot or me

SmAsH · « **Reply #18 on:** February 03, 2008, 04:33:36 AM »

wow you can really pick up those skips!

hazzer123 · « **Reply #19 on:** February 03, 2008, 05:51:12 AM »

I have attached the assembly code for the robot's stepper motor driver board. For some reason, the attachment doesn't accept .asm files so i had to rename it to .txt.
This may help some of the forum members with their ideas of using stepper motors as there have been a few related topics recently.

Now i have to try to get my main robot controller board talking through I²C to my driver board... This, i suspect, will be more difficult...

Also, i need a name for my bot... hmm I'm rubbish at name making ....

airman00 · « **Reply #20 on:** February 03, 2008, 05:59:12 AM »

uchhh i remember when I had to use assembly ......... BASIC and C are much much better

also this might help you with names
http://en.wikipedia.org/wiki/List_of_fictional_robots_and_androids

hazzer123 · « **Reply #21 on:** February 03, 2008, 06:03:17 AM »

Yeah haha assembly can be a bit of a pain. I have been using C18 with pic18Fs recently, and yeah, its a breeze, but i wanted to refresh my mind on assembly. Sometimes knowing such low level languages can help in debugging.

Also i couldn't get some free software supporting my pic, for coding in C.

Cheers for the link, ill check it out.

hazzer123 · « **Reply #22 on:** February 04, 2008, 01:35:27 PM »

I have implemented velocity gradients into my micromouse, which means i have much more reliable steps than before.

[youtube]H6nO5O4UzFc[/youtube]

This acceleration in the video is 0.5ms^-2.

Rebelgium · « **Reply #23 on:** February 04, 2008, 01:46:21 PM »

perfect hazzer, really smooth.

hazzer123 · « **Reply #24 on:** February 04, 2008, 05:12:51 PM »

Ok, im trying to get the two boards of the mouse to communicate through I²C. Its proving really difficult...

I can't debug both simultaneously, since i have only 1 ICD

Can anyone upload any of their I2C code? Don't really care what language it is in. Does anyone have any good links? Any advice, or common mistakes?

Thankyou.

hazzer123 · « **Reply #25 on:** February 05, 2008, 10:41:15 AM »

I made some more progress on the mechanical side of my mouse today - the sensor mounting.

I wanted two sensors at the front, one on the right (looking left) and one on the left(looking right). This eliminates the chance that a wall in the maze is so close to a sensor that it outputs erroneous values. Also, angling the sensors, instead of having straight side looking sensors, makes it easier to calculate the orientation of the robot.

I didn't know what angle the sensors should be at, so i used hinges. I glued the hinges to the robot using double sided tape and screwed the sensors to the hinges with nut and bolts. Initially the hinges were quite slack, so i squeezed them in a vice untill they became stiff. This is to ensure the angle of the sensors stays constant.

Here are some pictures-

dunk · « **Reply #26 on:** February 05, 2008, 11:29:26 AM »

Quote

Can anyone upload any of their I2C code? Don't really care what language it is in. Does anyone have any good links? Any advice, or common mistakes?

it's a while since i did anything on a PIC but i think i got my initial i2c code from Microchips application notes. there was a multi-master application note in machine code if i remember correctly...
dig around here: http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2136&secgrp=PicMicro_sg&doctype=DeviceInfo&xdoctype=AppNote&prodprefix=pic

alternatively if it's not too late to switch to AVR i can supply you with code for that....

nice job on the bot by the way.

dunk.

hazzer123 · « **Reply #27 on:** February 24, 2008, 04:22:36 PM »

Well i decided to not to have 2 microcontrollers, one for the maze algorithms and one for the motors, and instead go with having just one MCU doing it all.

So ive made a new revised main board for the mouse.

To show the sensor input and motor driving working with the new board, i have turned it into a simple wall avoider for now. If i enter it into the robotics competition, it will have to go in as a wall avoider, since i havent yet been able to build a small maze or implement the solving algorithms into the PIC.

Here it is, avoiding objects

[youtube]1GWTPn1WyQw[/youtube]

Hmmmm, maybe i should have made it a bit faster... ow well. nevermind.

hazzer123 · « **Reply #28 on:** February 26, 2008, 01:36:21 PM »

I just tested basic Proportional control on my mouse.

The pseudocode is basically -

Code: [Select]

start of loop

error = left_sensor_reading - right sensor_reading;

ouput = proportional_constant * error;

left_motor_speed += output;
right_motor_speed -= output;

loop

Heres a video -

[youtube]k-RlJIol6Vg[/youtube]

When the mouse leaves the pathway, you can see it turn away from the window, to the right of the screen. This is evidence that the Sharp IR sensors don't have the background light filtering that some people have recently suggested in the forum.

Also, it keeps crashing when it approaches an object front-on. When i get another IR sensor, this should be fixed.

hazzer123 · « **Reply #29 on:** March 02, 2008, 01:56:58 PM »

So the competition has started and i havent yet made a maze solver...

I have started the tutorials though - http://www.societyofrobots.com/member_tutorials/node/94 (An example of what to expect)

Im gonna continue with this project. I was going to enter it as a wall-avoider, but its been done before, so id rather wait till next competition and enter a real robot.

Give your votes to the more worthy/finished robots!

Any comments/criticism on the current tutorials are welcome! Especially on the animations... Do you like them?

News:

Author Topic: Micromouse robot project. (Read 19734 times)

paulstreats