I’m trying to make the 3pi-linefollower example work. I successfully compiled the program. I’m using the latest libpololu-avr-100607.zip. I use the Makefile provided with the example code (modified to find the libraries in my local installation path). Everything seems fine. However, at the beginning of the program, the robot moves forward and backwards instead of doing it to the right and to the left (trying to find the "line). I even wrote a very simple program:
#include <stdio.h>
#include <string.h>
#include <pololu/3pi.h>
#include <util/delay.h>
/* Program entry point */
int main(int argc, char **arv)
{
/* The map */
for(;;) {
set_motors(128, 128);
_delay_ms(3000);
set_motors(0, 0);
_delay_ms(3000);
}
/* Back to system */
return 0;
}
In this case, one wheel turns clockwise and the other one does it counter clockwise. However if I write something like set_motors(x, -x), both wheels turn in the same direction.
What am I doing wrong? I remember I had this problem before, but it was fixed by disabling optimizations. This “fix” doesn’t work for me in this case.
I’m using:
Yes, it did. The first time I tried, I was a bit puzzled until I searched the forums and knew about the compiler bug. I disabled optimizations and it was able to follow a line (this was with avr-gcc 4.3.0 IIRC). After that I didn’t play with the pololu for a while and now (after a couple of updates in my system, including avr-gcc) I get the same behavior.
How can I see if it is a software problem or a hardware one? Does anybody have a similar setup?
Hm, that is really weird. I have a vague memory of some avr-gcc optimization-related issues involving treating small integers as char types instead of int - can you try your test using a speed of 127 instead of 128, just to see if that could be the problem?
I tried, but it didn’t work
How can I tell if the generated code is ok? Which is the avr-XXX command to get the assembly code or something useful I could post here?
Can you try one of our pre-compiled hex files included in the pololu avr library download within “examples/atmega328/hex_files” to verify that the motor is really not just soldered backwards? It would also be useful if you could measure the voltages on all four motor pins when driving with set_motors(255, 255) and post your results here.
Pre-compiled hex files also show this weird behavior. The 3pi-demo-program for instance when pressing A and C buttons in the “motors” tests, make M1 move forward and M2 move backwards.
I measured the voltages between every pair of motor pins. I got ~9.30 V for M1 and ~9.33 for M2
This is the result of avr-objdump -d motor_test.obj (the program I posted previously I used to set motors at 255):
Hm. It sounds like your motor is probably just soldered backwards, and if it worked before, you had a bug back then. I recommend that you just define an inline function my_set_motors that calls set_motors(m1, -m2) and use that instead of the original set_motors().