Phoenix Math

[km6vv]

First off, let me start that I’m not questioning the code (it’s great!), I’d just like to follow the math a little better. I have stock LM legs (C or A) that I’ll be using, and not the Phoenix (P?) legs to work with. Hence I need to work out a few points.

As I’m starting to set up my 'quad legs (Octopod too?) and Phoenix code for “Little Cat”, I’ve run into some questions that I don’t recall encountering when building a hexapod from Powerpod-derived code. Or maybe I just forgot!

The first is the servo limits in Basic-coded degrees. I aligned my legs for 1500, and noted the limits in R/C servo pulses seen in Powerpod.

I fired up SSC-32 sequencer to work out the servo range limits. I also noticed that in addition to the pulse values there is a servo angle displayed in degrees. Yay! However the angle in degrees was automatically changed to ± 90 to end at my adjusted servo range! So getting a degree from that wasn’t very useful (maybe I’m using it the wrong way.

Servos aren’t typically calibrated or consistent either. So I can’t just copy the angles seen. Maybe if I leave the limits maxed out?

So I now have the pulse ranges that were useful in the PowerPod code, but Phoenix uses degrees! Anybody have a better way to come up with the limit angles in degrees?

In the PowerPod code the angle was scaled to servo pulses in an equation similar to this:

[code]/* scale the pulse to the range of the pulse / range of the angle /
/ Hp = ((2090 - 960) * (? - 21) / (107 - 21)) + 960 */

Hp = (unsigned long)(HipH_PULSE_MAX - HipH_PULSE_MIN) * (unsigned long)(HipH_Angle - HipH_ANGLE_MIN) /
(unsigned long)(HipH_ANGLE_MAX - HipH_ANGLE_MIN);
[/code]

Which I now have my doubts about. It looks like it would “compress” the angle to fit the servo range! I’ll have to do some more thinking about that later.

Back to the point, in Xan’s Phoenix code we see:

-RFCoxaAngle +90)/0.10588238)+650

With a “magic” number 0.10588238 which I take to be some scaling of pulses/ 90 degrees or something.

And 90/0.10588238 does in fact = 850 or very close.

650 + 850 = 1500, so I’m probably thinking on the right track, although I haven’t worked through all the “+90” and “* -1” stuff.

How did we come up with 650 (end of travel?) and 850? (if indeed that’s what it’s for) Good for a particular servo? I have a mix of '645 and '475 servos. I haven’t characterized them as yet. (the would all probably be a little different).

I could mount a compass (drawing instrument) on a servo shaft, and “characterize” my servos. Was that done to derive the 0.10588238 constant above? Or was the constant obtained from some other source?

What would be useful is a set of ‘C’ and ‘A’ leg constants, like is done in Powerpod.

Can we get some commentary on this topic?

Thanks!

Alan KM6VV

[robotdude]

I can only comment on the Sequencer program. I believe you have the ability to set the two angles, so in fact you can calibrate the servos available throw to correlate to real angles.

[robotdude]

@KM6VV

What would be useful is a set of ‘C’ and ‘A’ leg constants, like is done in Powerpod.

Ah ha, yes that would be useful info when we finally upgrade the Phoenix tutorial into a (anyhex using Phoenix code) tutorial.

[zenta]

@KM6VV

Back to the point, in Xan’s Phoenix code we see:

-RFCoxaAngle +90)/0.10588238)+650

With a “magic” number 0.10588238 which I take to be some scaling of pulses/ 90 degrees or something.

And 90/0.10588238 does in fact = 850 or very close.

Hi Alan,

It looks like you’ve answered your own questions.

@KM6VV

650 + 850 = 1500, so I’m probably thinking on the right track, although I haven’t worked through all the “+90” and “* -1” stuff.

The “*-1” are for direction. The +90, well you pointed it out yourself:

And 90/0.10588238 does in fact = 850 or very close.

@KM6VV

How did we come up with 650 (end of travel?) and 850? (if indeed that’s what it’s for) Good for a particular servo? I have a mix of '645 and '475 servos. I haven’t characterized them as yet. (the would all probably be a little different).

