Has nothing to do with that. If the SSC-32 resets, the program offsets are flushed, but the bot still walks, just not as well. The better way is to use the registers.
We just received an update for LynxTerm. It fixed a few problems due to working around old firmware bugs that have been fixed. LynxTerm does a lot of bidi coms to determine how to best handle offsets. For the registers form it’s straight up, you adjust the value for the offset with a slider, and then you write it to the registers. The only other place LynxTerm uses offsets is in the 12 servo sequencer set up. It now looks to see if the SSC-32 has the 168 chip, then it uses registers instead of generating the code line for your basic program. We should have it up soon.
Just a reply to whether it will walk with the 4.5 tubes. Yes. It will walk and looks quite cool, but a bit wobbly so i had to go steady. An upgrade of all servos would be advised. Lol.
I might drop a short clip of it walking with them in my next video. Hopefully with FSRs.
A new LynxTerm will be nice. I need to refresh my memory on what it can do anyway.
I just realized that as I never built a Phoenix, just the CH3-R, and that was basically my own build, as I didn’t build it “stock”.
Reading builds 131/139 should be useful.
I might try programming the registers in the BB2 program instead of the po command. Or not. Depends on how easy it is to “manage” them with LynxTerm or SEQ. Any updates coming for SEQ?
The phoenix tutorial is IMO the best one to follow. With xans code being a front runner and with its ability to be rewritten quite easily id go with it. The phoenix tutorial is as easy to follow as any other. Take your time looking over it and then you will have no prob. Let me know if you need direction. I built my ID3 Hex using the phoenix format. Works like a charm.
I’m on my way. Rather then re-learning or finding out all the nuances of the “build” for my self (like what alignment of the legs is required for a particular version of the software) this time I agree that it would be prudent for me to follow a published build. That’s actually nice!
I will have to make changes to account for the physical differences in size and leg distributions for my 'bot. Can’t be that different.
I was commenting that in the first “pose” of my 'quad, the feet and tibias of the two rear legs were pointed funny.
After checking the wiring for the nth time, I noticed the labels that I had carefully taped to two of the legs to insure their correct installation. Seems I wasn’t careful enough, and in the process of getting the battery packs and switches sorted out, I got the legs rotated 'round wrong.
I removed all four legs, and re-installed them, and now the first pose looks more reasonable! Of course I’ll have to re-do the leg-zeroing!
I’ve just finished putting the corrections in again.
First “posture” has foot on P0 sticking out at 90 deg. Switched to P8, same problem. About as far as I got.
Alan KM6VV
9/8/10 Edit: It’s looking more and more like this brand new servo must be bad. Only other thing I can figure. And another leg has got a weird swing to it. Just not enough time to work on stuff.
A “swap” of the P0 coxa with an adjacent coxa shows that the servo will move. I did note quite a bit of voltage drop to the servo connector (extension cable). I run with VS low when testing new servo setups. Also long light wire run didn’t help. Interesting that only this one servo dropped out. I’ll crank up the voltage a little, and get a heaver run of wire back to the bench supply.
I’m still seeing something funny on another leg, I’ll investigate that next. It just takes time…
What battery are you using? I have a nice clamp from the “Creepy Crawler” days that holds the LM 6V 1600 mAh NIMH battery. Or maybe two. I also allowed room under the SSC-32 for a pair of LiPo batteries, which would then require a BEC to take the voltage down from 14+ to 6V. I was going to wait on that.
lipo’s would be a nice touch. the battery i have is… well im using too.
first i have a large 6V 3300 mAh NIMH battery for testing on the desk. that battery is that big blue one you see in the video.
second i have now attached a 6V 2600 mAh NIMH battery to the underside of the chassis. works very well.
Strange. well i just moved the pin to another one and left it there. i just thought it was my SSC. but from your findings it seems to be code related. if i get time i will look into it.
this is down to zenta. im not sure as to why/what these numbers are.
after adding a few things to my code (notes) line 67 is not the same as yours.
anyway
for instance:
650 + 356
65.0 + 35.6
=100.6º
good luck with the cold, happy to help out with those funny leg pos. look forward to vid. will speak a thousand words!
I’d like to identify all of the “magic numbers”, what they’re for, and how they’re created.
There are still a few magic numbers in the old “pod” CH3 code that I’d like to get figured out.
Actually that brings up another question. Coxa Angle. I know the T-Hex has 45 degree brackets for the fore/aft legs, but I doubt (I’ve got it calculated somewhere) that that is the angle to the center of the T-Hex. I would think that would matter!
In fact, we can get the RR coxa angle by calculation atan(cRROffsetX/cRROffsetZ).
The additional value to 650
cLFFemurOffset con 650+183 ;Front Left leg Hip Vertical
is the actual servo offset for calibration. I didn’t use the register offset in the SSC32 since they are limited to about +/- 100 or so.
thanks for clearing that one Kåre.
Alan, i followed the same set up as you would for the phoenix hexapod. this included using the lynxterm software.
although saying that i must admit that when i then hooked up and programmed the Atom my offsets were … off-set!
just a few simple adjustments to the servo horns sorted that but Zenta 'are you saying that i can program the offsets strait from the atom.
EG:
so if:
650+183
650 = servo center
183 = offset value
i could simply change (trial and error) my offset values by changing the 183.
also what would the value of 183 be as a degree?
I’m wondering if we shouldn’t zero-out the offsets to the 650’s, at least for the ones we can accommodate with the ± 100 Lynxterm setup. If we need an extra 100, then we can add it to the 650. Although I don’t yet see how we’d be able to “see” the extra 100 offset while making the Lynxterm offset.
Kåre’s “offsets” are not the same as the offsets in the SSC-32’s registers or even the earlier software version. Our use of the word offset, means a very specific thing. It is used to bring the output shaft into a known aligned state. After this offset (less than 15°) is installed into the registers, sending 1500uS to all aligned servos takes them to the same place.
I believe Kåres use of the word offset is completely different. He’s using it as a means to solve math or position issues with the program. Admittedly I do not have a solid grasp of Kåres math, but I think his offset has nothing to do with aligning the servos to a defined orientation.
Maybe it’s the name that is confusing? Maybe we should have called it an “offset eliminator”, or a “calibration offset.” The whole naming concept is backwards. Calling something an offset, when it’s goal is to remove an offset that is not wanted.
