I am the head of my university’s team for an autonomous maze solving robot. Consulting with the faculty at the school about minimum specs for a micro-controller, I doubled them and then went over that by getting the Orangutan X2. I have the sharp digital and analog proximity switches. I am ok in the hardware and electronic construction, but I know nothing of programming. I am looking for a good place to start. My only experience in programming comes from some very very basic C++ and VHDL. Any help is very much appreciated. Thanks
Have you already built your robot’s hardware? Can you post some pictures of it?
The Orangutan X2 can be programmed with C which is like C++ without classes or objects. I don’t know much about Micro Mouse rules, but I believe they have walls and do not have lines on the floor. Is this how your contest works? The 3pi robot user’s guide contains a large section on lined maze solving which might provide some insight into the code for a maze solving algorithm.
The X2 does not support the Pololu Orangutan Library yet, so the code written for the 3pi will not ‘just work’ on the X2, but it is possible to translate them into working programs on the X2. If you have any specific questions after reading through that user’s guide section and the X2’s user’s guide, please ask them.
The hardware is currently in construction. The maze is a walled maze with a black floor and white walls. We are using the sharp infra-red digital and analog prox detectors for wall detection. We would like to use a motor with encoder feedback for distance traveled, but we would need help in deciding what motor/gear set to use. I need something with enough torque to move the robot, but fast enough to win the maze. Thanks.
To figure out what motor geat-ratio to use you need to know how heavy your robot will be and how fast you want it to go. You haven’t said the size or weight of your robot, but if it is a typical MicroMouse size, 50:1 HP micro-metal gearmotors will probably work well for you. Pololu has a wheel and encoder set that lets you add encoder support to these motors.
We are having problems getting the test program to load onto the X2 board. Is there a tutorial on how to do this? Something step by step? When we try to build the test file it gives us an error: make: *** No rule to make target ../SPI.c', needed bySPI.o’. Stop.
Make sure you’ve added the file spi.c to your AVR Studio project. It’s not sufficient to just have the files in the same directory as your project. You can do this by right-clicking on the “Source Files” node in the AVR GCC panel docked on the left side of the window and selecting “Add existing source file(s)…”. Once spi.c is listed under the Source Files node, you should be able to build the project. Please let me know if you still have problems getting it to work.
Yes. The VNH3 version can deliver a continuous 9 A per channel, and the VNH2 version can deliver a continuous 14 A per channel, so the X2 can easily power our HP micro metal gearmotors.
In general, you should compare a motor’s stall current at the voltage you plan on running it (note that stall current scales linearly with voltage) to the continuous current rating of a motor driver. If the stall current is under this rating, you don’t have anything to worry about. If it’s close to this rating, you then need to start evaluating whether your motors will ever be close to stall for extended periods of time in your application. If it well exceeds this rating, you might need to look for a more powerful motor driver or lower-current motors.
Just had an emergency that ended with a phone call. Thanks for all the help. I blew the capacitors on the top of the board due to hooking up the power supply wrong. I soldered in some new ones, and the board is working fine. One question I have is that the board feels hot underneath. One team member noticed this before, but I wanted to make sure this is normal.
I’m not sure which board you’re talking about, but the whole motor driver board can get hot if you put a lot of current through it, and the voltage regulator on the main board can get hot under normal operation, too.
I have to robot built and pretty close to having the final body design selected. When I have the robot run now, especially when the batteries get low, one wheel takes over and it spins about itself. I have loaded the test program that the X2 comes with, and it does the same. Ideas?
Is it always the same motor that turns off? Your motors might have different amounts of internal friction. If the voltage gets low enough, it could be enough to only overcome the internal friction in one of the motors but not the other.
How low is your motor output voltage getting? Can you measure it with an oscilloscope or multimeter?
It seems to be the same motor. I have tested this with a different set of motors, and the same has the same problem. I also took a stepper motor and it would work on one motor port but not the other. Advice?
How low is the voltage you are powering it with? Can you measure the output voltage of each of the motor channel outputs without the motors connected and verify they are different?
I am using a 7.4 VDC power supply. I took an O-scope to the outputs and they seem to be equal. Slowing down the motor speed seems to help. I am wondering if the motor is too torquey and causing the problem. I can email a video of what it is doing.
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.
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.
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.
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.
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:
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
}