I believe Xan is the best to answer this. But there are several ways to solve this. It all ends up with 0 deg = 1500 and 90 deg = 2350 and so on… I bet the 645 and 475 are pretty close to this.

@KM6VV

I could mount a compass (drawing instrument) on a servo shaft, and “characterize” my servos. Was that done to derive the 0.10588238 constant above? Or was the constant obtained from some other source?

I remember Xan told me how he came to this value, I believe he made a program for testing/calibrating exactly that. For example for Felix I used some 5645 servos and I had to use some very different values. I used PEP and Visual SEQ to calculate the constant. I also made a version for Felix that didn’t use this constant but instead the program calculated the accurate pwm value for each servo. By using the calibrated values for each individual servos center and end points (a bit more complicated and time taking…). The end result was perfect though.

[km6vv]

Yes, I was thinking about that on my “lunch walk”, and it I set 650 and 2350 (1500-850 and 1500+850) as the += 90 degree limits, I think it would allow me to directly read degrees! that is, if I can collaborate the 650 and 2350 points for my servos. That would simplify things! I don’t “actually” need the Sequencer program to limit my moves.

Thanks!

Alan

@Robot Dude

I can only comment on the Sequencer program. I believe you have the ability to set the two angles, so in fact you can calibrate the servos available throw to correlate to real angles.

[km6vv]

Hi KÃ¥re,

Yeah, I have a habit of seeing a solution after I’ve properly composed and submitted question(s)!

Ah yes, *-1 would be a direction change. And does Phoenix use left- and right-hand legs? I seem to recall that.

I might have to make a simple program as well to satisfy my curiosity! Perhaps I can even verify with the Sequencer program.

I did discover that Lynxterm has been improved, and now can read/write the registers of the newer '168 uP. However it needs a means of setting the corrections to all servos for the next time the program is loaded. As it is, one has to “read” data, then step through all the servos and “click” on them to get them set back again. Minor nit. But confusing if you haven’t run into it before! Perhaps Lynxterm, Powerpod or maybe a new program could generate a full calibration table with offset, ± 90 degree points, and step scale for any servo wanted. Ideally it would generate a bit of Basic “con” constant declaration code that could be cut and pasted into a 'bot program from an outputted text file.

Calculating/calibrating the ± 90 degree points for each servo could be a chore! But I can see how it might improve the smoothness of the leg transitions.

Well, I’ve decided to add the “angled” C brackets to my 4DOF legs, so I’ll be re-assembling my legs and doing calibration all over again anyway…

Thanks for the info!

Alan KM6VV

@zenta

@KM6VV

Back to the point, in Xan’s Phoenix code we see:

-RFCoxaAngle +90)/0.10588238)+650

With a “magic” number 0.10588238 which I take to be some scaling of pulses/ 90 degrees or something.

And 90/0.10588238 does in fact = 850 or very close.

Hi Alan,

It looks like you’ve answered your own questions.

@KM6VV

650 + 850 = 1500, so I’m probably thinking on the right track, although I haven’t worked through all the “+90” and “* -1” stuff.

The “*-1” are for direction. The +90, well you pointed it out yourself:

And 90/0.10588238 does in fact = 850 or very close.

@KM6VV

How did we come up with 650 (end of travel?) and 850? (if indeed that’s what it’s for) Good for a particular servo? I have a mix of '645 and '475 servos. I haven’t characterized them as yet. (the would all probably be a little different).

I believe Xan is the best to answer this. But there are several ways to solve this. It all ends up with 0 deg = 1500 and 90 deg = 2350 and so on… I bet the 645 and 475 are pretty close to this.

@KM6VV

I could mount a compass (drawing instrument) on a servo shaft, and “characterize” my servos. Was that done to derive the 0.10588238 constant above? Or was the constant obtained from some other source?

