Tom,
Do you ever make the HBRobotics meetings?
Alan KM6VV
Central coast, CA
HBRobotic meetings? Is that a robotics club? Do you have a www?
well, I’ve “injected” some initial values right before the “;H3” tag like so:
Height = 0 ; Default preset
LegUpShift = 35
GaitSpeed = 4
HeightAdjust = 0
LegUpShift = (LegUpShift max LegUpShiftMax) min LegUpShiftMin
GaitKind = LegUpShift > 45
GaitSpeedTmp = GaitSpeed max 20
MovesDelay = 8
;<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Xspeed = 128
Yspeed = 0
Xspeed = Xspeed*4/5
Yspeed = Yspeed*3/5
Steering = 1
FlipFlap = 1
Roll = 0
;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
;H3
if Steering or (Height <> LastHeight) or YSpeed or XSpeed or LockLegs then
.
.
.The feets are starting to move but it’s still not moving in any direction. It seems like it’s just staying put and just alternating the tripod.
The femur and the tibia servos are moving but the hip servos aren’t moving so obviously there is no movements at all in the Xpos and Zpos direction.
What am I doing wrong here in the assumption of these variable names?
I’m assuming that Xspeed and Yspeed are the speeds you want the hexapod’s body to move (not the legs since the legs uses X and Z):
Xspeed is the speed in which you want the Hexapod to move in the X direction
Yspeed is the speed in which you want the Hexapod to move in the Y direction
Steering is the which the “front” of the hexapod should face (?)
FlipFlap is just an alternating bit to alternate between the two tripods during an up or down motion
Roll is the pitch of the hexapod’s body (?)
Yes, for silicon valley.
Pitch is pitch and Roll is roll; you have two different parms.
Steering is like rotating the body to make a turn.
Looks like it should have worked! Make sure you are in a “move” mode, not shut down? Possibly MovesDelay is not getting set negative (as I recall). Are you running the “autonomous” version? It might have other things missing?
Alan KM6VV
I’m running Kurte’s modified code since I have an Atom Pro 28. I’ll compare some blocks against Powerpod’s generated code with “Autonomous” selected to see what the difference is between Kurte’s and Powerpod’s code. I’ve looked at “Autonomous” code before but couldn’t really discern what the difference was between that and the “PS2” controlled one.
Well, I wouldn’t mind joining you guys regarding the club but Silicon Valley is a little out of reach for me. I did go to school in Santa Cruz this was back in 2002. After I graduated, I’m back in Southern California (the greater Los Angeles area). Who is this Bob Krause fellow? I know a guy named Bob Krause, probably a different fella but I’ll go speak to him tomorrow to see if this is the same Bob that I know…
I’ve frankensteined so much of Kurte’s code, I’m planning to start over on the trimming. I am going to develop my own IK code eventually (note the word eventually 
) but at this point, I just want to see it walk.
Perhaps when I get more handle on Laurent’s code, I will adopt it, since it’s quite elegant as shown in many of the videos online, and also, why reinvent the wheel? Once there is a wheel, time to build a car with it, metaphorically speaking…
Coding your own IK code can have advantages as it should trim down the variable counts to get rid of all the extraneous ones and also have more control of the naming conventions rather then doing a “Find/Replace” command. Not to mention the valuable knowledge you gain in the process!
Thanks for your help so far everyone, let’s continue to support each other regarding this wonderful robot!
I compared (Beyond Compare) Kurte’s modified code with a CH3 round version that I had generated from powerpod. Kurte has added conditional compile statements to allow round and in-line builds, much as I have to my C code. I also see an “SSC32 wait” function. and the serout/serin pins are defined differently. That’s about all. So unless I’ve missed something in my cursory examination, the program should work about the same.
Watch the MovesDelay parameter, it needs to be “kicked off” to all the IK calculations to proceed and the legs to move. It gets set to run through a set of states. I found it a key parameter.
Basically the autonomous code has the joystick stripped out, from what I remember.
Yeah, that’s a long drive! Don’t know Bob.
That could change things. Better to start with something that works, then go from there. I save “ZIP” builds of my projects with all the required files. That way, if I discover something has stopped working, I can go back and figure out what got changed. Save milestones! But you probably know that!
I do make extensive use of name searches. And print statements! The SSC32 is fairly tolerant of non-command messages, you can print debug strings out to the same serial port, and “eavesdrop” on the communications with a PC running a terminal emulator program.
Alan KM6VV
I finally go the code working in autonomous mode. There are so many superfluous code and my CH3-R’s legs doesn’t start “centered” so I still have some trimming and refining to do. I need to pre-define the off-set values from my calibration file and also need to define some variable in order to control some of the speed. The gaitspeed does control the gaiting speed, however, when the pulses are still sent out, the ssc-32 is still commanded the fixed value of “T180” which is something that I feel can be a variable…
Thanks for all your help guys. If anyone is interested in some baseline code, which needs ALOT of cleanup, please let me know. I’ll post it on Kurte’s thread.
Glad to hear it!
I think I’ve got some work to do in that area as well, although my legs are adjusted quite closely mechanically.
The delay is apparently a problem on some of the Atom BASIC chips. Very coarse setting only possible. Yes, that’s what I am intending to do as well. Might even eliminate some IK calculations. Kurte’s code to see if the SSC32 is done is a good idea. With my access to interrupts, I can quickly check to see if a delay is timed out, and get other (background) tasks done until the SSC32 is ready for another task (NO BLOCKING).
Alan KM6VV
Question:
In the powerpod code:
DCoord = SQR(XSpeed * XSpeed + YSpeed * YSpeed) & 0x7fffWhy is the tangent of the triangle formed by xpeed and yspeed ANDed with the mask, 7fff. I would think it doesn’t matter that ANDing it with the binary mask:
0111 1111 1111 1111 (7FFFh) - 16 bits, 2 Bytes
would matter since it’s ultimately being stored into the variable of the type “Byte” ?
DCoord var ByteWhat would be the implication of ANDing a 16-bit number (the result of the square root) with a 16-bit mask and storing it in a 8-bit data type? Does the upper-byte get stored? If the upper byte is stored with the lower byte truncated, ANDing it with that mask would strip off the MSB of the tangent calculation, therefore probably to scale it down for a “ridiculous” length (like a 20-foot long tangent for a hexapod with leg length of less then a foot )
Funny, that code looks familiar, but the files I use for reference didn’t have that & 0x7FFF.
DCoord is indeed a byte, so it has no effect. And you wouldn’t want it there either.
Masking and storing in a 16 bit variable would but it in the LSD end. You’d have to do a shift “>>” to move the bits down, or address the individual “byte” name of the register, like AH and AL in 8080 code.
Alan KM6VV
Perhaps I will try to do a debug print to the screen to see what storing 16 bit numbers in a 8 bit.
You’ll simply do an ‘AND’ with 0xFF, and loose information.
Alan KM6VV
There was (not sure if is) a bug with the Atom Pro that sometimes the square root function would return a negative value and this fixed the problem. There was a thread on this awhile ago. It probaby had to do with maybe the differences of how the two processors handled sign extension. As for what happens when you move a 2 byte value into a 1 byte value is you lose information. However with the Joystick, the values for XSpeed and YSpeed I believe are in the range -127 to +127. So in this calculation the result should fix in a byte.
Kurt
Thanks for the info Kurte!
Sure seems like a lot of “fixes” in BASIC. Any Idea what the 300 parameter in:
XPos2(Index) = -(DCoord * COS(DAngle + (Index * 43 + 21)) / 300)is for? I’ve puzzled over that one for a LONG time. About all I could figure out was simple scaling. ;>)
Alan KM6VV
Sorry, I don’t remember what the 300 was about. I did not go into much details about some of the calculations, as long as the Atom and Pro gave the same results.
Some of differences may be bugs and others are just differences in how the processors handle edge conditions. For example: there was a case in the code that calculated the distance and then used the distance to divide into something. Well suppose the distance is 0, the two processors handled this case differently.
Kurt
Ok, I’m starting to code my own IK code for my Phoenix. I did my 3-space trigonometry and solved for the three critical angles given:
- (x,y,z)
- H - HipH to HipH length, F - Febur Length, T - Tibia Length
It’s no surprise that my closed-form equation to solve for the three critical angles involves Arc Cosine and Arc Sine. But the only reference to these functions in the Atom Pro manual is FACOS and FASIN which forces me to use float as my data type (yikes! good bye overhead processing power to do other things!)
I want to AVOID using the FACOS and FASIN since it involves my datatypes to be float, so I’m trying to understand Powerpod’s (Laurent’s) usage of the Bytetable.
I understand the meaning behind using a look-up table versus doing FACOS and FASIN (memory versus processing load), but what I don’t understand is the scaling:
;ACos
acosTbl bytetable 64,64,63,63,63,62,62,62,61,61,61,60,60,60,59,59,|
59,59,58,58,58,57,57,57,56,56,56,55,55,55,54,54,|
54,53,53,53,52,52,52,51,51,51,50,50,50,49,49,49,|
48,48,48,47,47,46,46,46,45,45,45,44,44,44,43,43,|
42,42,42,41,41,41,40,40,39,39,39,38,38,37,37,37,|
36,36,35,35,35,34,34,33,33,32,32,31,31,31,30,30,|
29,29,28,28,27,27,26,25,25,24,24,23,23,22,21,21,|
20,19,19,18,17,16,15,15,14,13,11,10,09,07,05,00How does the element 0, which is 64 correspond to an angle of 90-degrees? I tried to understand it in terms of PWM and Radians, but none of it pans out. Can someone please explain to me how the value 64 equals 90 degrees?
You’ll have to look up SIN and all that in the Atom BASIC manual. They work with integers. +127, -128 or so. You don’t need floats in BASIC, use the lookup table.
Alan KM6VV
ahh, I see, so I guess you re-scale these values, in this case from 0 to 64 to PWM with the 0.09 degree/unit (as in the SSC-32) ?
Tom,
Did you ever get the the code to work in autonomous mode correctly?
Thanks,
Duane
No, one thing I’m terrible at is reading and auditing other people’s codes… So I ended up scrapping the modified Powerpod-generated code and just coded an IK-code from scratch… Right now, it only has the YAW function incorporated, which is enough to do some walking and crab walking and rotating about the Z-axis. You can see a demo of it here:
I’m still working on the roll and pitch function, so it’s an on-going thing…
I believe kurte posted a Atom Pro 28 compatible modified Powerpod code a while ago. I believe the latest Powerpod program works with Atom Pro, but not really sure.
Yes the current version of PowerPod does create Atom Pro code. 8)