OpenServo.com

[mpthompson]

I feel a little strange mentioning this just after wrapping up version 2.1 of the OpenServo hardware, but it's probably worth a discussion.

In researching a little board called the MEGAbitty for nanobots I came across here on Yahoo Groups a pretty good description of sign-magnitude PWM versus locked-antiphase PWM. Monty's description is:

[Zeddicus]

Yes, the openservo uses sign-magnitude PWM. Basically, you connect the motor for a certain amount of time, then let it coast with no voltage applied. And the comment is correct: there is currently no way to detect power regeneration, which basically means that the power stage design of the openservo works only in 2 quadrants: forward load and reverse load. Forward regeneration and reverse regeneration can't be detected, because with the openservo power circuit design you can't detect opposing signs of applied voltage and resulting current. Ok, this sounds stupid, but:
The current current sense circuit can't sense negative current.

A modification of the circuit to enable control of the described situation (pushing down a ramp) would be to put the current sense resistor inside the H bridge (rigth beside the motor), and to use differential ADC inputs to measure it. The resulting value range would still be in the 0 - ADCmax, with 0A being somewhere in the middle, a count of 0 meaning a negative maximum current, and ADCmax meaning a positive max current. Because both positive and negative currents could be measured, the quadrant of operation of the DC motor could be detected (because the sign of the applied voltage is known), and appropiate control action could be taken. In the ramp analogy, if the robot is going down the ramp and it tends to get away from you, then you reverse the control voltage, so that the motor behaves like a generator, effectively braking the rate of descent, and maintaing control of the robot speed.

I've heard about the ""torture rack"", where a servo is fixed to a table, and an off center weight is attached, and I've heard comments about how the weight goes up at a controlled speed, but goes down way too fast. If the weight is big enough, this ""out of control descent"" explains it: the openservo can't detect that the weight is actually helping the motion.

There are 2 problems with implementing this type of control in the openservo:
1.- The ADC input maximum voltage can't exceed Vref. Basically this means that Vref would have to be the full motor supply voltage, which means the resulting ADC values could have a higher noise content.
2.- The component count would be much higher, as well as board real estate requirements.

Locked-antiphase sounds good, and has some advantages from a control and implementation point of view. However, it has the same problem as PWM: basically, you have to be able to sense the sign of the current, just like for sign-magnitude PWM, otherwise you don't know what quadrant you're operating in. The difference is that the Locked-antiphase design takes all 4 quadrants into consideration from the beginning, where sign-magnitude PWM has been simplified over the years to the current openservo design for small applications, in the interest of lowering costs and reducing component sign and circuit complexity.

In Locked-antiphase, if you have a greater than 50% duty cycle, the DC motor acts as a low pass filter, and the result is a positive DC voltage applied to the motor, right? In the ramp analogy, the exact same things happens as with PWM: The motor can start acting as a generator, and you won't really know it until you detect the sign of the current.

One of the reasons behind the H bridge simplification resulting in sign-magnitude PWM is that, usually, when used in applications that have some sort of gear system or equivalent motion reduction/torque increment system, the motor will always move in the direction you tell it to, and it is rather rare that the servo will regenerate. Just try turning the servo shaft with your hand, its very hard.

Whew! another long-winded explanation. Maybe I should stop that...

Cheers,
ZZZ

[mpthompson]

Zedd, my ignorance is going to be exposed by this question, but here I go. I've seen a lot of references to ""quadrants"" regarding PWM control. Can you explain this or provide a link to a brief explanation?

Also, regarding sign-magnitude PWM of the OpenServo, we should be able to gain control of the servo in the situation where an asymetric load is placed on the servo such as a weight at the end of an arm moving with gravity. Rather than the servo continuing to push the arm to reduce error, we the servo to apply braking against the pull of gravity to the extent needed for the arm to move at the desired angular velocity. The current PID algorithm doesn't do this, but it seems it shouldn't be too hard to do by making the algorithm more senstive to velocity. I believe this is what you are trying to get at with cascaded control loops if I understand your document correctly. Perhaps this is similar to a hybrid algorithm I described in another thread where a positional driven PID algorithm is blended with a velocity driven PID algorithm. If my understanding is correct, it shouldn't really matter that the servo uses sign-magnitude PWM or locked-antiphase PWM. Both should be able to control the servo appropriately.