I remember Xan told me how he came to this value, I believe he made a program for testing/calibrating exactly that. For example for Felix I used some 5645 servos and I had to use some very different values. I used PEP and Visual SEQ to calculate the constant. I also made a version for Felix that didn’t use this constant but instead the program calculated the accurate pwm value for each servo. By using the calibrated values for each individual servos center and end points (a bit more complicated and time taking…). The end result was perfect though.

[robotdude]

@KM6VV

Yes, I was thinking about that on my “lunch walk”, and it I set 650 and 2350 (1500-850 and 1500+850) as the += 90 degree limits, I think it would allow me to directly read degrees! that is, if I can collaborate the 650 and 2350 points for my servos.

This sounds about right. We chose 500 to 2500 for the range of the SSC-32 to accommodate all analog servos.

[km6vv]

Yes!

I have these comments in my current hexapod (Powerpod) code:

/* LEG MIN/MAX angles for typical 3DoF Legs, CH3-R type */ /* SSC32 range .50mS to 2.50mS */ /* 1500 (1.50mS = 0 deg) neutral (180 deg / 2000 steps) */ /* 1000 = -45 deg. 500 = -90 deg, 2000 = + 45 deg, 2500 = +90 deg */

and KÃ¥re/Xan are using 650 and 2350, possibly from some direct measurement of their servos, so I’ll just see what my '475 & '650 servos do.

Thanks!

Alan

@Robot Dude

@KM6VV

Yes, I was thinking about that on my “lunch walk”, and it I set 650 and 2350 (1500-850 and 1500+850) as the += 90 degree limits, I think it would allow me to directly read degrees! that is, if I can collaborate the 650 and 2350 points for my servos.

This sounds about right. We chose 500 to 2500 for the range of the SSC-32 to accommodate all analog servos.

[tom_chang79]

@zenta

I remember Xan told me how he came to this value, I believe he made a program for testing/calibrating exactly that. For example for Felix I used some 5645 servos and I had to use some very different values. I used PEP and Visual SEQ to calculate the constant. I also made a version for Felix that didn’t use this constant but instead the program calculated the accurate pwm value for each servo. By using the calibrated values for each individual servos center and end points (a bit more complicated and time taking…). The end result was perfect though.

Did you notice that after calibration that your hexapod walked a lot more straighter? I’ve always wondered how much “drift” there are due to inaccurate calibration and from the servo slop and resolution…

From my observations, hobby servos suffers from repeatable accuracy because of the resolution of the feedback loop right?

For instance, for one of my 645:

1. PWM = 1650

2. PWM = 1700

3. PWM = 1650 <— slight difference from the first PWM = 1650

and then the other direction:

1. PWM = 1650

2. PWM = 1600

3. PWM = 1650 <---- slight difference from the first PWM = 1650

That example is without loading, I’ve noticed this when I first fire up my servos by itself before a robot build.

The accuracy suffers even more when there’s loading and friction involved, which is nearly unavoidable…

I’ve always pondered if there are any tiny and light encoders we can put onto the horns. However, this encoder will have to have better resolution than the servo itself, otherwise it defeats the whole purpose!!!

But I’ve always thought that any of these inaccuracies of the hobby servos, are negligible in our application because:

1. We’re not using it for control systems for an application like space (where a small fractional degree of error can have something end up in the middle of nowhere).

2. There are too many other unknown factors such as tolerance of brackets, how each servos are bolted on in the ASB-04 brackets (I’ve noticed that you have to be careful when bolting on the servo into the ASB-04), frictional difference between each tip of the legs, slop in the servo spline, resolution of the servo itself.

I really liked it when Matt Denton attached a rotary head to one of his hexapods… Since he is using hobby servos as well, the tolerance/resolution of the milling should be nearly equal to the tolerance/resolution of the entire system (hexapod)…

Hey, I’ll be happy if my hexies are accurate and have enough dexterity to go to the fridge and grab me a cold one in the near future…

I know some of you guys are working with FSRs… In order to “calibrate” the legs using FSRs, you will also need a tilt sensor to complete a “self-calibrate” scheme?

