Leg walk test

Quick update, started putting together a bit of a test leg.  Here's a rough walking motion test.

For this test I had the leg moving at half it's maximum speed.

Servo Driver Test

I modified the ArduinoServoSample code in GitHub to better test out the drivers.  I plugged in 4 servos on digital pins 1-4 for load testing (only 4 because I only have a 1amp power supply, and each servo is drawing 250mA).

I did however tell the software that there were servos on every pin, so the drivers were working overtime.  I manually moved the connection of the 4th servo from pin to pin and checked it's speed.  Every pin worked with the exception of pins A6 and A7.  I did come accross this quote in the arduino port manipulation reference

"PORTC maps to Arduino analog pins 0 to 5. Pins 6 & 7 are only accessible on the Arduino Mini"

As I'm using a Fio, I have a feeling that they may not be available to me.

EDIT:  
Upon review of the Fio Schematics it looks like ADC6 and ADC7 are indeed not on PortC.  PortC pin 6 is attached to the reset.  PC7 is not shown.

I have also since noticed that when the servos are being told to stay still, they have a tendency to occasionally jitter a very small amount.  There are a myriad of possible causes for this, as it's not important for my current application so I am just going to note it and move on for now.

Servo power

The next part of the puzzle is going to be solving for the battery and power system for the servos.  I just got out a multimeter and tested the current draw.  While moving under no load the servos draw between 150 and 200 mA.  When not moving the servo blips on and off at around 10 mA.  Applying a resistive force to the servo causes the power consumption to jump up to it max of around 500 mA, depending on the amount of force applied of course.  Since this robot has almost no real resistance to apply to the servos, I'm going to generally assume around a 250 mA working draw.

Side note:  I've fixed a couple of bugs in the github repo.  If anyone actually uses the library and encounters any more, let me know.

Servo Controller Library

Ok,

So while the multi servo controller library is not done yet, initial testing seems good.  I do see a jitter issue, but I'm confident I can work it out.  Here's the code released under the MIT license, so feel free to do what you like with it.

https://github.com/teastman/com.roborec.servo

Let me know if you have any questions, I'll do my best to answer them.  I'm likely going to take a break from working on these now, as it's caused me to go a little bonkers pulling my hair out.  I think I'll work on some of the physical construction a bit more now.

Functional:

• Arduino Fio (other arduinos should not be hard to add support for)
• Move servo to a given location.
• Support for as many servos as you have pins available. There will be a practical limit, but I haven't hit it with 18 servos on the Fio.
• Various servo support via setting the manufacturers defined maxVelocity, minPulseWidth, and maxPulseWidth.
• Angle inversion
• Angle limiting
• Angle normalization

Still to come:

• Collision avoidance
• Angle inversion
• Angle limiting
• Angle normalization over the set limitation.

EDIT:
Cleaned the code up a bit and did some testing.  The jitter issue turned out to be a servo defect, replacing the servo fixed the problem.

EDIT (23/07/12):
Added support for inverting, limiting, and normalizing.

Timers and Comparators

I've learnt a couple of interesting things over the last couple of days fighting with why my drivers didn't seem to be working.  What I found was that I was unable to modify OCR1A while the timer was running, or rather, I was able to modify it, but only once per timer cycle.

The reason for this appears to be due to a mechanism the chip uses to update the OCR1A register called double buffering.

The chips documentation had this to say about it.

"The double buffering synchronizes the update of the OCR1x Compare Register to either TOP or BOTTOM of the counting sequence. The synchronization prevents the occurrence of odd-length, non-symmetrical PWM pulses, thereby making the output glitch-free."

So you can set OCRnA as often as you want, but it will only actually be set when the timer reaches 0.  This is highly problematic as changing OCRnA on the fly is essential to achieve the pin output complexities I am looking for.

This table from the documentation shows all the timer modes.

The only modes that update the comparators immediately are normal mode and CTC mode.  Normal mode is out as it always counts from BOTTOM to MAX and doesn't allow us to set the timer to 20us.

CTC could work, but it means that overflow can't be used.  What a pain.

I'm now in the process of rewriting the drivers to use CTC mode timer instead.  I'll likely post the resulting code on GitHub.

EDIT:  Sooo, after all that I wound up using Normal mode.  I use OCR1B to change between triggering at 2600, and 19999.  When the 19999 trigger happens I call what used to be the overflow_interrupt function, and reset the timer to 0.  Seems to work ok.