In the October of 2006 (my 3^rd Semester), I attended one month long workshop on the classic 8051 microcontroller. The seniors conducting the workshop encouraged us to apply the knowledge we have gained and participate in some college techfest. With the IIT-Bombay’s Techfest being organized in the late January next year, I decided to take part in it. Now came the big question, in which event do I participate? After some extensive search and some over-optimistic thinking, I opted to go with The Micromouse Competition. Reason? It was damn challenging, since 2002 only two people were able to complete the problem! First prize was a cool 50,000 (~$1000) bucks….enough for a new electric guitar and some accessories!

So that is how I got the start. Once my semester exams got over in December, I was all out for Micromouse and formed a team with two of my friends. But before I move any further, let me first describe what actually a Micromouse is and why The Micromouse Problem is considered to be so difficult,

The Micromouse is a completely autonomous (NO external interference from outside whatsoever, on-board AI) and self contained (microcontroller + batteries + motors + sensors + everything else necessary on-board) robot that solves a given 16×16 cell maze and reaches its center. Each cell of the maze has a dimension of 18x18cm and the thickness of the walls is specified to be 1.2cm, their height being 5cm. The picture below should give you an idea how big the maze is,

The designer of the micromouse and the mouse itself don’t know how the maze is configured, each competition maze is different, of course! The mouse solves the maze in real-time, reaches its center, comes back to the starting cell, calculates the best path and then zooms back again to the center. Initially, the mouse solves or ‘explores’ the maze till it reaches its destination, i.e. the center. Once there, it comes back to the start while searching for the best path in the process. On coming back to the starting cell, it uses its on-board AI to calculate the best path. Once the best path is calculated, this time, the mouse ‘races’ towards the center (because it knows the path beforehand) and this is known as the ‘Speed Run’. Usually, the time allotted for all this activity in the competitions is 11minutes and the mouse can make as many speed runs as it feels like in the given time span. At some places, like the All Japan Micromouse Competition, the maximum number of speed runs has been limited to five.

To better understand this process of maze solving, check out the video below of the BR3 Micromouse (the fastest mouse of its time!)

BR3 – 26^th All Japan Micromouse Contest

The speed and precision of that machine is breathtaking!

If we remove the super high speed part, you might want to know what still makes this micromouse thing so difficult. Think over it, what are the stuffs that machine is doing in real time, all simultaneously

1. Precise Actuation → Tight Motor Control Algorithm
2. Wall detection → On-board highly reliable filtering of some sort
3. Maze Solving → On-board AI based algorithm that solves the unseen maze
4. Best Path Calculation → On-board Path Planning AI
5. Speed Runs → Extremely precise motor velocity profile generation

Think over these five points, designing a machine that can do up to point 3 (a ‘maze solver’) is an achievement in itself……a mouse that can reliably reach the center might very well be enough to earn you a place on the podium since most of the mice fail to do even that. And forget not, the cell dimension is just 18x18cm, everything must fit in your palm!!!

The micromouse challenges a designer to think in three totally different aspects of designing namely,

1. Mechanical → The Size and Structure
2. Electronics → Things that make ‘it’ happen
3. Firmware → The Intelligence part of the things

A little bit of thought will reveal that all three of the above influence each other! The mechanical size and structure restricts the kind of motors and batteries that are being used. Also, the size of the microcontroller, the size of the sensor, the overall size of the PCB comes into picture. The electronics and actuators used dictate the size and complexity of the firmware (or software). This analogy stands true if we go bottom up, expertise in writing the firmware can very well decide the kind of electronics that is being used, which in turn can surely increase or decrease the overall size and structure of the machine. Hence, as you must have figured out by now, a successful micromouse is an ‘Optimum Compromise’ of the above said three points and that makes it a remarkably challenging (and fun) activity!

Coming back to where we left, after a lot of ‘ifs and buts’ me and my team mates finally took a final decision to participate in the micromouse event. With absolutely no previous hands-on experience in making practical electronic stuff, we were definitely of the ‘adventurous kind’. In a mere one week of starting up, I realized that we can never make it in the given time span of one month, forget about winning the first prize of $1000! What made the matters complex was we could virtually get no help from our college, faculty had no idea how to make this kind of a machine. A few seniors had tried it before, but their machines never moved. They did help us in whatever way they could, but we were all on our own in the end. Amidst all of this, a self realization happened. I realized that I was loving all this stuff. Designing, creating, programming and redoing it all over again (since nothing seemed to work in the first go!).

Before the competition, we did manage to come up with something that looked like a micromouse, but it was a failed attempt that successfully taught us a hell lot of things. Our micromouse never moved. We had named it ‘Slash‘. All my subsequent micromice were named after my guitar idols.

After the IITB Techfest, my teammates decided to part ways with micromouse. I had fallen in love with it so badly that I decided to stay. I kept on designing/redesigning/modifying my designs and participated at various micromouse events in the country eventually winning a few. But the high point came in 2009, when I finally secured a 3^rd place at the IITB Techfest. The Techfest Micromouse Competition was (sadly, they don’t organize it anymore!) considered to be the toughest in the country because of the tremendous participation. There were some 180 odd teams when I came third! Counting major hardware modifications, I have successfully/unsuccessfully designed seven micromice till date. I’ll take a trip down the memory lane and list out all of my designs in chronological order, describing what went inside, what was special in them, what made them tick or what killed them!



SLASH →

In a crude form, this is how we wanted our Slash to look like,

But since we were supposed to design a Micromouse, we imagined him like this,

