"Position Data Feedback"

Lynxmotion
11

You can buy a Y harness to connect the two servos, that has a reverse built in to switch one of the servos and also a small pot to adjust slight offset so the servos match.
This is the cheap and effective way to do it aside from using a regular Y harness, which I wouldn’t recommend in a rigid mounting system.

chiefaircraft.com/rcmsec/Mod … sions.html
http://i138.photobucket.com/albums/q253/gfisher2002/EXP_EXRA325.jpg

It is also good to match the servos by checking them on the Hitec programmer. And using a matchbox will also ensure that they travel exactly the same distances at the same speed. This is the more expensive solution, but very effective. I’ve used up to 6 of these matchboxes on one aircraft and they never fail and perform flawlessly.

horizonhobby.com/Products/De … ID=JRPA900
http://i138.photobucket.com/albums/q253/gfisher2002/JRPA900-450.jpg

12

I should clarify why the AX-12s are a good choice. Probably the simplest reason is cost. For under $50 you get 220 oz-in of torque with position, voltage, and load feedback over a TTL network. The command set is easy to use and you don’t need a PWM servo controller, special cables, or configurations.

13

Can you talk to an AX-12 from a Linux box, i.e., without running any Robotis software which requires Windows? I know that the CM-5 controller will talk to a PC over a serial line, but will it act as a simple protocol converter out of the box, or are you forced to run some Robotis code on the PC just to talk to it?

14

The AX-12s are not platform dependent. Each AX-12 has a microcontroller inside that does all the heavy lifting. If you can send/receive a command like one below at 1 Mbps you’re good to go.

Tx - center
FF FF 07 05 03 1E CD 00 05

Rx - status packet
FF FF 07 02 00 F6

15

It’s not that simple. The AX-12s use a shared TX/RX data line; you cannot talk to them over an RS-232 serial line. You need some piece of hardware to handle the multiplexing for you, i.e., a protocol converter. If you’re not looking to build your own custom hardware, then you need to be able to use the CM-5 controller to interface between your computer’s RS-232 serial port and the AX-12s. My question was: can you use the CM-5 this way without running any Windows-specific software?

16

It is that simple. You might want to lookup multiplexing. Anyway, under the sheets the CM-5 is an Atmel microcontroller programmed in open source version of C. The source is free too. So yes, the CM-5 would be right at home on any platform.

17

Open source is always good. But I don’t want to have to go find a compiler for this thing that will run on my Linux system. I just want to talk to the servos. My impression from your reply is that if I plug a CM-5 into my Linux PC’s serial port, and attach an AX-12, nothing useful is going to happen. I have to load code into the CM-5 first. Which means I have to get that code from someplace, and I have to have software on my PC to do the loading.

Do you know what tools people are using to work with the CM-5 under Linux? I don’t feel like reinventing the wheel.

18

I know that there is a lot of information up on the robosavvy forums about interfacing the AX-12 or the like to a PC or gumstix and the like. There is also a TikiWiki that summarizes these projects up at:
bioloid.info/tiki/tiki-index.php?page=User+Projects

19
  1. You do not need a CM-5 to talk to an AX-12.
  2. The Atmel micro in the CM-5 comes programmed.

If you connected a CM-5 to your Linux box and the CM-5 to an AX-12 network then issued the following command through your favorite terminal application at 56700

go 3 512
67 6F 20 33 20 35 31 32 0D

will move the AX-12 with the ID of 3 to position 512.

go 3 512 512 (half speed)

go 3 512 512 512 (half speed and torque)

DUMP - grab all value from the AX-12 table

SEARCH - find all AX-12s on the network

Theses are just a few commands

20

Thanks, kurte and agavejoe. This is the information I needed.
I’m looking forward to experimenting with servos that give position and torque feedback.

21

In spite of all the hype and hoopla I see about position feedback from servos, I don’t think I’ve seen an actual working project that uses it. Before spending a lot of $$$, it might pay to find some working instances to see if it is really a useful asset.

22

Tekkotsu already uses this on the AIBO, in several ways.

If your robot starts out in an unknown state on power-up, and you want to bring it to a good state, you need to know where its limbs are so you don’t thrash around wildly. This is a real problem with the Hitec servos since there’s no way to use the SSC-32’s speed control feature if the servos’ starting positions are unknown.

We also use force feedback to allow the user to “mold” the AIBO’s body by pressing on it; the system senses this and relaxes the servos a bit so the limb can move.

