I normally do it in that order too. But Zenta did the proof of concept for us didn’t he? Have you seen his videos?
Ok you got me on that one. I should have said the femur is longer on Phoenix, which is the more important one for strength. The tibia is always used to put the foot under the knee. So a longer tibia doesn’t effect the strength near as much as the femur;
CH3 - femur = 2.25" tibia = 5.5"
Phoenix - femur = 3.0" tibia = 4.25"
If the legs are at other then at the 30, 90, 150, 210, 270 and 330 degree points, then a simple table can be used to pick up the angles desired, rather then the (Index * 43 + 21) calculations seen in these two equations that I asked about before:
A table lookup is a simple “fix”. 43 is 60 degrees, 21 is 30 degrees. I’d still like to know what the / 300 is for!
Other then that, and the previously mentioned leg length differences, I don’t see why an existing program wouldn’t work. The servos appear to be in the same orientations; even Left vs. right side is the same as before. Of course, I’ve YET to get my friend’s “Goofy Legged” 'Bot to walk correctly!
One other small concern, calculations involving the femur and tibia lengths would have to be watched, even for the CH3-R with the 141 mm Tibia (longer then a byte). BASIC tends to “promote” variables sufficiently to accommodate this, it seems.
Slightly off this thread; but what is the “autonomous” variation to the BASIC Atom program doing? I can see no XSpeed or YSpeed (and other) “joystick” inputs to tell the 'Bot to go!
Oh that’s true; the Phoenix has already “flown”! Your engineering is done! No worries!
hehe funny, I was thinking the same about the femur part. Maybe the servo horn also can be anodized the same color as the rest of the aluminium parts?
Another hobby of mine is photography and I must say you have a great setup for taking “pro” photos of your bots! I liked the comparison of Phoenix and CH3-R. Phoenix is definitely a she with slim legs and a cute body… ehm… And CH3-R looks very muscular, definitely a male haha No wonder why my wife is a bit jealous.
About the videos you linked. Here is a video of the complete project, running over 810 steps from Visual Sequencer! Almost 3 minutes of walking and posing. youtube.com/watch?v=SdR0q-suw0c
I vote Phoenix to be the most insect like hexapod I have seen to date! She reminds me of a beetle. I think this is a good thing. You’ve done an awesome job on this design!
Can Phoenix climb over that box?
It will be interesting to see what James can do with Phoenix when he gets his hands on a prototype…
Why doesn’t she like the box? I don’t get it. She seems upset or angry with the box. I like the box… Does anyone else here like that box? I think its a fairly nice box… Would be great to see her climb over it. Possibly full body climb, and then only half of her body climbing on other half on the floor following
Thing? THING?! How dare you refer to a female as an object!
Jim - I like the idea of red. Maybe the design could incorporate a flame motif w/o sacrificing strength? Man, just when I paid off my credit card, too.
Hi,
I have not studied the powerpod much yet, but as far as I can see there is a little problem regarding of how I calibrated the HipH (coxa) servo on my Phoenix. They are calibrated the same way you calibrate a inline body, meaning that every coxa servo are set to 0 deg when the legs are parallell to the X-axis. So far so good… But the problem comes to the offset. I assume the offset value in powerpod is the same as the offset function (PO) in SSC32, and the offset are limited to +/- 100…
The rear and front coxa servos are not calibrated with the 0 deg close to pos. 1500, that is not a problem when using Visual Sequencer because you can define the zero deg point at any position. But with a offset value of maybe 400 there is a little problem… Does the SSC32 ver2. allow greater offset value than +/-100?
In my Excel program all coxa servos are defined with the 0 deg position parallell to the X-axis too. So if I wanted to make sequences for the CH3-R with the Excel program I would have to recalculate the coxa servos probably by +/- 60 deg.
But would it be a problem at all to have a greater offset value as long as you are aware of it and just do some recalculations in the basic atom code?
I’d be interested in hearing more about your gait development. As I understand it, you are writing the sequences with SEQ. I’d be interested in a way to graph the leg motions, with the thought towards designing a gait engine to run it (them). I’d also like to work out a way to have additional (state) code to also handle the “postures” (is that reasonable?).
But first to attempt to address your questions. I assume you’re talking about the BASIC Atom programs generated by PowerPod, rather then PowerPod it’s self!
Would you say that Phoenix’s legs are EQ spaced? I wasn’t able to ascertain that from the pix. It’s OK if they’re not, my octapod design has legs that are not equally spaced, as I’ll address later in this response.
There is a calibration that PowerPod does, and (I assume) stores in the SSC-32 (EEPROM) itself. This would be the “slight” offsets of the joints from the “neutral” (1500) position. Adjustments that can’t easily be made by “tweaking” the mechanicals. The “major” angular settings, what I think you are calling “calibrations” are set by either of two equations in code. The “inline” basically calculates for either left or right hand legs, and the “Round” code does a “rotation” for each vector (leg) around the body. A lookup table could be used instead if the angles of the legs can’t be easily generated by an algorithm. Does this make sense?
I suspect these angles would be at 30 (right rear), 90 (right middle) and 150 (right front) on one side of Phoenix, much like other -R (CH3-R) Lynxmotion robots (You know, I’m sure, that the Phoenix was a BIRD that emerged from the ashes?). The -R robots use 1500 as the center of their travel. Does that work for you? That’s why I don’t see much of a problem in using the existing code. Are your leg segment lengths much different? It sounds like it’ a little smaller then the CH3-R.
Yes, I believe you’d have to revolve the “requested move” (range and heading) of the 'Bot by the angle of the leg, as I’ve suggested above.
If we ignore the offset as a minor correction for the mechanical setup, and concede that the Heading/Range component gets revolved (as described), then it could be worked in. But that is handled by the gait engine (code). I’m wondering if you’re not describing SEQUENCES, which aren’t necessarily simple cyclic progressions achievable by a gait generator.
The gait generator in the current hexapod robots (as far as I’m aware) all work on a gait generation (engine) that only produces a basic tripod gait. I’m told that the new PowerPod program will have the ability to generate a number of gaits. That will be interesting to see.
So what types of sequences would you be wanting to “work into” the CH3-R? As sequences are basically servo positions and times, and if the angles of the legs agree, then they could probably be put in as sets of “canned” (just sets of servo angles) postures. If you’re talking about the nice ripple gaits that you’ve developed, then I think it takes some major rework of the gait engine.
You mentioned the spread sheets, I can’t remember, are they available? As you’ve developed the gaits with a spread sheet, it suggests to me that you used some sort of cyclic generator algorithm at the core of your spread sheet. I’m no spread sheet expert! Would that be accurate? That algorithm, I think, is the information needed to develop an appropriate gait generator. Perhaps you’re already working with Lynxmotion on that. I’m sure many on this list are interested in these!
I don’t know if you’ve been asked before; are you a programmer? I’d like to discuss this more if you’re interested! Gaits, Subsumption, Balance Gesture, and Inverse Kinematics are the reason I’m building a hexapod (or possibly an Octapod!).
It should be a HOT seller if it is available before Christmas. I think Phoenix has to be the most unique hexapod since hexapods were first built. The form is very different - not quite round, and yet not quite inline either. I love the range of motion Phoenix has.
Hi Alan,
I’m not exactly “writting” the sequences with SEQ at all. I generate all gaits and poses with the Phoenix Excel Program (PEP) and then import the sequences from PEP to SEQ via a .csv file. PEP is just a MS Excel spreadsheet with alot of VB code in the background. Jim has allready got it, but I have some work left doing some translations and making some documentations (how to…). PEP gives you a graph view of the body with legs seen from above and one leg seen from the side (you can select another leg by pressing the IK button). It’s easier to understand it when you see it, I hope. The code is a bit messy, I’m not a pro. programmer but have some exp with basic and C.
I was talking about the offset function (PO) in SSC32.
I’m not exactly sure what you mean by EQ spaced. Do you mean 30, 90, 150 deg coxa positions relative to the centre of body? If so, Phoenix’s legs are not EQ spaced, and they have not the same distance to the centre of body. In the PEP you can define any body shape and size you want, round, inline, oval or even asymetric body, because the body is defined by coordinates of each coxa (HipH) servo. You can also define your leg segment lengths, HipH-HipV, femur and tibia.
My bird (Phoenix) emerged from the ashes due to my first attempt of making a hexapod robot. The femur and tibia servo uses 1500 as the center of travel, but not the coxa servos for the front and rear legs. The leg segment are a bit different but that should not matter if you are able to define the lengths in the program.
PEP is not available yet but I think Lynxmotion will post it in their project section (at Lynxmotion.com), Jim said Beth was working with that.
Yes, there is a simple algorithm for making gait.
As mentioned above, I’m not a proffesional programmer, just a simple amateur.
But I’m very interested in making a Balance Gesture (each leg is a imaginary spring!), I have not studied that part yet so I’m not sure if I’m able to discuss it. haha
Ah, yes, you use the spread sheet to generate the sequences, then take them to SEQ. I sorta realized that after remembering the spread sheets. You must be quite good at spread sheets then! I am not. Documentation is always important!
I like the graph view idea! Who knew Excel could do such things! I’ve been toying with a program to take some form of input, like the SSC32 commands from either SEQ or the BASIC Atom program, and show the legs in 3D. I’d want to be able to step through each set of leg positions. Or possibly draw a graph of leg movements (three joints). I haven’t worked out the details yet.
EQ would be “equal”, probably a bad choice to abbreviate. OK, Phoenix’s legs are not equally spaced then. A table lookup for the leg positions should then suffice in Atom (any idea with the /300 is for?). Some of the scaling could also be calculated into the table.
The LegTable would be a simple array of 6 integers.
Humm, you wouldn’t want to make them 1500? I still think we’re alright, what would probably happen is the scaling from the desired calculated angle to the range of the servo would take care of this:
HipH_Pulse(Index) = (((HipH_PulseMax - HipH_PulseMin) * (HipH_Angle - HipH_AngleMin) / (HipH_AngleMax - HipH_AngleMin) + HipH_PulseMin) max HipH_PulseMax) min HipH_PulseMin
If I understand the “mapping” correctly, what’s important is the “center” of the range of calculated angles matches up with the center you’ve choosen for the HipH (coxa) servo, which is determined by the limits you’ve chosen for servo.
Yeah, I know what you mean; but they still pay me to write software! I certainly don’t know anything about BG, and I’ve just come to terms on IK! Bought the book Mike of micromagicsystems recommended, that’s a LOT to absorb! ;>)
If the gait algorithm is in VB code added to Excel, then it should speed Lynxmotion’s efforts to implement them.
I as well as I’m sure many others look forward to seeing PEP. It sounds like a very good tool for those wishing to study gaits! There are a few I want to work on (OK several).
I’ve just heard of the Balance Gesture, and am looking for a paper on it. I’m told that our legs really should have some sort of “spring” to them; I wonder how this is achieved? The micromagicsystems website is reported to have a PDF on both IK and BG, 'tho I haven’t found them yet!
Yeah, quite a book. Probably could be used as a grad course in ME.
Springs. I still haven’t found that PDF on BG.
Are these “microservos” something other then the Hitech type standard servos that LM is selling? Maybe you’re going for a miniature octapod? What servos do you have in mind?
Any ideas on gaits for an octapod? But I’m getting ahead of myself. First, get the CH3-R up and on it’s feet!
Have you seen his videos?
I’ll be happy to write some code too!
…
Very nice video!
Does the SSC32 ver2. allow greater offset value than +/-100?
Do you mean 30, 90, 150 deg coxa positions relative to the centre of body? If so, Phoenix’s legs are not EQ spaced, and they have not the same distance to the centre of body. In the PEP you can define any body shape and size you want, round, inline, oval or even asymetric body, because the body is defined by coordinates of each coxa (HipH) servo. You can also define your leg segment lengths, HipH-HipV, femur and tibia.