I used Rhinoceros v1.0 (released in 1999!) to design the above ‘proof-of-concept’ 3D models. I still use Rhinoceros v1.0 whenever I have to, its damn versatile for a simple 3D structure designer like me.

The Occasion →

→ IIT Bombay’s Techfest 2007 (last week of January)

The hardware →

The main processor was an 8-bit Microchip’s PIC16F877A. We decided to go with the top down sensing technique, where the sensors detect the top of the walls. We used the locally available Sharp GP2A22 proximity sensors which gives boolean output. Easy interfacing with the microcontroller dictated our choice for these sensors. We planned to do front wall sensing using Sharp GP2D02 distance sensor, which gave output in the form of a stream of digital pulses, but the sensor was not available in the country at that time and had to be imported from the USA. In the end, we managed to import Sharp GP2D12 and Sharp GP2D120. We went with the GP2D12 and GP2D120 because they gave analogue output, could have been ‘plugged in’ directly to the microcontroller’s ADC input pins, hence were simple to interface. Since they arrived very late, we were forced to go with the GP2A22. Remember that the contest was in the last week of January and we had roughly 4 weeks in our hand.

For actuation, we opted for the 1.8º per step NEMA 17 frame stepper motors from Shinano Kenshi. Stepper Motors are simple to drive and can be controlled ‘open loop‘. The stepper motors were interfaced with the microcontroller using a ULN2803 High Current Darlington Transistor Array. To provide power to this setup, we went with the Duracell 9V batteries.

The Hardware Mistakes →

The first and foremost thing that decides the performance of a micromouse is its electronic hardware and we had made quite a few mistakes in the hardware selection itself to be forgiven.

1. The PIC16F877A has a pretty small memory, if we want to write a code that can solve a maze. But since our firmware never reached such dizzying heights, let us forget about this one.
2. We had to struggle a lot to figure out and then procure the tool chain for PIC16F877A. We had to settle for a decade old C compiler because at that time there were no ‘student edition’ compiler versions from Microchip and a new one would have cost us a bomb (~$500!). The locally available PIC programmer was a costly purchase and turned out to be quite unreliable in the end.
3. We considered the bread board to be a gift to the mankind and used to conduct all of our experiments on the it. Little we knew that the bread-boards are highly susceptible to loose mechanical contacts and noise. Sometimes a simple led blinking program will go haywire due to this and we would end up spending the whole night trying to figure out the problem.
4. The stepper motors were rated at 5V but nothing was said about its current rating. Instead of measuring the coil resistance to figure out the current required, we naively thought it to be very low because the motor itself was rated only for 5V. We had absolutely no idea about how the stepper motors are driven and how much current they can consume. Now I know that those motors were rated for 1Amperes each!
5. Our ignorance regarding the stepper motor current rating lead us to another trouble, the ULN2803 driver. The driver is rated for 500mA peak current and we ended up destroying quite a few of these without having a clue as to what was going wrong!
6. Yet another trouble due to stepper motors, the Duracell 9V batteries are not supposed to discharge at a rate of almost 2Amps (one for each motor). They were just getting discharged very fast, in something less than 5min during the bread-board tests (which were quit a pain due to point 3).
7. We had no idea what a decoupling capacitor meant and noise was something we used to make in the classroom! After burning hands with the soldering iron, we made the whole test circuit on a general purpose PCB. This was our final design. Nothing worked. Obviously.

The Software →

Since our hardware was far from reliable, our software could never go beyond the basic stages of hardware testing like glowing an led based on an output from the sensors or simple running of stepper motors. We didn’t know how to use simple peripherals like timers and interrupts, so even if our hardware was stable our software couldn’t have gone too far without the use of interrupts.

For a change, our hardware mistakes didn’t allow us to make any software mistakes!

How it looked? →

The pictures below show Slash kept next to Vai, my second attempt at the micromouse problem. Slash was a very crude design completed in almost four weeks, huge in size and had a weight of more than half a kg with the batteries.

So, what killed him?

Everything! But if you ask me to blame one thing that was the cause of everything else, it was the lack of time. Practically speaking, four week’s time is just not enough for total newbies to make an autonomous maze solver.

Lessons Learnt →

Slash was a great opening first lesson for us. We understood that actually making things that work is a much more difficult (and fun) task than solving questions on the paper. Anything can become difficult if we go into too much theory but Slash made us realize that even a simple task of glowing a led through a microcontroller that looks easy on paper can become exceedingly difficult in practice if we don’t have proper knowledge and the right approach.




Vai I →

After returning from the IITB Techfest in January 2007, my friends decided to part ways with micromouse in search of greener pastures. I decided to carry on alone. For the most of the first half of 2007, my 4^th semester that is, I spent a lot of time in the library reading theory, the theory behind practice. In the summers, I attended a Micromouse Workshop at IIT Bombay itself, organized by TRI Technosolutions Pvt. Ltd. The same people who a year later, called me to their R&D center at IITB for summer internship.

In September, after 9 months of effort, Vai I or simply Vai, was born. My first micromouse that could go around a maze, sense walls and had some very basic maze exploration intelligence. Just that. It wasn’t a maze solver. It had a very slow speed, but watching your machine doing rounds in the maze is a hell lot of fun in itself. Believe Me.

The Occasion →

→ MindSpark ’07 (October), College of Engineering Pune’s Annual Techfest

The Hardware →

