OpenServo.com

[mpthompson]

Cliff,

Your reasoning makes sense to me and the ADC on the ATmega168 should be fast enough to get all three readings while PWM is disabled. I'm going to start throwing some test code to together to get getting a sense of the timing for the various pieces ofthe processing at 20MHz.

Also, right now we are not making any special allowances for the fact we are powering the servos with 7.2 volts, but using motors generally rated for about 6V. The rating changes between the various servo types and manufacturers and isn't always easy to determine. This has been the subject of other threads as to whether the motors can tolerate the overvoltage or whether we should be addressing this issue with the PWM duty cycle or through other means. Any opinions on this?

-Mike

[ginge]

I would recommend we switch to 3.3v for v3. It's tried and tested on v2, so no problems there.

if we switchdown to 3.3v we can then run the OpenServo at 6v. I still think that a voltage control loop (as discussed in other threads) would be a nice addition.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[mpthompson]

I agree regarding 3.3V as it does more latitude with the battery voltage.

I guess I'm being dense, but ""voltage control loop""? Please remind me.

While we are discussing version 3, something that has me a bit concerned is whether we should consider alternatives to the I2C bus. The major issue for me is that when attempting to control a large number of servos such as the the number that may be in a hexapod or humanoid robot (16 to 20) the overhead of a controller processing so many I2C messages becomes a significant. Also, because of the pull-down nature of the I2C bus, it doesn't have good noise immunity characteristics which limits the bus speed to 200 to 400 KHz which really isn't too fast.

SPI could be a viable alternative because it's built into the AVR as well and it's dedicated input/output lines have better noise immunity allowing much higher clock speeds. However, SPI requires more I/O lines and it may not be any less easy for a controller to manage a large number of SPI data than I2C data.

In my local robotics club a member is doing very interesting things with a multi-drop serial bus that runs at .5 Mbs (or 1 Mbs) on top of a CAN bus physical layer. The CAN bus physical layer provides high noise immunity communication between modules and communication is fairly easy to implement using the the on-board microcontroller UARTS. The downside is the CAN physical layer would reguire shoe-horning a 6-pin SOIC onto the board and the UART protocol isn't terribly sophisticated (but that adding complexity is always easy ). The bus has dual isolated power lines for off-board logic and motor power. This is being done as part of an ""open"" Robobricks 2 project and more info can be found here:

http://gramlich.net/projects/rb2/specifications.html
http://gramlich.net/projects/rb2/index.html

Some good notes on bus issues are here:

http://gramlich.net/projects/rb2/develop.txt

Just thought I would throw this into the mix.

-Mike

[ginge]

I can't remember who proposed the voltage control loop, but it works like so...

The Max PWM is initially set to run at a value a little less than the maximum, say 85%. This leave some room to enable the PWM to rise as the Voltage falls low, or rises above the norm. There is a control loop that runs to keep the motor voltage the same despite the input voltage.

This would help to keep as many variables as possible in a known state so that the main controller doesn't have to poll the servos as often.

Regarding the CAN implementation... It is something that would be nice to have, but I fear it could put the OpenServo even further out of reach to new users. CAN is not commonly interfaced with things like the Basic stamp etc, and could be difficult to implement in the end user application.

I realise I2C has many limitations, but it is common, and very easy to program for.

Can we have both in one package, or at least get away with not using the additional chip? What does the chip do, and can it be replicated in software?

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[mpthompson]

Barry,

I think you are right concerning I2C and CAN. Adding a hacked CAN interface would certainly make the OpenServo less accessible. I just wanted to include it in the discussion because it has some nice characteristics. On the side I may make a RoboBricks 2 version of the OpenServo for people interested in that platform to use, but it would not be related to the mainline OpenServo base which is more accesible to microcontrollers with I2C built-in.

For my own robot work, I may work with an FPGA where I dedicate a two wire I2C bus to each servo from the main controller. The FPGA would dedicate hardware resources to each I2C bus to transfer position/velocity information bi-directionally to all servos simultaneously. From the software perspective, it would look like you are simply reading/writing registers in the processor address space and the FPGA hardware transfers those values over the I2C bus without any software assistance. We'll see if I have the wherewithal to actually make this work as I intend.

