Solving Mazes using Floodfill Algorithm:

IEEE Micromouse Competition, April 2010:

Micromouse Maze Editor & Simulator:

The current demo of the simulator can be accessed from here: http://micromouse.reefat.com/simulator/

I was working for last couple of months to build one like this, and finally came up with the the following:

Ardumouse v.1

Ardumouse v.2

Ardumouse v.3 (Final Version)

I’ve been programming it to follow right wall and it worked perfectly:

Ardumouse: Arduino Micromouse – Right Wall Follower
Uploaded by reefat. – Videos of the latest science discoveries and tech.

Here’s another video that shows how the micromouse sends debug information to a remote computer through wireless:

Ardumouse: Arduino Micromouse – Wireless Debugger
Uploaded by reefat. – Technology reviews and science news videos.

And this the birth place of the micromouse, my bedroom. Don’t mind, it’s a little messy:

• 2 Joysticks
• 1 8-way D-Pad (Direction Pad)
• 8 Action Buttons, and
• 4 Extra Buttons (Select, Start, Macro, Mode)

So, I was searching on web, how to interface this PS2 Controller with Arduino, and finally found an Arduino compatible library called PSX Library. I used it with my Arduino and it didn’t work. I guess, it didn’t work because this library was for PlayStation 1, but my controller was PS2 compatible. So, I gave up this idea of using any library. It’s the time for me to come up with my own library.

Thereafter, I cut off the PS2 connector along with the long cable. This will be wireless, so why bother with this annoying cable/connector? This time I am not using any circuitry inside the Joypad. The only things I need are the Push Buttons, LEDs and the Joystick Potentiometer. Then I figured out the schematic of the two joysticks:

The approximate value for each Potentiometer is 5.2K. So, those 4 points will be used as Arduino Analog Input ( Pin 1 to 4 respectively). There was not really enough space inside the joypad, that’s why I had to use wire wrap wires to solder the connectors of buttons, potentiometers and LEDs. I was able to solder only 8 buttons, out of all 16; because the other 8 were so compact that they were almost impossible to solder. This 8 buttons and 2 LEDs will be connected to 10 Digital I/O pins on Arduino.

Here’re some pictures of the Modified Joypad, the Arduino board, and the Transmitter and Receiver modules:

I found some reference article on how to interface these RF Modules with Microcontroller. Here they are:

Running TX433 and RX433 RF modules with AVR microcontrollers
KLP/KLPA Module Walkthrough by Sparkfun
Implementing RF Modules

So, I followed the first reference (Running TX433 … …), and it worked without any problem. By the way, that example module was using 4-Bytes Packet Transmission Protocol at 1200 bps. I modified the code for Arduino, and as it worked with 2400 bps (because my RF Modules were little faster, 4800 bps).

My joypad has 2 joysticks and each of them has 2-axis (X and Y). So, it gives 4 analog inputs to the microcontroller and each input has a resolution of 1024 (0 to 1023), which requires 2 byes (integer) for each. And 2 joysticks needs 8 bytes (4 x 2 bytes). The 8 push buttons can be represented as 1 byte (1 bit for each button). The data transmission packet itself has 1 Synchronization byte, 1 address byte, and 1 Checksum word (2 bytes). So the length of the complete packet is 13 (8+1+1+1+2) bytes.

This time my code went real crazy. I tried to keep it clean and well-commented almost everything I could. As there are two separate circuits: the transmitter (joypad itself) and the receiver (Arduino Duemilanove); so there will be two separate scripts. But, I made the WirelessDataPacket class common for both. Here are both sketch source files:

Transmitter Sketch Source

Receiver Sketch Source

Everything was working cool when I was using 4-Bytes Transmission Protocol (as mentioned in the example reference). But when I am using 13-Bytes Packet, it became a lot slower and more than 50% (approximate) data is losing at the time of transmission.

I calculate the speed this way,

2400 bps = (2400/8) bytes per second = 300 Bps

300 Bps = (300/13) packets per second = 23 pps

Arduino uses 16.0000 MHz crystal (instead of 9.216 or 11.0592 or 18.432 MHz etc.) which can produce 0.1% error (ref: AVR BAUD Rate Calculator). And including some other circumstances (hardware+software) 5% error is acceptable. But for my case, the error rate is so huge that the transmission is breaking up and becomes too much slow. I guess, this can improve if the BAUD Rate of the RF Modules can be improvised and some other programming technique (which I don’t know yet) can me implemented.

Whenever the robot faces an obstacle in front of it, it looks left and right, and thinks about which side has enough space to go for. Then it turns to that side and moves forward. Check out the following video to see how the robot moves.

For programming the AVR, I am using AVRISP mkII In-System Programmer and AVR Studio Development IDE. The MCU Board has two I/O Ports – 8-Bit PORTD and 6-Bit PORTB, and 6-channel ADC. For PORTD and PORTB headers, the Vcc can be selected as either 5V or 6V, using the two yellow jumpers (red-marked). The board also provides 5V output headers to power up external device(s).

Supported AVRs: ATmega8, ATmega48, ATmega88, ATmega168.