[xan]

Hi Guys,

@KM6VV

and KÃ¥re/Xan are using 650 and 2350, possibly from some direct measurement of their servos, so I’ll just see what my '475 & '650 servos do.

Zenta gave a pretty good explanation about where the magic number came from. Can’t do it any better. The values are directly measured from a few of my servo’s. The value was/is pretty accurate enough for our application.

We found out that there is some difference between one servo or the other. So the best method should be that we have a “magic numberâ€

[km6vv]

Hi Xan,

I see how the numbers work now.

I use Sequencer to study a few of my 475 servos. They behave pretty well. I might shift to 645’s on a few axis.

I’m thinking I need an encoder that I can attach to the servo horn, then I could automate a few tests to characterize servos. But first I must determine if present IK calcs for a hexapod will work for a quadruped!

I did a redesign on my 4DOF leg; I can flip the C bracket and roll servo with it’s universal bracket basically upside down. The hip V servo range is increased, however I loose access to the SHCS that sets the tension on the LPA joint. Not sure if I will change to the new design or not.

Alan KM6VV

@Xan

Hi Guys,

@KM6VV

and KÃ¥re/Xan are using 650 and 2350, possibly from some direct measurement of their servos, so I’ll just see what my '475 & '650 servos do.

Zenta gave a pretty good explanation about where the magic number came from. Can’t do it any better. The values are directly measured from a few of my servo’s. The value was/is pretty accurate enough for our application.

We found out that there is some difference between one servo or the other. So the best method should be that we have a “magic numberâ€

[xan]

Hi Alan,

@KM6VV

I’m thinking I need an encoder that I can attach to the servo horn, then I could automate a few tests to characterize servos.

Sounds like a interesting thing to do. This would give a good view of the PWM – angle characteristic.

@KM6VV

But first I must determine if present IK calcs for a hexapod will work for a quadruped!

The IK calculations can be easy adapted for a 3DOF quad. Adding a extra DOF will make things a lot more complicated. The IK calculations will return more then one solution. You’ll need to find a logarithm to find the most suitable.

@KM6VV

I did a redesign on my 4DOF leg; I can flip the C bracket and roll servo with it’s universal bracket basically upside down. The hip V servo range is increased, however I loose access to the SHCS that sets the tension on the LPA joint. Not sure if I will change to the new design or not.

I’m not really sure how the setup is changed. A few pics will defiantly clear that up. Hint hint

Xan

[km6vv]

Hi Xan,

I already have panel shaft encoders with 256 CPR resolution. And if one detects the phases in quadrature, then that can be multiplied by 4. I’ll have to mill up a little shaft coupler from the servo horn to a 1/4" shaft. Or maybe order one from Servo City or the like.

@Xan

Hi Alan,

@KM6VV

I’m thinking I need an encoder that I can attach to the servo horn, then I could automate a few tests to characterize servos.

Sounds like a interesting thing to do. This would give a good view of the PWM – angle characteristic.

@KM6VV

But first I must determine if present IK calcs for a hexapod will work for a quadruped!

The IK calculations can be easy adapted for a 3DOF quad. Adding a extra DOF will make things a lot more complicated. The IK calculations will return more then one solution. You’ll need to find a logarithm to find the most suitable.

logarithm? I’ll assume you mean algorithm. ;>)

I was thinking of just keeping the new “roll” axis out of the equations. Maybe the roll works into the body IK better. I haven’t even started to look at that!

@Xan

@KM6VV

I did a redesign on my 4DOF leg; I can flip the C bracket and roll servo with it’s universal bracket basically upside down. The hip V servo range is increased, however I loose access to the SHCS that sets the tension on the LPA joint. Not sure if I will change to the new design or not.

I’m not really sure how the setup is changed. A few pics will defiantly clear that up. Hint hint

Xan

Ah yes, hard to get a good idea of the changes from a text description. I did shoot a few photos last night of the new leg, I’ll get some photos up as soon as I can.