-Mike

[Zeddicus]

No problem Mike, here goes the explanation, and no sweat about knowing/not knowing things: I still know very little about TWI and multimaster networks, so we're even

Basically, in electronics, for any component you can draw a voltage vs. current graph of its behaviour. If the signs of the voltage and the current are the same, the component is behaving like a load. This means quadrants I (both positive) and III (both negative) I think... In an electrical circuit, this means that the current is flowing into the positive end of the voltage, and out the negative. Examples of this are resistors. A DC motor behaves like this when the Vemf is lower than the applied voltage Vi. When this happens, the applied voltage acts as a voltage source, and the Vemf acts as a load, which is why the motor speeds up (power transferred to mechanical rotation)

If the signs of the current and applied voltage are different, the component is acting like an energy source. Examples of this are batteries and current sources. This means quadrants II and IV. In an electrical circuit, this means that current is flowing out the positive end, and into the negative end. The DC motor behaves like a generator in these cases, i.e.: the Vemf is higher then the voltage at the terminals. As a result, the voltage source gets charged. This is the same principle that was used to recharge the battery in a car in times past, before the alternator was adopted. The engine would turn a generator, which would produce a voltage, which was applied to the battery to recharge it.

There is no way of really knowing in what quadrant a DC motor is operating in, of you don't have both the current and voltage signs. The openservo can't detect opposing signs, because the sensing resistance is outside of the H bridge. If the motor is acting as a load, no matter the direction of rotation, you can only sense a positive current, i.e.: flowing from + to - from the voltage source, or from top to botton in the circuit schematic. If, for a certain direction of rotation, the motor should act as a generator, the current would flow from - to +, or from bottom to top in the circuit. This would create a negative voltage entering the current monitor IC, and I don't think it can handle that. Since you can't detect the situation, a controller can't take an appropiate braking action. This is essentially an additional non-linearity of the system, which I haven't taken into account yet in the control strategies I have proposed, basically because I'm still trying to figure out the ideal situation.

As long as this situation doesn't happen (which means rather low speeds), the control strategy I proposed should work fine.

As for the current control loop, the idea behind it is to have a stable current even when the position is perturbed, and avoid a wildly changing one.

All the above explanation is just one of the reasons behind current control loop. The main one is to make sure it doesn't go out of a range that the user specifies, or if it does, that it does it for a very short period of time (like the overshoot in the PID).

As for locked antiphase, it is mainly used when you really, absolutely, necessarily have to have very accurate control near 0V. This is usually a problem for PWM, because you have to stop using one switch and start using another, which is basically a discontinuity in the applied voltage. In an ideal world, the graph for output voltage vs. PWM output would be a straight line y=mx. In reality, there is a tiny deadband near 0V. This does not happen in locked antiphase control.

An example of this type of application is the Thing, which is an implementation of the inverted pendulum problem. You need to control the position angle so that the person riding it maintains balance. At this point, you have to control near 0V all the time, so that the Thing stays upright, with 0 speed. I wouldn't be surprised if locked antiphase is used.

[Zeddicus]

Damn, I lost part of the explanation, seems there's a maximum messsage length

as I was saying:
I should mention that the openservo is curently using X style PWM, which means that either Q1H and !2L are on, or Q1L and Q2H are on. This was done to simplify the circuit, the control lines and the uC code, and I agree with it for our application, but there are other PWM strategies that could be used, that use all 4 switches independantly. This is usually done when noise reduction is needed, or when harmonics need to be taken into account (i.e.: electrical contamination to the source). The implementation of this type of PWM is alot more complex from a theoretic point of view, but the benefits, when required, are quite good.

Oh, just found this:
http://www.danahermotion.com/education/learn_about_mc/servohandbook/motor/four_quadrant.php

It shows the 4 quadrants, but as voltage vs. torque. Sinve the torque resulting from the electrical component in the DC motor equation is proportional to the current, it's essentially the same thing.

Hope I helped?

Cheers,
ZZZ

[Zeddicus]

I forgot to mention that locked antiphase can be implemented in the openservo with the current hardware, but with the same problem as sign-magnitude PWM: you can't detect 2 of the 4 quadrants.