Learning from my Slash experience, I decided to not to design my own custom hardware but use the ready-made kit given to us by the TRI people during the workshop. Using a ready-made hardware kept me away from the hassles that come with designing your own stuff from scratch. This allowed me to concentrate wholeheartedly on the software for the mouse. The idea behind this approach was to first make sure that I have a fully functional mouse that goes around in a maze and perhaps later be able to solve it, then design killer hardware that has a powerful processor, reliable sensors and dedicated specialized stepper motor drivers. Thankfully, this approach payed off big time, read on. The hardware had the following ingredients,

1. iBoard AVR – The Atmel’s AVR ATMega32 based motherboard, taking data from the sensors, making decisions and driving the stepper motors.
2. Micromouse Side Wall Sensors – Tailor made distance sensors for micromouse. Give analog outputs and have a range of roughly 15cm.
3. Stepper Motors – Small NEMA17 frame, 12V/160mA, 1.8º step angle stepper motors.
4. 12V NiMH Battery Pack and Battery Charger.

Notice that I had now shifted to the AVR microcontroller, who’s tool chain is freely available on the net.

The Software →

Vai essentially did a fairly simple task of slowly moving exactly one cell at a time while simultaneously keeping itself aligned in the middle so that it doesn’t hit the maze walls and sensing their presence or absence and taking 90º or 180º turns wherever necessary. Instead of making it a sports car, focus was on making Vai a very reliable machine that can go around a maze a hundred times without hitting the maze walls. Simple enough.

The firmware was not so simple though. To perform all of the above said operations, Vai had a sophisticated interrupts based software architecture. Critical tasks like stepper motor driving and sampling data from the sensors required careful interrupt synchronization and acute software writing skills. Special care was taken to make sure that the interrupt routine driving the stepper motors had a precise timing and was not obstructed by other interrupts being generated in the processor. Locking the stepper motor driving interrupt routine precisely with the data acquisition (from the sensors) interrupt routine made the software relatively complex.

The Looks →

I tried to keep the mechanical design of Vai as simple as possible. The whole micromouse was created by sticking together all of its components. There was no chassis as such. Not the best method, but a very fast one. Replacing the batteries or the motors was not possible at all as they formed the very base of the whole mouse and were stuck together. Just in case if the electronics failed, the sensors and the motherboard were mounted on an acrylic base (which was stuck to the motors and batteries) for easy replacement. Wheels could also have been replaced if necessary. My theory behind this kind of structural design was that you seldom use batteries during design and testing phase. There’s usually an umbilical cord supplying power to the micromouse. Also, steppers motors are very rugged and are not supposed to fail, at least I had never heard of a stepper motor getting destroyed in such a delicate application. So sticking together the motors and the batteries provided a quick method to build the chassis and the rest of the mouse. Since there are two wheels, I had made my own custom skids for the mouse which were also stuck to the batteries. The skids were made out of pencil erasers in which rough dome shaped spaces were carved and ball bearings were stuck in these carvings. Use of ball bearings ensured that the skid surface was rounded and smooth, and hence the friction between the skid and maze surface was minimal.

Vai weighed less than 350gm, was a cube of about 12x9cm having a height of almost 6.5cm and was very slow. But it was serious fun to watch him doing rounds on my homemade test maze. Have a look,

Vai I in Action

The Result →

Vai I successfully cleared the preliminary round of the Micromouse Competition at the MindSpark ’07. In the finals, it couldn’t make it to the center though. Official rankings were given only for the first three mice, Vai I finished 6^th overall.

Lessons Learnt →

Building Vai I was a very satisfying experience. Writing software was the main task and was very challenging indeed. Vai I was not a maze solver but had enough intelligence to traverse a maze and try to visit each and every cell. Thinking behind was that at some point, it would eventually reach the center. Vai I failed to do so in the finals not because of the software, but because of the sensors.

In simple terms, the sensors had emitter LEDs that emit red modulated light and receiving photodiodes which measure the amount of modulated red light reflected back. The output of the sensors was directly proportional to their distance from the maze walls. Inside the software, threshold levels were set for each of the three sensors. Output from the sensor above its corresponding threshold level indicated the presence of wall or vice-versa. Now consider a situation where different maze walls have different reflectivity, and this is usually the case in competition mazes. Expecting every maze wall to have exactly the same reflectivity is impractical. In such a situation we try to come to an ‘average value’ for the threshold levels, but still, a single black sheep in the crowd can let us down. This is exactly what happened in Vai I’s case. The unsuspecting micromouse rammed into one of the maze walls that had a rough surface. Since the mouse was not equipped to recover after an accident (I have seen only one such mouse till date, a Japanese one I remember), it required a ‘touch’ and that meant the mouse had to be restarted from the starting cell. So, I couldn’t do much but to look at Vai fail again and again at that rough patch of the maze.

Now the need of the hour was to incorporate a more robust wall sensing hardware and software.




Vai II →

After MindSpark, in just a month’s time, Indian Institute of Information Technology (IIIT)– Allahabad had their micromouse competition at their annual fest, Effervescence. Learning from the Vai I experience, I made a clever change in the sensor hardware. Remember for Slash we had imported Sharp GP2D12 and Sharp GP2D120 sensors from USA but couldn’t use them as they arrived very late. Now was their turn. Given the short time span in which I had to solve the issue, I figured out that the main culprit behind the mouse ramming into the maze walls at MindSpark finals was ‘Forward Error Correction‘, rather the lack of it. The problem was with front wall sensing. I decided to put a single Sharp GP2D120 sensor for front wall sensing which shall work in tandem with the TRI micromouse sensor.

Occasion →

→ Effervescence ’07 (November), IIIT-Allahabad’s Annual fest.

The Hardware and Software →

