OpenServo.com

[DKNguyen]

The Hitec manual recommends against handling the coreless motor because the ""brushbase"" (whatever that is) can become very easily separated from the PCB.

If this happens, does this mean that the motor has just become separated from the PCB? Or does it mean something inside the motor has come apart and that the motor is destroyed?

For Hitec, servos, what configurations has everyone seen (please refer to the image links below).

1. Pot & Motor direct connected to PCB (I so hope this is not the case):
http://www.seattlerobotics.org/guide/images/servo3d.jpg
2. Pot & Motor connected to PCB via wires:
http://www.lynxmotion.com/images/howto/smodh209.jpg

Do all Hitec servos that everyone has seen have the exact same setup as 2 (ie. motor/pot connected via wires, pot held in place by fixture)? I would really appreciate any mention of any variation from 2 that anyone has seen in Hitec servos.

In case 1, that the pot is direct connected to the PCB, how did you ensure that the pot leads were still the correct length so that the pot would still be properly mated to the gear train?

About the servo case itself, I noticed in the two pictures above
1. The servo lid was at the front (removing it would reveal the geartrain, so you had to dig through the gears to get to the PCB)
2. The servo lid was at the back (removing it would reveal the PCB.
Do all Hitec servos have the lid at the back?

If at all possible, I would really appreciate it if someone could provide me a photo of the HSR-5995TG PCB (ie. of the inside PCB with just the back lid removed) would be great.

Thanks.

[mpthompson]

Using Google I found the following pictures of the internals of an HSR-5995TG servo:







These images are from a Japanese web page at the following URL:

http://aitech.ac.jp/~furuhasi/robo/tetujin3/technical.html

I'm collecting images and information on servo hardware targetted by the OpenServo at the following link:

http://www.openservo.com/moin.cgi/Servo_Hardware

The motors of the HiTec HS-311 and HS-475HB are soldered directly to the PCB. It would appear the motor in the HSR-5995TG is soldered to the PCB as well. This is not the case for the HS-645MG which has wires between the motor and the PCB. Something to keep in mind is that HiTec seems to use hot glue to hold the motor in place it it would be easy to use a half-size OpenServo board and use wires to connect the motor on any of these servos.

If you get information on other servos I would be happy to post the information on our Wiki so others could benefit.

I hope this helps.

-Mike

[DKNguyen]

Wow I dont know how yo found those but my searches didn't turn up anything.

Here is an internal servo schematic of the regular HSR-5995TG servo provided by another tinkerer, Richard Ibbotson. I don't know if he worked it out himself or if he got it from HITEC...I think he traced the circuits himself.

Uhh...how do I attach a PDF? Nvm. TUrns out Adobe Acrobat can save a PDF as a JPEG!.

[mpthompson]

Terrific. Thanks for the schematic of the commercial HSR-5995TG servo. This could have saved me a bunch of work figuring out a workable H-Bridge circuit. Perhaps a future version of the OpenServo will use some of the ideas that can be gleaned from this circuit.

BTW, I found the images using Google's image search. A pretty nifty tool at times.

-Mike

[ribbotson]

The HSR5995 schematic is worked from the servo itself, no help from Hitec.

I was dissapointed to find no current monitoring in the HSR, and pleased to see it on the Open Servo.

The motor in the HSR has a DC resistance of 1.4 ohms, which confirms the Hitec spec. of 5.2A at 7.4 Volts. There is no way that the servo can safely work at full load for any period of time. The H Bridge devices are only specified at 3.5A continuous. The H bridge gets hot very quick when stalled.

For the H bridge drive, I prefer the HSR mode with two additional transistors, but only if there are four drives from the processor. I would like to be able to turn off all four H bridge FET, since both the HSR and Open Servo brake the motor when off. This makes it hard to turn for mechanical training from position feedback.

Some further detail on the existing Hitec Digtital Servo serial programming protocol is here.
http://www.basicmicro.com/downloads/docs/Hitec%20Digital%20Servo.pdf

While the 5995 uses the ATMega8 it is not clear if the frimware is upgradable,

The HSR 8498HB is claimed to be firmware upgradable, but has very different mechanics and electrical interface

[DKNguyen]

I wonder if it's the electronics or the motor that place the upper limit on the current? I am used to working with big motors where the electronics usually burn out before the motor does. This is the first time where the motors may give out before the electronics do...

I am using the ST VNH2SP30-E which has a rating of 30A with heatsinking traces. But I'm actually trying to not heatsink it so that it will overheat at the same rate everything else does at a much lower current so that the thermal protection will kick in around when the motor starts to overheat...sort of hard to do though without knowing the motor's max temperature. I just assume it's relatively low because it's a coreless motor. It's a pretty big IC, but it should fit in the servo case.

[Zeddicus]

Either one. Basically, the lowest allowed current, considering all elements in your circuit, is the maximum limit, and you should take that conservatively.

Care should be taken to not just take the maximum current as the rated current for the H-bridge, for example, if you have a sensing resistor that can take much less. This is the current (ehem... no pun intended) case in the openservo, where the sense resistor can take up to about 1.8A, but the FETS are rated at 3.5A, and I don't even know what the motor ratings are.

In any case, this is exactly the reason why a current limiter has to be implemented, in our case in software, either with a simple comparison and a PWM limiter, or via a current control loop. If not, something will eventually burn you shouldn't depend on the overheat protection, that's a last resort.

ZZZ

[mpthompson]

Ribbotson, I came across the document you wrote regarding the Hitec Digital Servos on the Lynxmotion site and if you don't mind I'll add the link you provided to the resources section of the OpenServo Wiki. Great job on putting the information together. It could be valuable as we look to make improvements in the OpenServo.

For the H bridge drive, I prefer the HSR mode with two additional transistors, but only if there are four drives from the processor. I would like to be able to turn off all four H bridge FET, since both the HSR and Open Servo brake the motor when off. This makes it hard to turn for mechanical training from position feedback.

I'm fairly certain the OpenServo does not brake the motor when both control lines (PWM_A and PWM_B) are off. This is because all P channel and N channel FETs should be turned off and current generated by the motor can't flow to break the motor. Perhaps I'm overlooking something.

The H-Bridge was originally designed for the AVR ATtiny45 MCU which only had 8 pins -- two of which could be used for control of the H-Bridge. The circuit seems to work fairly well and I kept it intact when we transitioned to the ATmega8/168 even though more control lines would be available. I try to keep the PCB so it can work as a half-size PCB so adding more components such as transistors to control the FETs would be a challenge.

An interesting hack would be to reprogram or replace the ATmega8 on the HSR-5995TG so it ran a varient of the OpenServo code. It may not run better (at least for now), but it would be more open for hacking.

-Mike

[DKNguyen]

Yeah, the H-bridge IC has voltage, thermal, and current overload built-in, but for all intents and purposes it is far too high for the motor. The motor will give out long before the chip does. I'm going to use the current sense output from the H-bridge IC and a temperature IC to have ""feedback"" so I will be able to stay within limits. BUt feedback isn't the same thing as protection because if the MCU code malfunctions it could lead to the servo ""willfully"" operating beyond acceptable limits.

But it's always nice (and safer) to also have a thermal/current protection circuit that works on a physical basis independent of the MCU, which is why I'm trying to ""de-heatsink"" the H-bridge IC so it heats up faster than it normally would so that it would be more effective at protecting from thermal overload. Not much I can do to artificially lower the current limit rating though. Should the worst happen, at least the PCB will be okay.

[Zeddicus]

After carefully looking at the schematic, I agree that if both PWM lines are switched off, all four fets are switched off as well. However, if current was flowing through the motor at the time the lines were turned off, well:
v=Ldi/dt

basically this means that, due to the motor winding inductance, the current will oppose change. In an ideal world, this could destroy the electronics, or the motor. A sudden turn off of all Qs implies a step to the current (circuit interruption), and the derivative of a step is an infinite impulse, which means that the voltage at the motor windings will spike badly.

But since the MOSFETs have a parasitic diode in parallel, then there is still a path for the current to expend itself against the voltage source, by flowing against the MOSFETs through te diodes. Therefore, no damage should occur, since these diodes are usually fast enough to turn on, which will reduce the voltage spike.

whew! long-winded, aren't I?

Cheers,
ZZZ

[Zeddicus]

DKNguyen, you're right of course, that's allways the pitfall of implementing safeties in software.

What I would do is implement a direct security in the ISR for the current sense, so that if the current is limit is exceeded, the PWM output is set to a minimum. This, of course, in addition to the current control loop.

This way, if the controller goes wrong for some reason, the ISR will at least offer protection.

It's still code, but it should be an improvement...

ZZZ

[DKNguyen]

Excuse me? ISR?

[Zeddicus]

Interrupt Service Routine of the AVR, the function that gets executed when the ADC finishes a conversion.

Z

[m_kanter]

... you let the watchdog enabled.
since the avr uses flash and all addresses and jump locations are (or can be) hard-coded in this project. so the program counter keeps in locations where code is - solving many problems.
then ... enable the watchdog, write an (watchdog-)reset routine, which handles the current limit (maybe simply by shutting off all fets, or go to an well defined initial state)
this will make the servo act weird only some ms until the wtd overflows and an reset occours then the servo goes back to and defined state.

maybe we will find and place to put an diode and an resistor next to the bridge ics to measure the temp. next to them and provide an overhead protection ( - its just an idea - maybe we can use the parasidic diodes)

(Im working in an automotive firm and here they have to grant for some security stages - there are some industrial norms about that - they do things like that.)

[guru]

Did anyone notice anything peculiar about the RX/TX line. It has a transistor on it. It seems to me that this transistor would be for transmitting (holding the line to ground). Therefor this RX/TX data line should go directly into RX and the TX should be using the transistor when it wants to bring it to ground.

Am I wrong?

C