New Parallax 360 Feedback Servo

Comments

I LOVE this servo! Finally got a few minutes to play with it. Slap a 1 uF smoothing cap across the output signal line and just read the position/voltage with an ADC. It doesn't get any easier than that!

Edit: Duh, yes it does. Use PULSIN, no cap or ADC required!

This is a high speed servo, I'm sure great for mobile robots. It's downright zippy, can't wait to get something going.

Ken, IMO you may also want to consider selling a slower version for more precision motion control applications (no need for multi-turn sail winch servos now). The minimum speed I can get (occasionally stalling) is about 6 RPM. I think a standard gear ratio servo (maybe metal gears) would make for a dandy robot arm.

Hope you sell a bazillion of these. I'm mentioning them in other forums already, and Mr. Roboto will def give 'em the nod. I'll post a video when I figure out something cool to do.

This servo just keeps getting better & better! It's an ABSOLUTE encoder! Am I dense, or is that not obvious in the product guide?

It uses a Hall effect sensor with some internal circuitry to generate the PWM position signal. I ASSumed that on powerup it would reset to zero but actually she comes right back to wherever I left her. Far out!

Even better, if you move the servo with the power off, it knows the new position on powerup! That's as great as it can be!

No, it's not really obvious. When Ken posted the video I suggested a narrated tour of what the servo could do, mentioning "Some folks might not see the benefit of this type of servo without more explanation." I still encourage someone at Parallax put together a "what this sucker can do" -type video.

How dey do dat? While I haven't taken one of these apart, a common technique uses a Hall effect sensor to detect the orientation of the poles of one or more magnets. Flux changes with rotation orientation. Hall effect encoders tend to be very, very expensive,. but there are now some lower cost versions, such as those for automative applications. Here's one general overview of the concept:

I built a stand for the servo with a large dial so that I could test accuracy and repeatability. It has a range from 0 to 999, with hash marks every two units (1/500 of a full rotation. The easiest thing I was able to check was the amount of backlash in the geartrain. The two insets in the photo below show the backlash when the servo is unpowered and when the needle is pushed one way until resistance is felt, then the other way. This amounts to three hash marks or .006 of a full rotation (2.16°). This backlash is between the output shaft and the motor, not between the output shaft and the encoder, where there appears to be no backlash. What this means is that the motor will have to rotate 6/1000ths of a full revolution before it can begin to correct a position error in the opposite direction from which it last moved. This will entail careful programming to prevent oscillations when the servo is "on-target."

Magnificent work as always, PhiPi! You're always one step ahead. That's a nice rig, much better than the simple pointer in my old video below. This servo could do a much better job of accurately recording and playing back a motion sequence. The high speed (AKA low gear reduction) nature of this servo makes it very easy to turn by hand.

I think I'd augment this servo with a single light sensor, and use that to monitor revolutions. It's fairly typical in industrial servomotors to couple an index sensor with absolute positioning. Not that it can't be done with just the absolute encoder, but it would simplify some applications. Would be cheap to do.

Which is not to say you couldn't do it, or wouldn't want to try! There are a pretty good number of videos on YouTube of people who have converted their servos to Hall effect control -- some are simple demos using external one-element sensors, and going up from there. Here's just one from a guy who used an off-the-shelf 3-axis compass module (X-Y only for this application). He has to keep the module external as the magnet is too strong for the default sensitivity of the compass.

This is definitely a good piece for Ask Mr. Roboto, where you could demonstrate the concept using discrete parts, then show it in a convenient $19.95 ready-made product.

I added an inertial load to the servo by taping a nickel to the needle:

Upon arriving at a fixed position, the servo tended to oscillate:

As before, I was using a proportional error correction algo with upper and lower velocity limits (i.e. no fancy PID stuff). But I think that this might be adequate if I also take backlash into account. We'll see ...

I modified the error correction to apply a higher lower speed limit if the error changed sign between corrections. That way I could lower the lower speed limit in general. This had the effect of canceling the effects of backlash without causing oscillations.

BTW, this is all being done in Spin. As soon as I have some code that I'm not ashamed of, I'll post it.

It's dead simple with the built-in encoder: increment revs on a high(990±)-to-low(10±) transition; decrement on low-to-hi.

How to handle this depends on the processor and its capabilities. Not everyone uses a Prop. On an Arduino, for example, you don't get one signal change at the index position, but nearly a thousand of them each second, this being the nature of PWM. That precludes the use of a simple pin change interrupt (just a few lines of code), which doesn't require running in the main loop. For an Arduino, having a signal interrupt means no transition will ever be missed, even if the single thread of the MCU is tied up in a long delay.

Other MCUs are going to introduce their own special limitations and requirements.

Just as an FYI, if you were to aftermarket an add-on magnetic absolute encoder, this would likely be among the less expensive options (about $48):

The RC lowpass filter converts the PWM to a smoothed voltage output. This is followed by two RC high-pass filters that pass the edges of the filtered PWM when the zero-point is passed one way or the other. The top Schmitt trigger is biased above the switching threshold and passes a pulse on a negative-going edge. The bottom Schmitt trigger is biased below the switching threshold and passes a pulse on a positive-going edge.

No external mechanical devices needed!

I'm sure erco can come up with something even simpler using a pair of CMOS 555s!

PhiPi,
Thank you for your interesting and well constructed experiments and useful tips/circuits on this servo.
Many of us would greatly appreciate your Spin code snippets (when you have time to post them), and we thank you in advance.
You should consider agglomerating your work into some sort of application note for the servo!

My original comment about the desirability of an index pulse was really a passive-aggressive way of suggesting an improvement, without it looking like criticism. This is already a superb product, but as a small enhancement it would maximize usefulness to users of other MCUs. It could probably be built into the existing servo without additional internal components, with only a modification of firmware and a second output pin.

I'm not sure a circuit with nine components and two pins is any better than a $1 IR module stuck onto the side of a robot with tape. You've exchanged one hack for another. Neither of these is a good solution. Again, not meant as criticism for what is an excellent first try, but it would be better if the index feature were available. It may be unnecessary in the Propeller, but not everyone uses a Prop. A single-core processor like the Arduino could better handle the timing, without resorting to the usual coding tradeoffs and limitations that come when implementing a fully-functional device with an involved main loop.

It was simply a suggestion to extend the market for the product by making it more universal for all kinds of users. I want to see Parallax succeed with this as much as the next guy here.

Wait. . .what, what, Gordon, you want us to do a total redesign and put all those parts Phil included on his schematic into the servo? And what is the Arduino thing you're talking about? I'll get the servo factory to put the Arduino, that pile of parts, and the other stuff into the servo. Do I understand this correctly? Andy, get your ticket!

I did most of my initial testing running a single servo. It was powered via USB power on the Activity Board. I wanted to test out the abdrive360.h and decided to use external power for the 2nd servo. When doing so I started with the maximum voltage of 8.4 V and noticed a lot of overshoot. I understand the software is on development phase, but also wonder if this is normal.

The LED voltmeter displays servo voltage. There's a 5 V test and an 8.4 V test. I pick random numbers using the demo code on the product page.

Overshoot has a lot to do with the servo's inertial and static loads, along with the drive voltage. The P(ID?) parameters will probably have to be tuned on a case-by-case basis for maximum effectiveness. Also, the overshoot will likely be less acute when the wheel is mounted on a robot, due to the increased static load.

BTW, standard analog servos are not immune to this behavior either. The designers of those have to strike a balance among all the uses to which they might be subjected. I had a particularly vexing problem with vibration (a concomitant of overshoot) with one of them on a robotic xylophone player that I built. The mallet would not stop its tremor when not striking a key, no matter what programming I tried to quell it.

If you want a cheap way of getting them, just use Amazon Prime. We're not driven by brick-n-mortar stores, unless we start making stuff to sell in Home Depot or Lowe's (the only sector of retail that seems to be growing).

I'm certainly not smart, but these things most people can see. When you work with retailers, it starts out with big orders and lots of excitement. They hold a lot of inventory and they always owe you lots of money for their big orders. Once the situation starts to decay and they figure out they're having losses, two things happen to the suppliers:

- the inventory gets marked down really low, closing out the supplier's products
- payment to the suppliers is delayed or doesn't happen

Then the bankruptcy filing happens. Now you're really screwed as a supplier. Don't count on a penny from any post-bankruptcy closures. Somehow, though, they keep selling your inventory to pay debts to other parties. It's a train wreck. Lawyers certainly can't help you, either.

The driver has four methods: Start, SetPos(degrees), GetPos, and Width(USec). GetPos returns the current position in degrees. SetPos drives the servo to the indicated position, and Width forces a pulse width.

It starts a PASM cog that sends a pulse to the control pin every 20 msec and returns the duty factor every 4 msec.

The demo exercises the driver by slowly spinning the servo, returning and displaying the position. It then uses SetPos to turn in a circle in 5 degree increment. It then sets a number of random positions.

This program thinks it is doing a much better job than it actually is and I don't understand why. In the second exercise, it sets the position of 5, 10, 15,...355 degrees. Now SetPos returns what it thinks is the final position which always agrees, within +- 1 degree of the commanded position. But what actually happens is that sometimes the servo only moves on every other command. It is as if it moves 10 degrees and 0 degrees alternately. But the feedback says it is moving 5 degrees each time.

I was able to verify the 5 degree problem here also. That was with very light finger pressure on the servo horn. I ran the program with much more pressure on the horn, and it seemed to advance through all the 5 degree advances with no skips. It may have to do with no loading on the servo. May be due to gearing, backlash. Will try some more testing.

I moved the conversion from pulse duty factor to degrees into the PASM cog and I moved the positioning correction into the PASM cog. That is a good thing since it means you can command a position and go do something else while the driver does the positioning. I need to add something to indicate when the driver is done.

I am not yet using proportional control; just drive at a fixed velocity to the commanded position.

It oscillates a little (well sometimes a lot) but always settles. It consistently gets to within 2 degrees.

I'm certainly not smart, but these things most people can see. When you work with retailers, it starts out with big orders and lots of excitement. They hold a lot of inventory and they always owe you lots of money for their big orders. Once the situation starts to decay and they figure out they're having losses, two things happen to the suppliers:

- the inventory gets marked down really low, closing out the supplier's products
- payment to the suppliers is delayed or doesn't happen

Then the bankruptcy filing happens. Now you're really screwed as a supplier. Don't count on a penny from any post-bankruptcy closures. Somehow, though, they keep selling your inventory to pay debts to other parties. It's a train wreck. Lawyers certainly can't help you, either.

Anyone interested in this kind of stuff should check out a copy of Andrew Bunnie Huang's "The Hardware Hacker: Adventures in Making and Breaking Hardware." He discusses some of the mistakes people make crowdfunding products and then thinking about retail after the fact. Also he has various tips scattered throughout the book - a lot is repeats from his blog, but the book is priced quite low so why not support him. I like his style - instead of getting angry about some of the differences in how business is conducted in China, he gets more philosophical about it.

Even one little tip could save someone far more than the price of the book. Separately he has a book called "The Essential Guide to Electronics in Shenzhen" that you can pickup at Adafruit. This one looks useful for those trying to buy parts from Chinese vendors.