Vai II was a modification of Vai I at sensor level. The hardware stayed exactly the same, only a Sharp GP2D120 sensor was added for more robust front wall sensing. On the software front, modifications were made in the data acquisition interrupt routine to accommodate for the GP2D120. Also, clever changes were made in the data filtering and final wall presence estimation routine to make sure that added redundancy provided by the extra sensor resulted in a more reliable and robust wall presence estimation.

The Look →

The only change between Vai I and Vai II was that Vai II had a GP2D120 attached on the right side of the TRI’s Micromouse Sensor. The sensor was kept a little backwards so that it does not obstruct emitter light from the TRI’s sensor.

The Result →

Jackpot!

The idea worked exceedingly well and Vai II won First Place at Effervescence ’07! The micromouse was awfully slow and took roughly six and a half minutes to reach the center, but it was very satisfying and rewarding nevertheless.

How Sharp’s GP2D120 made all the difference?

The TRI sensors I was using and almost every robotics related sensor out there in the market works on the principle of emitting something and giving the output according to the amount reflected back. This implies that when working in the stated range, its the obstruction’s surface’s reflectivity that dictates the output from the sensor. In a maze, uneven surface reflectivity can obviously spell the doom for a micromouse.

Sharp’s GP2D120 have something called as a PSD or Position Sensitive Device as a sensing element. GP2D120 emits an Infra Red beam and it falls on the PSD after getting reflected back from the obstructing surface. A PSD gives an output according to the spot where the reflected Infra Red light falls on its surface. The output DOES NOT depends on the intensity of the radiation and hence, is unaffected by uneven surface reflectivity. Read the article on Sharp sensors from Acroname, it ‘demystifies’ them well!

Talking in terms of fast moving robots (and micromice), these sensors do present a very strong limitation on the speed of the robots because of their lazy response times. GP2D120 updates at a rate of mere 26Hz! The micromouse in that Japanese competition video you saw achieves speeds in excess of 5m/s. If that mouse was using these sensors then in 1/26^th of a second, the time between two consecutive readings, it would have moved almost by 19cm. That’s more than the length of a unit cell in the maze!

Lessons Learnt →

Hard work coupled with clever thinking pays off!




SATCH →

Satch was my entry for the Micromouse competition at IIT Bombay’s Techfest ’08. Given the fiasco last year, I was determined to make a difference this time. My Vai series of micromice had a ‘very ready-made’ hardware, something that is prohibited at the Techfest. With the only exception of sensors, I decided to completely revamp the design in terms of both, hardware and software.

The Occasion →

→ IIT Bombay’s Techfest ’08 (January)

The Hardware →

By this time I had acquired a decent amount of knowledge regarding motor driving and voltage regulation. I had come to know about various stepper motor driving techniques that could have helped me design a real fast micromouse. DC-DC voltage boosters to step up the stepper motor driving voltage. Lithium Ion batteries that are very light weight, have a huge charge storage capacity and can deliver large amounts of current (to the hungry stepper motors). PonyProg, a simple serial port programmer for the AVR microcontrollers that I could use to program my own custom circuit. Also, I came to know about buck mode switching voltage regulators that are more than twice as efficient than the LDO’s (e.g. 7805) that I had been using so far for voltage regulation. With almost one and a half months of time in my hand to design and develop, I decided to incorporate all of this into my new micromouse.

Starting from the bottom, four 3.7V Li-Ion cells connected in series (14.8V) were supposed to power the Satch. There were two 3V/1A 1.8º step angle stepper motors driving the whole system. Initially, they were supposed to be powered by a DC-DC boost converter that would ramp up the supply voltage to around 35-40V. The thought behind was that driving the stepper motors with more than 10 times the rated voltage will result in some serious speeds but later on during the development however, the idea was scrapped because of increased circuit complexity. The boost converter worked, though. The stepper motors were supposed to be driven by a stepper motor current chopper drive made out of a Sanken SLA7062. But due to high cost of the IC and some technical difficulties, I had to settle with the big and bulky classic combination of L297-L298. I kept the main processor same, an AVR ATMega32, powered by a 5V buck mode switching voltage regulator. The sensor module was also kept the same, TRI sensors coupled with a Sharp GP2D120.

I started off by building and testing the basic ATMega circuit on the bread-board and kept on adding the various motor driving and voltage regulation features. A point in the development phase was reached when the testing circuit became so big that there were four bread-boards to cater to its huge size. Everything was on the bread-boards, the chopper drive (both SLA7062 and L297-L298 based), the voltage booster, the buck regulator, the programmer and the ATMega circuit. I had even designed a Li-Ion battery charger, didn’t work though. Following pictures should give an idea how the whole test bench looked.

This is the DC-DC Voltage Booster at work,

The mammoth sized test bed,

at a slightly different angle,

The Chassis, which is essentially two back to back stepper motors and batteries, all stuck together.

The ATMega32 based motherboard, the chassis and the motor driver board,

The following video shows the stepper motor current chopper drive at work on the test bed, 

Flip side of the motor driver board

The Software →

The software that I had for Vai II could have been used here too, but I decided to improve upon it too. As I have stated in one of my previous articles, ‘The Modified Flood Fill Simulator’, I teamed up with one of my juniors, Manish Sharma, to design a simulator for the Micromouse. I thought this was the time when I should inject some real maze solving AI into my robot. Manish did come up with the basic architecture of the simulator, but in the end I ran out of time to do anything meaningful with it. It was after coming back from the techfest that I worked on the maze solving algorithm development. Rest of the history has been stated in the above mentioned article.

The Mistakes →

