Ok so, I’ve gotten everything installed and operational as per the guide forProgramming Orangutans and the 3pi Robot from the Arduino Environment and all was well, I loaded up the blink sketch and it blinks. I unhooked the programmer and cut the power. Turned it back on, and it started blinking away again, cool. Next, I downloaded the motor library and the Adafruit gryo library for the L3GD20 3-axis gyro. Ran my code and the motors now spin according to how the fast gyro is tilted, even cooler. The problem however has just begun, I unplugged the programmer and turned off the power. When I tried to turn it back on…nothing. The green LED lights but no sketch is initiated. I modified my sketch to blink the red LED on pin 1 to verify, and when I turn the board off and then back on it just sits there with it’s little green light staring at me (probably with a little smirk, I just know it.) What am I missing here?
Hello.
I think it is unlikely the Baby Orangutan is forgetting its sketch; the memory doesn’t work like that. It is more likely that you have a power issue or something else is going on that keeps your program from executing properly under certain conditions.
If you disconnect everything from the Baby Orangutan and go back to the blink LED sketch, does it work properly after a power cycle?
- Ben
Hey Ben,
I was just trying to be colorful and descriptive for future perusers of the forums 
Yes, I did revert back to square one with the blink sketch and all was well. After including the orangutanMotor library, it stopped wanting to play nice. I commented out anything gyro related and couldn’t get the motors running properly again with the setM1Speed, or setM2Speed methods. Only when I had the motors set to the gyro.axis.data did they want to do what they were told.
For a bit of background:
This is all aimed at a 2-wheeled balancing robot, The Baby-O is powered by 6xAA (Fresh Alkalines at the moment). I’ve got 2 micro-metal gearmotors MP (75:1, 290RPM, 0.7A stall) attached to M1A, M1B and M2A, M2B, an ADXL345 3-axis Accelerometer, and an L3GD20 3-axis Gyro. All grounds are connected.
Using Windows7 with Arduino IDE 1.0.3 to program the Baby-O via the USB AVR programmer. I did notice that When I installed the drivers for the programmer the Arduino IDE gave me 2 COM ports to choose from. One being the programmer port(which is the one I used) and the other a TTL Serial port. I hadn’t seen anything mentioned about showing 2 ports, but I got it to work so I rolled on.
I appreciate the help.
-Jeremy
Since your simplest tests (the blink LED example) work and your more complicated ones don’t, let’s try to incrementally increase the complexity from the working case to figure out better where things stop working (and hence what is likely responsible for the problem).
Can you disconnect everything except motors and power from your Baby Orangutan and just try a simple sketch to drive the motors at, say, half-speed? Can you post the sketch and tell me exactly what happens? If it isn’t working exactly as expected, can you post some pictures of your setup?
- Ben
Thanks for your help Ben,
The problem ended up being the gyro failing to initialize after power off/on cycle. Here is the debugging code I added:
void setup()
{
// Initialize gyro with 500 Deg/Sec Scale and check for error
if (!gyro.begin(gyro.L3DS20_RANGE_500DPS)) {
// Blink LED 2 times on Error to make sure sketch started running
digitalWrite(1, HIGH);
delay(1000);
digitalWrite(1, LOW);
delay(1000);
digitalWrite(1, HIGH);
delay(1000);
digitalWrite(1, LOW);
while(1);
}
// Initialize accelerometer and check for error
if(!accel.begin()) {
// Blink LED 4 times on error to make sure sketch started running
digitalWrite(1, HIGH);
delay(1000);
digitalWrite(1, LOW);
delay(1000);
digitalWrite(1, HIGH);
delay(1000);
digitalWrite(1, LOW);
delay(1000);
digitalWrite(1, HIGH);
delay(1000);
digitalWrite(1, LOW);
delay(1000);
digitalWrite(1, HIGH);
delay(1000);
digitalWrite(1, LOW);
while(1);
}
}Originally the code I had cut and pasted into my sketch was using the serial terminal to give these warnings. I couldn’t get the Baby-O to show anything in the serial terminal so all serial related code was removed. What I didn’t do is add code to tell me if the thing was getting past the setup() loop. Using the LED, I was able to determine that a failed gyro initialize was leading to the while(1) being executed. Now everytime I turn it off and then back, on the gyro error LED happily tells me it failed to start-up. To fix the problem, I simply added a 1 second delay at the very beginning of setup() loop and the gyro initializes flawlessly everytime. (20Mhz related issue?)
Is there a way to get the serial terminal window in the Arduino IDE working with the Baby-O, or is it necessary to have a USB connector and FTDI chip on board?
Thanks for your time.
-Jeremy
I’m glad to hear you figured out the problem; that’s exactly the way to troubleshoot something like this. Various devices take different amounts of time to start after power is applied (they need to wait for the power supply to stabilize above a certain level, and then they frequently have their own initialization routines to get through), so it is not surprising that the Baby Orangutan might be ready before the gyro. It’s often good practice to add some delays at the beginning of your program before interacting with other devices just to make sure they’re ready.
If you have our USB AVR programmer, you can use that as a USB-to-serial adapter (it shows up as two separate COM ports, one for programming and one that can be used for general serial communication). If you connect its RX pin to Baby orangutan PD1, its TX pin to Baby Orangutan PD0, and its ground to the Baby Orangutan’s ground, you should be able to select its general-purpose COM port from the Tools > Serial Port… menu of the Arduino IDE, and then I expect the serial monitor will work for you. Please let me know if it doesn’t.
- Ben
I’m having a similar problem, except more bizarre. My Baby-Orangutan 328 can be programmed and verified, but seems to have a “working” state and a “broken” state. When powered on, it starts in the default “broken” state - the power LED turns on but that’s it. I can put it into the “working” state where the program does run, by accessing the Orangutan with the Pololu AVR programmer (program, verify, or read-signature), or by momentarily touching a ceramic disc capacitor between the VIN and GND on the Orangutan. These must be done after the Orangutan is powered-on, and done again EVERY time it is powered on to get into the working state again.
int main()
{
delay_ms(50);
set_digital_output(IO_B4,1); // Turns on external green LED
delay_ms(2000); // Wait 2 full seconds to verify green LED is on, indicating the program is actually running
set_digital_input(IO_B0, 0);
set_digital_input(IO_B1, 0);
set_digital_input(IO_B2, 0);
set_digital_input(IO_B5, 0);
set_digital_input(IO_D7, 0);
serial_set_baud_rate(9600);
// If the first two commands run, the rest of the program also runs fineI’m also having a related serial communication problem between the Orangutan and Qik. Everything is set to 9600 bps. When I test it by connecting the AVR programmer’s serial lines to the Orangutan, it communicates properly. When I connect the AVR programmer to the Qik and send the same commands that were received from the Orangutan in the previous test, the Qik works fine. Only when I connect the Orangutan to the Qik does it have a problem. When the Orangutan attempts to transmit to the Qik, it immediately goes into the broken state and the Qik generates a “serial hardware error”, for which I had to connect the AVR programmer to read. Bumping any of the wires on the breadboard also seems to break the Orangutan (I can tell immediately because the red-LED attached to the TX line goes off when in the broken state), leading me to believe it is being ultra-sensitive to voltage or capacitance fluctuations, and filter capacitors haven’t helped. I appreciate any insight into this problem.
Hello.
That certainly sounds like a strange problem. Has the Baby Orangutan always behaved this way or did the behavior just start recently? I think the best thing to do is to simplify. Can you disconnect everything except power from the Baby Orangutan and post the simplest program that demonstrates the issue (e.g. blinking the user LED)?
- Ben
I removed everything except the Baby Orangutan and the power lines, and used the code below that just blinks the red user LED. Unfortunately it still has the same problem and temporary solutions. The supply voltage is 12.7 V, and the Orangutan is drawing 13 mA. The power is supplied from a NiMH 10-cell battery pack to the Qik first, then to a 3A fast-acting fuse from the Qik’s unregulated VIN(out) pin, then finally to the breadboard the Orangutan is on.
This Baby Orangutan is the second one I’ve owned. The first worked normally when powered-on with the same configuration and program, and was able to communicate with the Qik. Something eventually went wrong with it though. It draws a ton of current and the tiny black square IC next to VIN gets extremely hot. This part appears to have 6-pins and is marked “530P”, but I could find no information on it and am curious as to what it might be.
#define F_CPU 20000000UL // Baby Orangutan frequency (20MHz)
#include <util/delay.h>
#include <pololu/orangutan.h>
int main( void ) {
while (1) {
//two brief blinks per second
red_led(1);
_delay_ms(100); // delay 100 ms each phase
red_led(0);
_delay_ms(100);
red_led(1);
_delay_ms(100);
red_led(0);
_delay_ms(700); // delay 700 ms between pair of blinks
}
return 0;
}I apologize for my delayed reply.
This doesn’t quite count as simplifying things down to just the Baby Orangutan and power. Also, the VIN(out) pin in the qik is not intended for high currents; you really should not be routing the Baby Orangutan power through the qik if you are going to be drawing more than a few hundred milliamps.
I strongly suspect the source of your problems is your power supply. A 10-cell NiMH pack can be above 15 V when fully charged. The absolute maximum voltage for the Baby Orangutan is 15 V, and we recommend you avoid voltages above 13.5 V to leave room for noise/voltage spikes on the power line. Are you taking any special precautions to ensure that the supply voltage stays within appropriate limits?
This is the reverse-voltage-protection MOSFET. I expect that the short is actually somewhere else on the board, though, such as in the motor driver.
Can you look at the output of the Baby Orangutan’s voltage regulator when it is in the “broken” and “working” states? Can you describe how you had everything connected before this problem started?
- Ben
I removed the Baby Orangutan from the robot and placed on a separate breadboard, powered by 4 AA batteries providing 5.1 V, and no other components attached. It demonstrated the same behavior but went into the broken state after a fraction of a second of running. On both the 13.5 V supply and 5.1 V supply, the Orangutan’s regulated output was steady at 5.00 V, in both broken and working states, although it dips to 4.99 V briefly while communicating with the AVR programmer. The pgm03a utility and AVR Studio both usually read around 4.7 V from the Orangutan though. I tried to use the SLO-scope to measure in more detail, but it didn’t show any voltage changes. It seems to pause when the AVR programmer is programming, I suppose they are mutually exclusive.
After a lot of experimenting, I finally made a mistake and put the Orangutan on the 13.5V board backwards, with the power and ground connected to PD7 and PD4 respectively. Now the ATMega overheats like on the other board and I’m sure it’s ruined as well, so after all this I’ll just have to just replace it anyway. If you have any idea what might have been the problem though, I’d still be interested in knowing. Thanks for your help.
My main suspicion is that something was damaged as a result of unintentionally exceeding the maximum voltage rating for the board at some point. Did you ever change the AVR fuses?
At this point it sounds like you should just try again with a new board and a lower-voltage power supply (e.g. a 9-cell NiMH pack). If you email us and mention this forum thread, I might be able to get you a discount on a replacement.
- Ben