MicroMouse Robot

[ryantm]

I thought you said the problem happens when you are using batteries. Can you reproduce the problem with a power supply? Or does it only happen on battery power? What is the voltage of your batteries when it happens? If your motors draw a lot of current when your batteries are low, you will get large changes in battery voltage.

Posting a video on YouTube would let us all see your problem, but if you want to email it, you can email it to ryantm at pololu dot com.

- Ryan

[CraigB]

End of the semester really got to me. Solved the spinning problem by slowing the motors down. Is there a good tutorial on using the A to D converters. I need 2 channels for analog distance sensors.

--Craig

[Ben]

Hello.

I don't know of any good tutorials, but reading the ADC channels is pretty easy. You should take a look at the ADC section of the ATmega644 datasheet, and the demo program under the resources tab of the Orangutan X2 product page reads from the ADC. You can also take a look at the source code for the OrangutanAnalog section of the Pololu AVR library. This code works on our new Orangutan SVP-324, so it should also work on the Orangutan X2. If you need some help understanding how it works or how to copy it into your project, please let us know.

- Ben

[CraigB]

I am having trouble finding a way to access the analog channels. I have an analog sensor connected to the main I/O header (D header) and I am trying to figure out how to get it to a channel to the AD converter.

[Ben]

The analog inputs on the ATmega644 are pins PA0 through PA7; these comprise analog input channels 0 through 7, respectively. Note that PA6 and PA7 are already used by default on the X2 for measuring the system voltage and trimpot, so I suggest you use one of PA0 through PA5 for your sensor. Have you looked at the sample code I mentioned in my previous post? If you can stand to wait, we should be releasing a new version of the Pololu AVR library next week that features full Orangutan X2 support. If you can't wait, you can put the following function in your program:

Code: Select all Expand

unsigned int read(unsigned char channel)
{
   // Channel numbers greater than 31 are invalid.
   if (channel > 31)
   {
      return 0;
   }

   ADCSRA = 0x87;      // bit 7 set: ADC enabled
               // bit 6 clear: don't start conversion
               // bit 5 clear: disable autotrigger
               // bit 4: ADC interrupt flag
               // bit 3 clear: disable ADC interrupt
               // bits 0-2 set: ADC clock prescaler is 128
               //  128 prescaler required for 10-bit resolution when FCPU = 20 MHz

   ADMUX &= ~(1 << 7);
   ADMUX |= 1 << 6;   // use AVCC as voltage reference

   ADMUX &= ~0x1F;   // clear channel selection bits of ADMUX
   ADMUX |= channel;   // we only get this far if channel is less than 32
   ADCSRA |= 1 << ADSC;   // start the conversion

   while (ADCSRA & (1 << ADSC));   // wait while ADC is converting

   if (ADMUX & (1 << ADLAR))   // if in 8-bit mode, result is left-adjusted
      return ADCH;         // so just return high byte of 16-bit ADC result register
   return ADC;            // else right-adjusted 10-bit result; return entire 16 bits
}


I tested it briefly and it seems to work.

- Ben

[CraigB]

Did I ever tell you how awesome you guys are?

I am having another problem with the motors running at the same speed. With no load on the motors they run fine and with the encoder feedback they adjust speed to stay even. The second they hit the ground they don't run evenly, one motor runs a lot faster than the other. I have checked everything I can think of, and I think it might be a motor driver. The problem follows the motor port. Any ideas?

[Ben]

Thanks for the compliment! Also, it appears my estimate for getting X2 support into the library was a little off, but the current plan is to get the new version out tomorrow if no new bugs show up.

So you're driving the motors with encoder feedback? What happens if you just set the motors to the same duty cycle and don't use encoder feedback? Is the problem better, worse, or the same?

- Ben

[lufamseed]

Hi Everyone,

My name is Terry, also known as lufamseed. I made a micro mouse by modifying the pololu 3pi robot and adding the sensors and the wheel encoders with floodfill algorithm. Please see below youtube reference.

http://www.youtube.com/watch?v=KXzmfAIF0-Y

This is my latest version of 3pi robot with following improvements,
1. Front and side digital distance sensors.
2. 45 degree analog distance sensors.
3. Wheel encoder on both wheel.
4. Ready to run in a real wall maze. (IEEE standard maze.)
5. FloodFill algorithm.
6. Run as fast as possible right after the shortest path has been identified.

My next move is to build an 8x8 real wall standard maze and run the robot in it.

I hope you like my works.

3pi Robot is really a state of arts product and I really enjoy of playing it.

[Ben]

Hi Terry.

Thanks for sharing your project with us! That is by far the most customized 3pi I have ever seen. Can you tell us more about your modifications? Specifically, I'm wondering how you found the I/O lines to connect those extra sensors and encoders. Did you have much difficulty moving the motors to enable the use of the 42x19mm wheels? Are the motors the same the 30:1 micro metal gearmotors that the 3pi shipped with? I'd love to see a video of it running through a larger maze!

- Ben

[lufamseed]

Hi Ben,

I am glad that my work has brought to your attention. Thanks for your compliment. It was my honor to chat with the master of 3pi robot.

Actually, I made my first micro mouse back in 1984 and attended the very first micro mouse competition in Taiwan. Of course, I did not make it. My mouse died in the middle while searching the shortest path. Ever since of then, I kept my mouse in dream untill I found the pololu 3Pi robot. Thanks to Pololu, my dream has come truth.

In term of your questions, yes, I use the same motor 30:1 micro metal gearmotors that the 3pi shipped with. I was a little worry if the motors were stong enough since I've changed to a pair of bigger wheels. Guess what, the result is just as good as you can see in the video.

As to the I/O, there is no difficult at all. I disconnect the build-in 5 reflect sensors, use 4 of them for wheel encoder, use the last one and PD7 as left and right digital sensor, PD5 as front sensor. In addition, I use two ADC converter as 45 degree analog distance sensors. The mouse seems pretty stable after the fine tunning and run the maze successfully almost every time.

I think my mouse is ready to try a bigger maze. I will surely uoload the video when it was done.

Finally, I must say it again, good job and well done Pololu. I believe Pololu will have a bright future in no time. I only wish I had the same opertunity to work with this excellent company and the talent people like you when I was younger.

Keep in touch.

Best Regards,
Terry.

[Ben]

Well, I am incredibly impressed by your resourcefulness in integrating so many additional components into an already packed 3pi! Did you ever consider adding a second processor to handle the additional sensors?

PD5 as front sensor

PD5 is one of the inputs to the motor drivers; do you mean PC5?

We have added your MicroMouse robot to our community projects page and our 3pi robot videos document. Once again, thanks for sharing your project with us, and I look forward to seeing more videos of your robot in action!

- Ben

[lufamseed]

Hi Ben,

Yes, you are correct, it was a typo, it is the PC5, not PD5. Actually I did consider to add another processor to deal with all of the I/Os. However, I was afraid that additional chips might suck more power from the battery. I have added a lot of components from original 3pi robot. Anyway, maybe I will take it into consideration in next version. That is the fun of the micromouse, all you need is the imagination.

I will take a look of the web page that you provide. Hopefully it can give me some new ideas to my mouse.

Nice to talk to you. See you.

Regards,
Terry.

[godzeus]

I reviewed the videos and I can't see where and how the encoders were fit into wheels withouh touching the board. By any chance Martin, do you happen to have some pictures of your setup of 3pi with encoders ?

Regards,
Edwin