-Mike

[Cliff]

Mike,

The issue is really how much current flows in the motor at low speeds and high loads and what the maximum RPM is with light loads. When starting the motor (even with no load), the applied voltage and motor coil resistance determine the amount of current that will flow(stall current). At higher speeds, the motor develops BEMF, which subtracts from the voltage available to drive current through the coils (applied V - BEMF V / coil R). At a given applied voltage, the motor will increase speed until the BEMF, plus the current needed to drive the load times the coil resistance, equals the applied voltage (applied V = (load current x coil resistance) + BEMF V).

So by applying a higher than rated voltage (average voltage, peak voltage is not the issue), excess current will flow when starting and under heavy load, which will excessively heat the motor. When the motor gets too hot, a couple of bad things can happen. One is that if the temperature approaches the currie temperature of the permanent magnets, the field created by the current in the coils can demagnetize the magnets. The other bad thing is the excessive heat can cause the coil wire insulation to fail, producing a short in the coil.

In the case of a lightly loaded motor, the problem is that the motor will run at a speed greater than the rated RPMs, possibly causing damage to the bearings and the brushes.

Limiting the PWM duty cycle (ratio of motor voltage to battery voltage) will prevent these bad things from happening to the motor, but there is still the possibility of causing damage to the FETs. If the FETs are rated to supply the current required by the battery voltage divided by the coil resistance, then there should be no problem. However, FET specifications assume proper heat sinking, which I think is less than a proper assumption in our case. This is an area I hope to define better, when I get some working hardware. With some defined guidelines on FET selection, I don't think this will be a problem. On the other hand, maybe we'll need to start an OpenHeat-Sink project.

Cliff

[Cliff]

Barry,

The problems I can see with running OpenServo v3 with 3.3V instead of 5V are:

a) The choice of FETs will be limited to those rated at 2.7V Vgs - there a more rated 4.5V Vgs.
b) Even when a FET is rated at 2.7V Vgs, its on resistance will be 1/3 higher than using the part at 4.5V Vgs. ? more heat for the same current.
c) The above problems go away, if two more transistors are use to drive the N-FETs, but I don't know where to find the space ? any suggestions?
d) I think a 5V ADC range results in less noise error, in this noisy environment.
e) The 3.3V I2C has less noise margin than 5V I2C and is limited to a shorter bus length at the same clock rate.

As far as running 6V motors or for that matter 5V motors, with a higher battery voltage, I do think this can be handled with a PMW duty cycle limit and some guide lines on FET selection.

Cliff

[Cliff]

[mpthompson]

We'll need to start a biped discussion in the off-topic area. I've been thinking through various issues over the last year at a start-up that I've recently left. I know a number of other people in the forums are interested in bipeds as well.

-Mike

[eric_lmi]

[ginge]

hi Eric_lmi, and welcome

[ginge]

I friend of mind had a great idea... for V3 break out the serial lines to two of the pins and then allow a CAN to serial module to be attached as a breakout of the servo connector.

Why won't this work

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[mpthompson]

What does a CAN to serial module look like? I assume they are available in an SOIC package or something. I envision a small external PCB that hangs vertically on the side of the servo (perpendicular to the internal PCB) that implements protocol conversion.

-Mike

[mpthompson]

Cliff,

Any estimate on getting your first batch of version 3 PCBs made? I'm just curious...

Also regarding 3.3V or 5V operation of the OpenServo logic, are there ways of reliably generating a regulated 5V from a 5V to 6V battery source? I think you make a good case for keeping the logic voltage at 5V, but it would be nice if the OpenServo worked reliably with a 4.8V to 6V battery supply. This would help make it a candidate for replacing standard RC servos in certain instances.

I have a bunch of Hitec HSR-8498HB servo boards which are the digital servos with position feedback used in the RoboNova robot. These servos are spec'd at 4.8V to 6V operation. They look to use an Atmel ATmega8, but I don't know at what voltage. I wonder if there are things we can learn from taking a closer look at these servos.

-Mike

[Cliff]

Mike,