At the bottom of it all, there was one seriously wrong decision, I was trying to do too much in too little time! Given the time frame of one and a half months, I was being over-optimistic that everything would work out in the first shot, when almost everything I was doing was for the first time. In reality, nothing went right in the first instance. Let us make a list,

1. The ATMega’s basic circuit worked fine on the test bed, but the very simple PonyProg just won’t work. After a few nights I realized that was due to a faulty zener diode. Lesson → Always check the components before using them!
2. The SLA7062 turned out to be a hard nut to crack even though it had a fairly straightforward circuit and I don’t know why. The crazy speed some Japanese mice had achieved using this baby drove me mad and only after spending almost a week on this motor driver I finally decided to let go. Lesson → NEVER get carried away!
3. The L297-L298 had an elaborate circuit, there were quite a few sleepless nights before anything showed any signs of movement.
4. The voltage booster wasn’t softer on me either. After a lot of maths, I figured out that boosting 14.8V to around 20V was the practical thing to do given the huge amounts of current required by the stepper motors(1Amp each!). That experimental setup in the picture where I configured it up for almost 40V could only supply less than half amperes of current. It took me quite some time to realize this.
5. I was using Lithium Ion batteries in Satch. They require a dedicated charger. The Maverick in me made think that designing my own Li-Ion charger won’t take much time and I’ll be saving a lot of money on a professional charger too. Sadly, the charger sub project failed big time and I just couldn’t get it functioning the way I wanted. But not before wasting a precious 4 days! In the end, I had to purchase a ready-made charger. Lesson → Time is usually more costly than money!
6. Spending a lot of time on hardware left me with virtually no time to make any significant software change or modification.

I had spent so much time in experimenting and finalizing things on the bread-board that I was left with just a week in the end to assemble everything on a general purpose PCB and do the final ‘in-maze’ tests. I was simply out of time by now. Not giving up hope, I took out my soldering iron. I soon realized that given the very little time I had, a voltage booster on-board will unnecessarily complicate matters. It was scrapped and that meant all that time I spent in making that thing also got scrapped! I must admit poor planning on my part.

Finally after working day and night the whole thing took shape. With hardly two days in hand, during the testing I rammed into this severe but strange problem where one of the steppers were having a low torque than the other. I tried hard but just could not figure out what went wrong. It was only after discussing the problem in the Micromouse Forum, I came to know what exactly went wrong. But the discussion took place after I came back from yet another unsuccessful trip to the Techfest.

The Looks →

Satch was bigger and bulkier than Vai primarily because of slightly larger and much more powerful stepper motors and a separate motor driver board. It was heavier too and weighed almost half a kilograms. The overall look of the micromouse clearly gives an indication that not enough time was devoted in manufacturing the whole structure.

Lessons Learnt →

Satch was a great ‘Project Management and Planning’ lesson for me. I got carried away by the success of Vai I and II, became over-optimistic and over confident, got carried away more than once, eventually failed miserably. But I am glad that things happened the way they did, an unsuccessful attempt teaches you a lot more than a successful one! As Dalai Lama once said, ‘When you lose, don’t lose the lesson’.

As a special note I would like to thank Manish Sharma, a first year student at that time, not only for designing the simulator but also for being a part of the complete design process and for his ideas and suggestions.




Vai III →

After coming back from a very disappointing Techfest ’08, I got my head down almost immediately for my next Vai series micromouse. The Micromouse competition at Zealicon, the annual techno-cultural fest of JSS Academy of Technical Education (or JSSATE, my college!) was just two months away. Initially, I spent a few days figuring out the various problems I encountered with Satch. Then finalized a few hardware modifications for Vai III and started off exactly from where I left.

The Occasion →

→ Zealicon ’08 (March), the annual techno-cultural fest of JSS Academy of Technical Education, Noida.

The Hardware →

Learning from the Satch experience, I kept my feet on the ground this time while making some major hardware modifications which were ‘doable’ in two months.

1. The TRI’s ATMega32 based development board used in Vai had L923D as motor drivers. These things perform good for DC motors and can be used with stepper motors too, but they lacked the ‘performance edge’. Hence, I decided to ‘hack’ the TRI board and put up my own set of dedicated stepper motor drivers. The (now unavailable!) UCN5804 was the easiest option.
2. Instead of using a single Sharp GP2D120 sensor for front wall sensing, I went for a complete sensor overhaul and put in three GP2D120s while removing the TRI’s Micromouse sensor completely.

As stated before somewhere in this article, Sharp sensor’s slow response meant that Vai III can never achieve that sports car like performance. But nevertheless, the sensor’s sluggish response never came into the picture, reason being the stepper motors rated at 12V. With a 12V battery pack, there was no question of overdriving them to get high speeds. That’s why I stated before, Vai was never designed for high speeds. UCN5804 did help in getting a better performance from the motors, but more importantly, stepping was very smooth.

This is the stock iBoard AVR from TRI,

This is how it looked after hacking,

The top and bottom sides of the UCN5804 PCB,

The PCB was manufactured through a manual process at my college’s PCB lab by a rookie (called Me) which explains the messy look!

The UCN5804 motor driver board sitting on the motherboard,

During the design phase,

The Software →

Thanks to the Satch experience, this time I had a lot of time in my hands to make some critical software changes.

1. This was the first time I implemented stepper motor velocity profiling in the firmware for a smoother robot movement.
2. The simulator that was designed before the Techfest, gave results now and I was ready with a true maze solving algorithm.

These software advancements turned Vai III into a true AI based sophisticated autonomous maze solving robot. Slow but a Very Cool robot!

The Looks →