And I also discovered last night that the universal bracket will hit the screw of the LPA servo horn, which isn’t too good!

I have milled and added a 062" thick spacer between the driven gear and the C bracket (universal bracket on new design), in order to keep the frame of either bracket from catching on the drive gear of the LPA.

Alan KM6VV

EDIT:

I don’t see a “read encoder” function in Atom Basic PRO. I do see “interrupt on” functions, so that’s encouraging! Kurt, you said you implemented an ASM function for reading an encoder? Did you use the interrupts, and did they further interfere with bit-banged routines?

[kurte]

Hi Alan,

The encoder code that I mentioned, is up on my thread about processing interrupts on the BAP:
lynxmotion.net/viewtopic.php?t=3496

Look at the post from June 8th.

Kurt

[km6vv]

Hi Kurt,

Found it!

Thanks. It should make a good little test fixture using a BB2. I was going to code it in C on a PC, using the parallel port, but why? Nice little job for a BB2.

Alan KM6VV
EncoderKurt.BAS

@kurte

Hi Alan,

The encoder code that I mentioned, is up on my thread about processing interrupts on the BAP:
lynxmotion.net/viewtopic.php?t=3496

Look at the post from June 8th.

Kurt

[km6vv]

Hi Xan,

Some PIX as promised!

http://www.marconettengineering.com/New4DOF_Leg2.jpg
New 4DOF leg

http://www.marconettengineering.com/Old4DOF_Leg4.jpg
First 4DOF leg

You’ll notice that the “roll” servo and it’s universal and ‘C’ brackets have basically been turned upside down.

The new design does give me more range in the Hip V servo, but at the cost of making the SHCS of the LPA not reachable for adjustment without removing the roll servo.

http://www.marconettengineering.com/LittleCatIK.jpg
IK for LittleCat 4DOF legs

the IK for the 4DOF legs (excluding roll axis) might actually be simpler, as the legs can stand straight up, with no coxaH-coxaV offset!

Alan KM6VV

@Xan

Hi Alan,

@KM6VV

I did a redesign on my 4DOF leg; I can flip the C bracket and roll servo with it’s universal bracket basically upside down. The hip V servo range is increased, however I loose access to the SHCS that sets the tension on the LPA joint. Not sure if I will change to the new design or not.

I’m not really sure how the setup is changed. A few pics will defiantly clear that up. Hint hint

Xan

[tom_chang79]

Very nice Alan! Is this going to be the next HPI G-Dog Killer?

With all you guys working on quads, I’m starting to think about it more and more…

[km6vv]

Thanks for the kind words!

Good. I’l like to see more people working on 'quads! Join us! I have a chassis plan that will allow building in several ways.

This is for “Little Cat”, I don’t think she should be taking on Big Dog anytime soon!

@tom_chang79

Very nice Alan! Is this going to be the next HPI G-Dog Killer?

With all you guys working on quads, I’m starting to think about it more and more…

[tom_chang79]

No, no, not the big dog. The HPI G Dog:

youtube.com/watch?v=4u7aIIUDSQk

This guy is a cute little quad that’s like a companion for their G-Robot (it’s distributed by Futaba for us North Americanos)…

If it didn’t have a “Dog” in its name, I swear I would’ve thought it was “Ravage” from Transformers. The similarity is uncanny:

http://www.comicstatues.com/images/ravagemain.jpg

[km6vv]

Oh! I haven’t seen it before. Interesting robot! And very agile. Of course, it looks like it is tethered.

Still, I’d be happy with even part of its routines!

The stride looks very short, and I see a diagonal gait.

One could learn a lot from that 'bot!

Thanks for the URL!

Alan KM6VVV

@tom_chang79

No, no, not the big dog. The HPI G Dog:

youtube.com/watch?v=4u7aIIUDSQk

This guy is a cute little quad that’s like a companion for their G-Robot (it’s distributed by Futaba for us North Americanos)…

If it didn’t have a “Dog” in its name, I swear I would’ve thought it was “Ravage” from Transformers. The similarity is uncanny: