OpenServo.com

[ginge]

Hi all, I hope you can guide me in the right direction with this...

Occasionally a servo controller will reboot, and get stuck in its bootloader, causing total axis failure.
I know the bootloader issue has been discussed, but I think the issue of the rebooting servo needs to be researched.
The problem is quite annoying, and happens about one in 1000 times I use the openservo.

This is the situation that lead to this event is as follows:

using 9 servos on the bus simultaneously. All servos are in a series bus to minimise capacitance (am I right doing this?)

1) Write a position to the servo so that it is set to its max position say 255
2) Read position from servo every 10ms
3) Before the servo starts to slow, write a position back to 0

There are some considerations I have taken into account that may help:
There is a measuable back EMF voltage that induces lots of noise into the circuit when the motor switches direction. The transistion between the movement causes larger current draw too.

The smaller servos dont seem to suffer much at all.
A heavy duty servo will do this occasionally when under a lot or strain and the current draw is high
The large motors that I am using are causing a definate reboot at a rate of 1 in 1000 writes.

All this got me thinking...

I have been suffering from chronic I2c noise and corrupt packets. There is new checksum code that would help no end, but even this would suffer.

The more current I draw, and the dirtier the power supply, the more I2C corruption I get.

I think there is some merit to the reasoning, and I am going to investigate a more EMF friendly design.

Maybe excessive noise in the PSU and MOSFET is causing my I2C woes.

If anyone can shed light onto anything, please do!

Barry

[mpthompson]

Barry,

I don't have any specific information, but let me mention a few things that may help narrow the problem. They may also be off the mark.

When you say this problem happens 1 in 1000 times when you use the OpenServo, is this 1 in 1000 I2C commands or less frequent than that.

Barring a bug in the servo code the only way that I think a servo could reboot from a corrupt packet is if it thinks it received the TWI_CMD_RESET (0x80) command. You could try disabling the handling of this command in main.c to see if that helps the situation. Of course this will prevent you rebooting the servo. Because the consequences of receiving a bad command packet we may want to create a more complex command sequence to minimize the chance of bad command packets or put a checksum command packets.

Another reason a servo could reboot could be a crash of the software caused by the stack (which grows down from the top of SRAM memory) overwriting the global variables. This has happened to me a couple of times during development and symptoms are pretty much unpredictable. We probably need to put simple stack monitoring code in to flag if/when the stack gets dangerously close the global variables.

Finally, the other way a servo could reboot is if the voltage drops dangerously low and the brown out protection on the servo resets the servo. If the servo tends to reboot when there is heavy load placed on the motor, this could be the culprit. One way of experimenting with this is to put a heavy load on the servo and examine Vcc going into the servo. If it drops below 2.7 volts the servo will likely reset and wake up when the voltage returns above 3 volts. This brown out settings are controlled by the ATtiny45 fuses and I am assuming you set them to 2.7 volts when you initially programmed the MCU.

Are you using the latest bootloader code? You indicate that when a servo does reboot it doesn't seem to exit the bootloader. If so, we will need to track down why the bootloader doesn't exit after 3 seconds. Something to check is to make sure you are using the latest bootloader code. Andy found a problem a little over a week ago that we both fixed related to an I2C command causing the bootloader to get stuck in a bad state. The latest bootloader should have a fix for this problem. The CVS log comments for twi.c will explain the issue. Also, it isn't very intutive, but there is a way to upgrade the bootloader on a servo over the I2C bus that I can explain to you if it would help.

I believe there may be flaws or shortcomings in the OpenServo circuit that do make it very susceptible to noise from the servo motor and h-bridge circuit. This is where getting an experienced electrical engineer to examine our circuit could really help us out. Hopefully a fix would require only minor changes to the circuitry. This is something that we will have to solve together because I myself just don't have the experience needed to really diagnose and fix this issue.

If you like, try and use Yahoo IM to reach me with my IM id of michael_peter_thompson. I can ask you more questions and try and get a better feel for the specific issues that you are facing.

I appreciate the work you are doing with the OpenServo and hope that we can help you come up with a solution fairly soon. You are pretty brave for adopting the OpenServo so soon in its design cycle .

-Mike

[andylippitt]

I was having this problem early on. I was running the servo off 5V. I raised it to 6V and the problem disappeared completely. Check to make sure that when your motors are kicking on it's not dropping too low.

[ginge]

Thanks for the input.
The glitch happens in about 1 in a 1000 writes to the servo.
I will try the 6v input method to see if that works. I dont believe I am getting a brownout on chips, but the possibility is there for a global overwrite.

Brave? No, just didn't really want to start from scratch for the motor controllers.

Barry

[andylippitt]

You don't have to get all the way down to 2.5 for the brownout to occur. I believe the voltage regulator cuts out well above 2.5V.

[andylippitt]

A rather uneducated read of the voltage regulator spec tells me that the mcu will see it's 2.7V at just shy of 4V input to the regulator.

[mpthompson]

Barry,

I talked with a friend of mine who is an electrical engineer and he says that we definitely need to make sure that we are supplying the servo with at least 6.2 volts or higher. Otherwise, we will likely see the voltage output from the regulator fluctuating wildly. This is entirely consistent with the problems that Andy discovered.

I'm assuming that in your version of the OpenServo circuit you retained the LM3480 voltage regulator. You'll need to make sure you are supplying at least 6.2V or you can power the MCU and the potentiometer from a separate 5V line to each servo independent of the h-bridge/motor voltage.

Hopefully this will have some impact on the reboot issue you are seeing.

-Mike

PS. I also got some tips on noise suppression with regards to the servo that I'll be looking to incorporate in the next rev of the OpenServo hardware. It's basically adding ceramic .1, .01 and .001 uF capacitors at some strategic points in the circuit.