We used force feedback to allow the AIBO to press keys on a keyboard without applying too much pressure, see this video demo.

But what we really want this feedback for is fine control of gait on a hexapod.

23

Position feedback is used on the RoboNova in a similar way.

You can read the servo positions on power up and set those as the current position for later point to point moves.

Some work has been done using position reading for force feedback, since the difference of actual position from desired indicates the torque applied, though fairly coarse, it does work.

The most used facility is the catch and play where you move limbs to the desired position and capture the pose to make up programmed moves.

To go back to the original post. If the type of servo can be changed, then the open servo based on a gear motor may be an alternative. This would allow a more powerful motor, or two motors to be used without problems. It will have position feedback

It would be good to know more of the mechanical configuration. A pendulum can be made to perform with a very wide range of power demands. Also with gear motors you can trade torque for speed.

24

Well, if you have an ssc32 and a HS-422 servo, and are willing to do a little testing, then you could quickly find out if you can get useable position feedback from the HS-422. If you are inerested in doing some actual testing, then start a fresh discussion on the subject on how to do the testing.

25

Position feedback is very useful, very quickly. Force/Current feedback is much harder to effectively use as it’s often pulsed (at a relatively low frequency with analogs) and entirely dependent upon the variable loading of the joints.

Record/Playback of position capture over time

26

Ok well with regard to several posts here, gad where to start!

Ok well, I’m not too stressed about using the AX-12. and i prefer the servos for reasons listed below…

um ok first some info about my pendulum:

The Robot itself is a remotely controlled ball, with a dynamically stabilized internal platform. Hence the pendulum. So very simply the pendulum hangs from the center of the sphere from a truss. The servo’s that move the pendulum are connected to the truss and to each other in a kind of universal joint configuration. This allows me to swing the weight left/right or forward/back and allows me to place the CM of the pendulum anywhere in the lower hemisphere of the robot…

so there you go, my patent application is now shot! haha!

Ok, so my reason for using servos are:
1: small compact package, big torque
2: they are easily interfaced to a microchip or the like (I’m using the DsPIC30F family from microchip)
3: They move to specific positions, which ultimately makes my life easier than designing a feedback network for a gear motor… (which can sometimes exhibit some rather interesting oscillations depending on your compensation)

The reason i am using positional data feedback, is that for the ball to effectively balance itself, it needs to know where the pendulum is in order to predict the kind of dynamic response it can expect from various possible actions…

Now this is how I am interfacing the servos…
http://i62.photobucket.com/albums/h91/robrobstation/DSC02843.jpg
http://i62.photobucket.com/albums/h91/robrobstation/DSC02840.jpg
using a rigid mounting made of meccano…
so er, haha it should be interesting…

I don’t have a Hitec servo programmer, so I’m setting my sights on the programmer cable mentioned by ribbotson:
lynxmotion.net/viewtopic.php?t=2539&start=0&postdays=0&postorder=asc&highlight=

I can easily control the speed of both servos by using the micro to give discrete positions along a set trajectory to achieve a certain acceleration or angular velocity of the pendulum, it updates once every 20 milliseconds, and the bandwidth of the physical plant is estimated to be about 10-15Hz… so updating my actuators at 50Hz (standard servo time base?) should be fine… as long as i can calibrate them accurately enough…

So yeah!
Thank you guys for all the input!
My next post will most likely have a lot to do with that serial interface and the HMI thingamahjig…
Fun!

27

I will be sure to test them when my SSC-32 Arrives :smiley:

28

Is the pendulum project something that depends on pendulum physics, or is it a tilt detection/counter balancing weight setup?

29

It depends on pendulum physics a bit, since the dynamic response will have a lot to do with the angular velocity and acceleration of the pendulum and its momentum,

But the steady state response (ie when the ball is sitting still and nothing bothers it) should be dominated by the position of the pendulum, which will act to apply a torque to the internal truss, balancing it against something like a sloped surface or holding the entire structure at a user defined angle…
something like that…

30

Just a couple of ideas.

Looking at you photo and the idea to use 2 servos in opposite directions. I think it best not to mechanically link the servos, but to give them seperate pendulums. Reverse the directions, but avoid having too much problems with relative position.

You are probably best to use serial HMI to the servos. This will mean you need to invert the dsPic UART in and out. Transactions in serial mode are 7 bytes at 19200 = about 4 millisec. you will need one out to set the position, and one in to read position which can also set the speed. You might consider a dsPic with two UARTS.