Yay 5-cell. Now you can wire power straight to your Baby-O, no problem!
Real-time debugging is quite handy. Serial debugging is probably simplest way to go on the Baby Orangutan, but the logic-level serial signals generated by the Baby O are incompatible with computer serial ports, which use an inverted serial signal at much higher voltages. To connect your Baby O to a computer for debugging you would need a USB or RS-232 to TTL serial adapter. You could also do something creative like connect LEDs and resistors to each pin of a port, and light them up to display 8-bit numbers in binary (I’ve totally done it). You could even just use the built-in LED to do a simple check, having it light up when your sensor returns greater than a certain value. This LED happens to be on the serial transmit line, so you wouldn’t be able to manipulate it while using the USART. On the other hand, you have your servo controller and servos working, which could be a decent debugging tool itself.
But first for a little offline debugging of your code. The “PORTC=0x00;” line isn’t necessary, but it also isn’t hurting anything. The line:
val1 = analog_read(PORTC=0x00);
is a little odd, you don’t need to set the PORTC register at all, just specify the number of the analog channel you want to read from. If you’re wiring hasn’t changed recently, you have your analog sensors connected to PC0, and ADC6, so you would get readings from them by calling:
val1 = analog_read(0);//Read PC0
val1 = analog_read(6);//Read AD6
In any case, the line as written should be checking the analog input value on PC0 anyway.
Another problem I can spot is your scaling function:
bend1 = ((val1*4000)/255);
Val1 is an unsigned int, which on an AVR can have values between 0 and 65535 (2^16-1). Since you just loaded it with a MODE-8-BIT ADC value, it is currently set to something between 0 and 254, which you are trying to scale to a value between 0 and 4000. The problem is that when you multiply val1 by 4000, the immediate result may be more than 65535, in which case you would loose all but the remainder. Since you’re dividing the result of that multiplication by 255, your result will always be somewhere between 0 and 257. For example, lets say val1=255:
Normaly: (2554000)/255=(1020000)/255=4000
But since the intermediate results are limited to 16 bit values: (2554000)/255=(1020000)/255=(36960)/255=144
There’s a quick remedy for this, however, called type casting. Essentially its telling the AVR to treat (cast) a variable as if it were another type of variable. If you write the formula this way, the AVR will allocate 32 bits (0 to 4294967295) for the intermediate values of the calculation:
bend1 = (((long int)val1*4000)/255);
The only other possible problem I see is that your while(1) loop will be running very quickly. Servo position can only be updated every 20ms anyway, so you might consider adding a delay that long or longer inside your loop, just to give the servo controller some time to react to what you’ve sent it before sending it another command.
-Adam