Vai III had a similar hardware setup like all of its predecessors but had a different look and feel to it because of the new sensor assembly and the added motor driver board.

In the video below, Vai III is ‘patrolling’ in my practice maze. The control algorithm that was designed to keep this machine aligned with the maze walls at all times can be seen at work here.
The Result →

→ Vai III got 1^st place at Zealicon ’08.

Lessons Learnt →

Smart management and planning are instrumental in any project’s success (or failure)!




Gilbert →

I was in my final year of engineering now and every micromouse competition I was going to participate in was going to be my last. I needed a machine that can make a difference. A micromouse built for speed was on my mind. I started working seriously towards it when I went to IIT Bombay for my internship at TRI. This mouse was going to be my entry in Effervescence ’08 and The Techfest ’09, I was preparing early this time…..in case the lightning strikes!

 

The Occasion →

→ Effervescence ’08 (November), IIIT-Allahabad’s Annual fest

→ IIT Bombay’s Techfest ’09 (January)

The Hardware →

Gilbert’s hardware was designed for speed (more than 1m/s), hence the size was kept small to make sure weight doesn’t cross a self imposed limit of 300gm. I built a custom circuit and PCB for Gilbert. Special thanks to the folks at TRI for manufacturing the PCBs for me free of cost. The hardware was totally revamped, listing out the changes :-

1. I finally moved to a relatively more powerful microcontroller in terms of memory and peripherals, The ATMega128.
2. Instead of going for the big and bulky L297-L298 combination or the SLA7062, I went for the very small, simple to use and highly efficient Allegro A3982 stepper motor driver.
3. For Gilbert, I started working upon my own set of sensors. But after quite a few attempts failed to yield the desirable results, I went back to the good old TRI sensors.
4. In order to keep the size and weight down but not compromising with the torque, I went for small but powerful bipolar stepper motors.
5. A 5V buck switching voltage regulator was designed and was kept on a separate PCB in order to keep things a bit simple on the motherboard.

Given that I was about to participate for the last time in various micromouse competitions, my preparation for Gilbert was very elaborate. I followed a very methodical approach starting from PCB designing, 3D visualization, circuit simulation (for sensors) and card board prototyping to visualize the design in reality.

Here’s the circuit layout on Eagle PCB Layout Editor,

In the software I used A3967 for designing the circuit as they have the same package as A3962 (which was not available).

3D visualization of the board using Eagle 3D and POV-Ray,

Top Side

Bottom Side

The Cardboard prototype had the sensors attached too, but they were later scrapped because of undesirable performance.

Here are the manufactured PCBs,

5V Buck mode switching regulator PCB,

After soldering the components,

Motherboard after soldering of the main ICs,

Motherboard after complete soldering of the components with the power regulator PCB,

The Mistake and Two Deaths →

The heading sounds like a name of a chapter from some Harry Potter book!

I was testing the PCB sometime in late October, for Effervescence ’08, I noticed that the ground voltage at some points on the PCB was too high. When I tested the A3982s, the left one worked but the right one just won’t fire up. After going through the datasheet again and again I figured out that as soon as I was powering up the motor driver, it was going in the ‘shutdown’ mode due to an undervoltage condition on ‘VCP’ pin. Further investigation revealed that ground voltage was so high (more than 1.5V!!!) that the internal charge pump in A3982 was not able to step up the voltage high enough to drive the DMOS gates. I tried replacing the A3982 motor driver thinking that the IC might have been damaged but nothing worked. I tried everything possible, even put up a query in the CNCzone forum, hoping that something will work out. Fact was, Gilbert was dead!

Before Gilbert, I had designed small PCBs for Vai III and for a regular course work project. But unlike Gilbert, those designs were single sided and very simple. Gilbert’s PCB was a mixed signal design, i.e. it contained both the analog and the digital signals. Moreover, the analog signal lines from the stepper motor driver ICs carried high amounts of current (almost 1.5Amps) and since it was a current chopper driver, switching of such a large amount of current resulted in a lot of noise in the ground lines.

It was only a month later after coming back from Effervescence ’08 I realized that Gilbert’s PCB required a very careful layout and routing in order to work perfectly, something I had no idea about whatsoever. Till now, designing a PCB to me was as simple as connecting the dots! While designing the PCB, I made one big ground plane and connected all the ground signals to it irrespective of from where they were coming. I had no clue about the standard mixed signal PCB layout and routing practices, keeping the analog and digital ground lines away from each other, the concept of star ground, keeping the analog and digital ground planes separate etc.

As Gilbert was no more and there was hardly a week left, I had to rely on Vai III for Effervescence. Remember when I started building mice, I had this notion that stepper motors are very rugged and can probably never malfunction unless and until they are deliberately destroyed. I was wrong. The stepper motors in Vai III were the same that I had been using since mid 2007 and they tragically broke down in the competition finals. Result was that I lost out on first place and had to settle as a runner-up. For the time being, Vai III was dead too (later, replacement of motors revived him though).

Lessons Learnt →

With preciously little time left for my last Techfest (’09), there was a lot to learn from the mistakes I had made in Gilbert. Challenge was in learning fast and correcting those mistakes in that short span of time which also had my semester exams in between (December).

Tragedy with Vai III taught me why a car has 5 tires!




SLASH II →

It was late December in 2008 and I was confronted by the same situation for the third time in a row. Roughly four weeks in hand and had to design a maze solving machine from scratch. The only difference this time was that I had a history of making mistakes which were now a part of my experience and knowledge that I had gained in order to correct those mistakes.

Past experience (or mistakes) had taught me by now that I had no time for experimentation, whatever I do must be done perfectly in the first shot. With my fingers crossed, I relied on my knowledge that things will come out perfect in the first go. Planning out the hardware and the software was the key. I spent the first week in chalking out a strategy, thinking and rethinking over the hardware and the software issues that might creep up during the development process and ways to avoid them while keeping an eye on possible alternatives (car’s 5^th tire!).

Hardware →

My target was to design and completely test the hardware in just one week so that I had at least one week in hand for software development and in-maze testing, I kept one week in buffer just in case if something doesn’t work out with hardware or software.

Even after two years, Slash was still there on my table and now the time has come for him to give way to his successor. I worked out the basic hardware architecture in such a way that it involved only the best from all of my previous mice. Remember the stepper motors we used in Slash, they were rated at 5V and I later found out that their coil resistance was 5Ω, hence rated current was 1Amps. Such low voltage and high current stepper motors can be easily overdriven to achieve high speeds and have a very high torque. Slash’s stepper motors were now Slash II’s stepper motors. That’s the reason why I called this micromouse Slash II.

With the stepper motors done, I shifted focus on the sensors. I realized that the TRI’s Micromouse Sensors that I had been using in Vai I and Vai II were pretty good and with the good filtering technique I had developed over time, the extra Sharp GP2D120 was not required. Discarding the GP2D120 meant discarding that slow 26Hz sampling and that implied high speeds. Slash II now had eyes.

The motors and the sensors were now finalized and so far there had been no compromise with the speed. Selecting a proper motor driving technique to utilize them was the key. With all the little time I had in my hand, I decided to go back to the motor drivers I used in Vai III, A3982. But A3982 is not a current chopper IC so I had to think of something that can still make my motors go fast. Learning from experience and keeping the KISS (Keep It Simple Stupid!) principle in mind, I kissed the L/R drive method. As stated in that Wikipedia article, the L/R drive method is low performing, wastes a hell lot of power but simple and cheap. That’s exactly what I want, simple and cheap!

Atmel’s 8-bit AVR ATMega32 had served me well since the days of Vai I and hence was my choice of microcontroller this time too. Changing the processor meant re-writing all the previous code (Vai I/II/III) that I could have utilized here by a simple copy-paste. By this time, i.e. the end of 7^th semester, I did had some experience with the 32-bit PIC32 Microcontrollers from Microchip, but not now! The ATMega32 and other on-board circuitry, except the motors, required 5V of regulated power. I could have gone with the simple LDO regulator, 7805, but these things are highly inefficient (typically less than 40%!!!). Given that I was already going with the L/R drive method, going with 7805 would have made my PCB a hot plate! At this point, I remembered that the Gilbert PCB failed big time, but its 5V Buck Switching Regulator PCB. These switching regulators have efficiencies in excess of 80% and hence it was obvious now, that SLASH II’s regulated power was going to come from Gilbert.

Only one thing was left now, the power source. Battery selection was critical to the performance of this micromouse now. Opting for L/R drive meant that my resistors could have doubled up as room heaters! Hence, a high capacity battery pack was required but at the same time the weight should be less. I opted to go with 800mAh Lithium Ion Cells. I already had a charger for these that I purchased during the development of Satch. I made two battery packs of 4 cells in series, almost 15V each and then put them in parallel, this effectively doubled up the total battery pack charge to 1600mAh. The stepper motors were rated at 1Amps each and the rest of the circuitry hardly consumed 0.35A, hence the total theoretical current requirement was roughly 2.5Amperes. A 1600mAh battery pack should ideally be able to supply 2.5Amperes of current for almost 40mins but the batteries on-board Slash II used to give up in almost 15-20min, just enough for the competition! The reason was L/R drive. Let me show you how,

Resistance of Stepper Motor’s Coil (Rc) = 5Ω

Voltage Driving the Motor (Vm) = (3.7 X 4)V

= 14.8V

Hence, total induced current in the coils (Im) = Vm/Rc

= 2.96A

Quite obviously, 2.96A of current will deep fry the stepper motor’s coils which were rated for 1A of current.

Following the L/R method, 10Ω resistors were kept in series with the coils to bring down the current to its rated value and prevent the motor coils from burning up.

Hence, total effective resistance (Rt) = 15Ω

Net current flowing through the coils (In) = 0.99A (exactly what was required)

Power converted into heat by the series resistors (Pr) = In² X 10Ω

= 10W (Room Heaters indeed!!!)

Total power ‘wasted’ by the two motors = Pr X 2

= 20W!!!

It is this 20W of wasted power that is bringing down the run time of the batteries from 40min to 20min! (It should also be noted that the total power consumption of the stepper motor drive is a whopping 30W)

Going for the ATMega32 offered me an advantage of designing the whole circuit on a general purpose PCB, the method was fast as I could solder the components directly without going into the hassles PCB designing. Also, this time I decided to build a chassis, albeit a simple one. A nicely designed chassis ‘might’ help your mouse to automatically recover in case it rubs against a wall. Do check out Slash II’s competition video, chassis did came into play!

Slash II’s hardware was designed and fully tested in a record time of 9 days. Target was 7 though (I had taken 2 days off of that buffer week). The motherboard had separate connectors for in-circuit programming, serial UART connection and for a 16×2 LCD. I designed a separate LCD module which would plug-in to the motherboard. Keeping the LCD circuitry off-board helped me keep things simple on the motherboard.

The following ‘schematic’ of SLASH II’s hardware will give a better idea of what came from where,