I should also mention that locked antiphase does indeed have lower efficiency then PWM, which results in the motor heating up more. This is because the AC component of the result of low-pass filtering is higher than for sign magnitude PWM, because the rate of decay of the current is higher. If there is any interest in this, I could probably work out the equations for both cases, for comparison.

Cheers,
ZZZ

Getting some z's now, 3am...... yawnn...

[mpthompson]

Yes, it did help. Thanks for the clear explanation.

When I implemented current monitoring on the OpenServo my intention was not for it to participate intimately in the motion control. This may explain it's rather simple design. Instead, current monitoring was/is intended to give the MCU some sense of how much current was being consumed by the H-Bridge from the battery so that the MCU could it could take evasive action should the current swing out of an expected range for some duration -- probably indicating an obstructed motor. Together with the temperature sensor built in the original ATtiny45 design it would give the OpenServo some extra awareness about the environment. Unfortunately the ATmega8/168 doesn't share the temperature sensor feature.

At this point I'm not too eager to change too much about the OpenServo v2.1 design because I want to shift the emphasis for a while from hardware design to software design. I'll soon have a biped robot to build . Changing resistors or capacitor values and other minor tweaks are fine, but I'm reluctant to invest too much in a new H-Bridge design or current monitoring if the functionality of the OpenServo can be brought to parity with commercial RC servos without it. This is not to say that someone else couldn't use OpenServo as a starting point to push the design a lot further without my help. Encouraging such development is one of the purposes of the OpenServo site. I'm hoping anyone who does so is willing to contribute the work back to OpenServo so others (and myself) can benefit.

That being said, over the next few months I'm very interested in what can be done within the limits of the v2.1 hardware for the OpenServo firmware to be the best that it can be. For instance, I'm very interested in coming up with an algorithm that will function well with non-linear servo loads such as we described. This could be particularly important for control of limbs of a biped robot which will surely undergo such non-linear loads. I'm also interested in the motion issues and challenges that Barry has identified for his robot arm -- once again the biped limbs will have similar issues when it comes to coordinating limb motions.

Once you get the hardware to assemble your own OpenServo I think you'll gain an appreciation for how minimal the system is. When I look at the design of the HiTec HSR-5995TG as discussed in this thread it's interesting to note the similarities between it's design and that of the OpenServo. While I'm not suggesting the OpenServo design is equal to the commercial HSR-5995TG, hopefully it's not too far off that we couldn't hope to control the OpenServo at least as well, if not better. The magic will really be in what we can achieve in the firmware with hardware that fits within an 18mm x 18mm footprint.

-Mike

[Zeddicus]

I agree Mike, I don't think a hardware changing the Hbridge design is practical at this point jut to get 4 quadrant operation. Like I said, for our purposes, the current design should be ok, and we can always cange it later if we want to (v3.0? ) Simple is elegant .

As for the hardware, I consider the openservo to be superior to the HSR-5995TG, except maybe for the digital conditioning that the HSR-5995TG does on the input bus, and the fact that it uses a crystal (faster uC). It's the only advantages I see that the openservo is missing, and both can easily be added later.

From a theory point of view, I think the openservo will allow for far better algorithms to be implemented. Like you said, in bipeds and robot arms, the loads are non-linear, which means the controller algorithms will have to be more sophisticated.

I'm-a-workin'-on-it...

Z.

[stone76567]

hi everyone..
thanks for all the information ive learned in this site..
btw this is my first visit in this site..
and thanks for accepting me..
thanks a lot and God Bless......
_________________
how to treat depression

[ervo]

Well, from what I have learned, the OpenServo uses sign-magnitude PWM, which certainly gives us the insurance to connect the motor, but for a certain amount of time. However, they do fail to give us the apt information when it comes to identifying the regeneration of power. However, there is still the insurance of modifying the circuit and controlling the situation even if that is to al limited time as well! Let us all wait for the proper solution here!
_________________
CAAS

[jhonharry]

At this point I'm not too eager to change too much about the OpenServo v2.1 design because I want to shift the emphasis for a while from hardware design to software design. I'll soon have a biped robot to build. Changing resistors or capacitor values and other minor tweaks are fine, but I'm reluctant to invest too much in a new H-Bridge design or current monitoring if the functionality of the OpenServo can be brought to parity with commercial RC servos without it.