Thanks for sharing Xan!
This is awesome progress! Did you try the TA part combined with other gait too? Cool to see you V2.0 in action 8)
Thanks for the positive reactions guys!
I’ve tried to upload a demonstration video about the new features in 2.0. The video was cut off because off maintenance at YouTube. :s I’ll try to Upload it again when I get home today.
Xan
Very cool Xan! 
The video looks a tad strange though… Did you increase the speed or something?
Nope, the video is 1x speed! It is a bit wobbly once the balance mode is on. One of the things I need to figure out.
I notice the body shifts a little bit while taking steps. Are all six legs sensing the ground? Would it be possible to turn sensing on or off depending on which leg is in the air? toggling the input would allow you to only read the one leg that is in the air. Once a leg makes contact, you can switch reading the input on the next lifted leg and so on…
It looks like it might be reacting to input from all six legs? I don’t know, perhaps I can spark some new ideas.
Ah, ok. I was wondering what that was. I’ll let you get to the figuring out part. 
Wait, first, lets watch it again in slow motion. There was a lot going on in that video and we don’t want to miss anything! … 
Been staring at this thing for a while now. It looks like the leg positions are continuously updated even when the single leg is being lowered. Why can’t you leave them all as-is while you lower one leg, then adjust them all when the lowering leg makes contact? This has to be faster.
It’s easy for me to comment, because making a comment does not require any knowledge at all. lol
If you make some assumptions…
Robot body will try to remain flat.
Object to be walked over is not taller than the lifted leg minus some (working value)
Object to be walked over will also be flat.
Then a simpler mode could prove to be faster but still work reliably. I know you really want it to not have these restrictions.
Thats exactly what I was saying a few post up there ------^
Only read the leg that is off the ground and leave the rest of the legs fixed, but you have a good idea about doing a quick query of all six legs before taking the next step. But like you said, I’m just throwing stuff across the table blindfolded.
Hi again Xan,
As I mentioned it looks great. My guess is that you are doing this by breaking up the move into really really small moves and then testing the input to see if you hit before you try moving the next little bit. Out of curiosity have you tried the other approach, which was to try bigger moves and continusously checking to see if you get contact and then abort the move and then ask the SSC-32 where it thinks it is. If so how was the speed and how far off did it appear to be. My guess is that you could make a reasonably good guesses. That is if you told the leg to move from point A to Point B in time X and you hit something at time Y, you may be able to reasonably compute where the leg is at the point in time even without asking the SSC-32. Just a thought.
Maybe I should have ordered some more FSRs with my current order …
Kurt
The body position and rotation is continuously updated corresponding to the positions of all legs. Not corresponding to the switches on the legs. The updating is caused by the balance calculations. The balance calculations are needed to push itself up on the book. If it is turned on the ground clearance is to low once one leg is on the book and the leg can’t move at all. This is caused by the short femur.
It is possible to walk over an obstacle with balance mode turned off. This will barly increase the speed since the balance calculations only take up a few ms. The object can only be less then half the book.
Something to get our minds around:
Without balance mode:
Let’s say the hex is on the ground and the body clearance is 10 cm.
The hex walks on an object of 4 cm. The legs will stop early so the ground clearance is only 6cm. If it walks on a new object of 4cm it will have 2 cm of ground clearance left.
Or the other way around is even worse. Say I’ve got a down slope. It will walk for a bit and then automatically overstretches the legs and game over.
With the balance calculations the body is placed relatively to the legs. So if the legs move down, the body moves down. That’s why the balance mode is crucial. I think the body is shaky since the precision of the balance mode is a bit to low. I think adding an additional digit will solve this.
Xan
Yeah this was my first approach. The only down site to this is that I need to stop all servos one by one. There is no stop all command. This resulted in some overshoot between stopping one servo or the other. And like you said I need to know exactly where the legs are. So after stopping I need to query the angles and do FK to get the positions. This isn’t hard to do but BAP <-> SSC communication speed is leaking on this part. Having a single board with a onboard SSC emulator will solve a lot of tease problems.
At this moment speed isn’t my main goal. There still is some work to do in returning the legs back to there original position once it’s over the object. And see how to solve the wobbly part.
I’ll figure it out. If it was a easy job there would be much more hexapods with TA on the web. 
Xan
PS: Don’t go with FSR’s they won’t work for this setup. (Been there, done that )
The hex Xan’s using has switches in the tibia to know when it’s touching the ground. It’s just a prototype for now though. If he makes great progress, then I must get these legs made into a kit real quick like.
Leg switch thread…
viewtopic.php?f=8&t=4579
Yep, but it is fun being an armchair programmer
But what I was thinking was not to query the SSC-32 at all, but for the software on the BAP to guestimate where everything is. That is for all 3 servos of each leg you know that you were moving from angle X to Angle Y over a certain amount of time, so if you hit something at some portion of that time. If you can assume reasonably linear movement during that time. For example if you hit something at half the specified time then the servo is half way between X and Y. Assuming you can get a reasonably close guess at this point then you simply need to do the FK. My guess is that if you can compute this fast enough, then maybe it would be easier to simply tell the servos to go the computed spot instead of telling them to stop… But then again I could be completely wrong!
Now back to the Hex on Xbee, have the code integrated, but sticks and sliders not doing what I expected so now to check them out again.
Kurt
Yep, now I remember! 
Kurt
Sounds like a good idea to increase the precision, I’m guessing you need to do some small changes in both the BodyIK and BalCalcOneLeg sub. If I’m correct the precision used for rotation is 1 deg, 0,1 deg would be much better.
Oh… I would love to prove you wrong there. 
…one day…
Ok guys,
It is been a while for me since I had some serious input over here at the forum. Well the time is here that I’ve finished most of the stuff around the house and I’m fully in to robotics again. So it’s time to open up the topic from where I left off.
For the last few months I’ve been studying kinematics because I noticed that I kept running in to the limitations of my knowledge of math. In the last few months I solved most of the kinematic problems for both FK and IK. Currently I’ve got most of the math worked out and simulated on my pc.
Today I started to run some tests on the BAP. I will posts my progress in this topic.
As descussed before, the idea of my TA approuch is like this.
- drive a leg down.
- Stop all servos using the ssc “stop” command, once the leg hits the ground.
- Query all servo positions from the ssc
- Do Leg FK
- Do Inverse Body Translation
- Go on to the next step of the gait
Step 2 is pretty simple to implement. Once the leg goes down, wait for it to hit the sensor. Be aware, there is no fail safe in here yet. So if there is no ground. The leg will get fully streched. But this will be something to figure out when the rest is working.
[code]WaitForTouchdown:
Lookup LegIndex, !IN15, !IN14, !IN13, !IN12, !IN8, !IN7], TA_GroundContact
IF TA_GroundContact THEN
serout cSSC_OUT, cSSC_BAUD, "STOP", 13][/code]
Today I tested and finished step 3. This is the code to Query the servo positions from the SSC and reverse them in to the servo angles. The SSC version I’m working with returns the position with less accuraty since it only returns 3 digits for the PWM signal so #0P1500 returns in to 150. Here is the sub.
[code];--------------------------------------------------------------------
;[QUERY SERVO POSITION] Queries the current position of the servos
TA_CoxaPWM var word ;SSC Read value for coxa PWM
TA_FemurPWM var word ;SSC Read value for femur PWM
TA_TibiaPWM var word ;SSC Read value for tibia PWM
QueryServoPositions:
for LegIndex = 0 to 5
serout cSSC_OUT, cSSC_BAUD, “QP”, dec cCoxaPin(LegIndex), 13]
serin cSSC_IN, cSSC_BAUD, [TA_CoxaPWM]
serout cSSC_OUT, cSSC_BAUD, “QP”, dec cFemurPin(LegIndex), 13]
serin cSSC_IN, cSSC_BAUD, [TA_FemurPWM]
serout cSSC_OUT, cSSC_BAUD, “QP”, dec cTibiaPin(LegIndex), 13]
serin cSSC_IN, cSSC_BAUD, [TA_TibiaPWM]
;Translate PWM to Angle
if LegIndex<=2 then
CoxaAngle1(LegIndex) = -((TA_CoxaPWM *10-650)*1059/1000-900) ; Queried PWM data is devided by 10
FemurAngle1(LegIndex) = -((TA_FemurPWM*10-650)*1059/1000-900)
TibiaAngle1(LegIndex) = -((TA_TibiaPWM*10-650)*1059/1000-900)
else
CoxaAngle1(LegIndex) = (TA_CoxaPWM *10-650)*1059/1000-900
FemurAngle1(LegIndex) = (TA_FemurPWM*10-650)*1059/1000-900
TibiaAngle1(LegIndex) = (TA_TibiaPWM*10-650)*1059/1000-900
endif
next
return
;--------------------------------------------------------------------[/code]
I’m not quite sure if there already is a binary command for this. Mike was in the middle of this when I left to work on our house. But if there is a binary version I need to change a few lines to get it optimzed.
I kinda lost track of the ssc binary command set. Does somebody know where I can find the instruction set? Thanks!
More to come soon!
Xan
Hi Xan, there is info about the binary query command on the first page of the thread: viewtopic.php?f=2&t=5953&hilit=ssc+binary
I have done a little playing around with the command, and found that the current code does not take the servo offsets into account when it reports the values. MikeD mentioned that he was working on a fix for it (viewtopic.php?f=2&t=6780&p=66990#p66990)
It will be interesting to see what you have come up with!.
Hi Kurt,
Thanks for the info. This was indeed what I was looking for. Seems like I already had the correct topic when asking for a binary version of the ServoDriver.
Good found! This explains the small errors I got yesterday. 8)
Xan
Hi all,
I posted the binary version of the ServoDriver subroute over here.
I didn’t look at the binary Query command yet. But I did had the time to lay my finger on the little bug in the Leg FK part I posted earlier.
Here is the new version
[code];--------------------------------------------------------------------
;[LEG FK] Calculates the position of the Tars corresponding to the given angles
LegFKLegNr var nib
LegFK [LegFKLegNr]
;Coxa angle
Gosub GetSinCos[CoxaAngle1(LegFKLegNr)-cCoxaAngle1(LegFKLegNr)]
FKSinC4 = Sin4
FKCosC4 = Cos4
;Femur angle
Gosub GetSinCos[FemurAngle1(LegFKLegNr)]
FKSinF4 = Sin4
FKCosF4 = Cos4
;Tibia angle
Gosub GetSinCos[FemurAngle1(LegFKLegNr)-TibiaAngle1(LegFKLegNr)+900]
FKSinT4 = Sin4
FKCosT4 = Cos4
;Position of the tars
FKFeetPosX = (cCoxaLength + (cFemurLengthFKCosF4 + cTibiaLengthFKCosT4)/c4DEC)FKCosC4/c4DEC
FKFeetPosY = (cFemurLengthFKSinF4 + cTibiaLengthFKSinT4)/c4DEC
FKFeetPosZ = (cCoxaLength + (cFemurLengthFKCosF4 + cTibiaLength*FKCosT4)/c4DEC)*FKSinC4/c4DEC
IF LegFKLegNr > 2 THEN
FKFeetPosX = -FKFeetPosX
ENDIF
return
;--------------------------------------------------------------------[/code]
I’m currently integrating the little bits and pieces I tested separatly. But the battery of my Hybrid just died…
More to come soon!
Xan
Edit: Changed the code so it will mirror the X position for the right legs