Alongside pictures show how SLASH II’s Motherboard, chassis and rest of the assembly looked in a b.i.t.Wise!™ Format.

The Software →

I roughly had a dozen days in hand (including the buffer week) to design and test the firmware for SLASH II. Of all my previous designs, Vai III had the most sophisticated program, capable of generating stepper motor velocity profiles and solving a maze using modified flood fill. I decided to improve upon this code with the intention of adding speed runs as the stepper motor tests showed that SLASH II could achieve speeds reaching 1m/s or maybe more.

I realized that Vai III’s stepper motor velocity profile generation code was not good enough, the motors were not able to achieve high speeds consistently and were going out of synchronization. During my quest to improve it, I came across this wonderful application note from SI Labs, AN 155. The application note had a detailed information regarding stepper motor basics and generating linear velocity profiles. After going through it I realized that Vai III’s stepper motor velocity profile generator was not linear in nature and that is why when I was trying for higher stepping rates, the motors were going out of sync. Linear stepper motor velocity profile generation was the first improvement in SLASH II’s firmware.

New profile generator did wonders to the maximum possible stepping rate. I was now getting speeds close to 1m/s but the problem was of controlling such high speeds inside the maze. The basic control system that kept mouse aligned with the maze walls was not designed to handle such high speeds. I tried on a few things but I couldn’t get the reliability I was looking for, given the critical amount of time in hand, I decided to keep the machine slow for competition. I felt instead of getting carried away by speed once again, I should concentrate on reaching the center.

The modified flood fill code worked pretty well and was good enough to solve any given 16×16 cell maze, but on the simulator I noticed that the micromouse used to take a long time to solve the maze and reach the center and moreover, it used to visit parts of the maze where it had already been. This type of redundancy in maze exploration was rather unacceptable. Instead of trying to make amends in the modified flood fill algorithm, I cured the problem by adopting the standard Flood Fill Algorithm and going with the wonderful method described by Peter Harrison over here. The method not only solved the problem of redundant maze exploration behavior but, as already stated in the slides, turned out to be highly efficient in terms of machine cycles taken to compute the path to the center. With full optimization on the WinAVR compiler, the code took roughly 12ms to compute the path on an ATMega controller running at 16MHz.

Developing a speed run routine (with slow speed!) was a rather simple task once the flood fill problem was resolved. Neglecting the speed which remained unchanged, the routine was supposed to bring the micromouse back to the starting square once the way to the center was known and then start again for the center but without exploring the maze as the path was already known this time.

This was all the intelligence that was put in SLASH II for the Techfest ’09.

After returning from the Techfest, with the craving for that speed still inside me, I worked on its control system and came up with a new technique. Result was a pretty fast micromouse on the test maze. Check out the video,

I believe that better speeds can be achieved with an improved linear velocity profile generator and a more sophisticated control system.

The Looks →

SLASH II was a compact, heavy but a smart looking average palm sized beast that weighed close to 450gms. Apart from the obvious weight of stepper motors, it was the weight of those two battery packs working in parallel that had the maximum contribution to its weight. Also, instead of going with the usual pencil eraser and ball bearing setup as the skids, this time I used simple Drawing Pins for the sleek look. Note that I took these pics while writing this article, SLASH II is almost two years old now which explains the kind of messy and worn off look.

The Result →

→ SLASH II was placed 3^rd at IIT Bombay’s Techfest ’09 (but unfortunately couldn’t make it to the center!)

Why SLASH II failed to reach the center?

…and how come he still managed to get the podium position?

Out of 180+ participants, only two were able to complete the problem and reach the center. That too, the first place went to a pretty fast DC Motor based micromouse from Sri Lanka (to everybody’s surprise!). Look at the video of the final competition below and you’ll will realize that SLASH II came quite close to the center. Hence, on the basis of maximum unique cells traveled, SLASH II secured a 3^rd place.

Notice what happened at 4:05. The mouse rammed into a right wall, thinking there wasn’t any wall, but thankfully recovered because of the chassis. Recovery was only physical though, algorithm working inside was thinking that the mouse has moved into the next cell, but it didn’t! The algorithm got fooled because the stepper motors are operated ‘open loop’ and there is no feedback from the wheels to know whether the mouse has really moved or not. Hence, all the maze mapping going inside SLASH II’s mind went haywire and it kept on roaming around fruitlessly. I think there was something seriously wrong with that maze wall because later SLASH II again bumped into it while tracking back.

Question is why SLASH II bumped into that wall, twice. Obviously, the wall’s surface was less shiny than probably every other wall in the maze. I believe that that accident could have been avoided if I was a bit more lenient in deciding the sensor threshold levels. Unfortunate…..but Nevermind! \m/ \m/

Lessons Learnt →

Perseverance.

Even though the performance of my micromouse at my last Techfest was below than what I had expected, I was satisfied and relieved by the result. A podium finish. This is what I was working for, for complete two years!

As it turned out, micromouse was not just a robot, it was a teacher for me. A great learning experience that cannot be substituted by anything else. I still work on it whenever I get time, which I hardly get, finally got some success with the sensors a few months back. Truth be told, I still crave for that anxiety before the competitions, that adrenalin rush before the finals, that exhilirating feeling when my machines were navigating the maze, when I fondly remember those days…..those were the days…..The Micromouse Days!

As a concluding note, I would like to say that I have plans of open sourcing all the technical details of SLASH II, hardware and software, but not just like that. Rather, in the form of a complete tutorial on Micromouse. A tutorial on AVR microcontrollers and one on micromouse is my plan for 2011. Let’s see how it goes.

Thanks for reading…….this one was lengthy!