Free shipping on orders over \$75

 Print view Share : #at3win #at3winheader h3 { text-align:left !important; } Previous topicNext topic

Page 3 of 5 [ 71 posts ]

1, 2, 3, 4, 5
Guru ( offline )
Posts: 1132
Posted: 2009-11-02 17:47
 Post subject: Re: Hybrid Terrain adaption
Robot Dude wrote:
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.

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

_________________
Share, Use and Improve!

Guru ( offline )
Posts: 1132
Posted: 2009-11-02 17:57
 Post subject: Re: Hybrid Terrain adaption
kurte wrote:
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

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 )

_________________
Share, Use and Improve!

Guru ( offline )
Posts: 9256
Posted: 2009-11-02 18:15
 Post subject: Re: Hybrid Terrain adaption
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.

viewtopic.php?f=8&t=4579

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...

Guru ( offline )
Posts: 4937
Posted: 2009-11-02 18:19
 Post subject: Re: Hybrid Terrain adaption
Xan wrote:
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

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

Guru ( offline )
Posts: 4937
Posted: 2009-11-02 18:21
 Post subject: Re: Hybrid Terrain adaption
Robot Dude wrote:
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.

viewtopic.php?f=8&t=4579

Yep, now I remember!
Kurt

Guru ( offline )
Posts: 2131
Posted: 2009-11-03 03:27
 Post subject: Re: Hybrid Terrain adaption
Xan wrote:
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.

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.

Xan wrote:
PS: Don't go with FSR's they won't work for this setup. (Been there, done that )

Oh... I would love to prove you wrong there. ...one day...

_________________
Kåre Halvorsen, Zenta
-----------------------------------------
Zenta's blog
http://zentasrobots.com/
-----------------------------------------

Guru ( offline )
Posts: 1132
Posted: 2010-11-24 20:01
 Post subject: Re: Hybrid Terrain adaption
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.

1. drive a leg down.
2. Stop all servos using the ssc "stop" command, once the leg hits the ground.
3. Query all servo positions from the ssc
4. Do Leg FK
5. Do Inverse Body Translation
6. 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]

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
;--------------------------------------------------------------------

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

_________________
Share, Use and Improve!

Guru ( offline )
Posts: 4937
Posted: 2010-11-24 21:10
 Post subject: Re: Hybrid Terrain adaption
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!.

Guru ( offline )
Posts: 1132
Posted: 2010-11-25 05:47
 Post subject: Re: Hybrid Terrain adaption
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.

kurte wrote:
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)
Good found! This explains the small errors I got yesterday.

Xan

_________________
Share, Use and Improve!

Guru ( offline )
Posts: 1132
Posted: 2010-12-05 11:48
 Post subject: Re: Hybrid Terrain adaption
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 + (cFemurLength*FKCosF4 + cTibiaLength*FKCosT4)/c4DEC)*FKCosC4/c4DEC
FKFeetPosY = (cFemurLength*FKSinF4 + cTibiaLength*FKSinT4)/c4DEC
FKFeetPosZ = (cCoxaLength + (cFemurLength*FKCosF4 + cTibiaLength*FKCosT4)/c4DEC)*FKSinC4/c4DEC

IF LegFKLegNr > 2 THEN
FKFeetPosX = -FKFeetPosX
ENDIF

return
;--------------------------------------------------------------------

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

_________________
Share, Use and Improve!

Guru ( offline )
Posts: 1132
Posted: 2010-12-28 12:08
 Post subject: Re: Hybrid Terrain adaption
Hi guys,

I finished the Query sub route using the fast binary command set for the SSC. The binary version is not only faster but it is also more precise since it returns 2 bytes. The original Query command only returned one byte so the center position of the servo returned "150" instead of "1500". So this is solved with the binary version.

Here is the code:
Code:
;--------------------------------------------------------------------
;[QUERY SERVO POSITION] Queries the current position of the servos
; Using the SSC binary bit mask
;- byte 1 = (binary) 1 0 1 1 s3 s2 s1 s0
;- byte 2 = (binary) 0 s10 s9 s8 s7 s6 s5 s4
;- byte 3 = (binary) 0 s17 s16 s15 s14 s13 s12 s11
;- byte 4 = (binary) 0 s24 s23 s22 s21 s20 s19 s18
;- byte 5 = (binary) 0 s31 s30 s29 s28 s27 s26 s25
TA_CoxaPWM         var word(6)   ;SSC Read value for coxa PWM
TA_FemurPWM         var word(6)   ;SSC Read value for femur PWM
TA_TibiaPWM         var word(6)   ;SSC Read value for tibia PWM
QueryServoPositions:

; Need to query servos like defined it the config file
;               Command - 2, 1, 0    1011-0111   0xB7
;               10, 9, 8 - 6, 5, 4   0111-0111   0x77
;               17, 16            0110-0000   0x60
;               24, 22, 21, 20, 18   0101-1101   0x5D
;               26, 25            0000-0011   0x03
; binary command is always 5 bytes so no <cr> needed
serout cSSC_OUT, cSSC_BAUD, [0xB7, 0x77, 0x60, 0x5D, 0x03]

;read pwm inputs, 2 bytes per servo. Order from lowest pin to highest pin.
serin cSSC_IN, cSSC_BAUD, [TA_TibiaPWM(0).highbyte, TA_TibiaPWM(0).lowbyte, TA_FemurPWM(0).highbyte, TA_FemurPWM(0).lowbyte, TA_CoxaPWM(0).highbyte, TA_CoxaPWM(0).lowbyte |
,TA_TibiaPWM(1).highbyte, TA_TibiaPWM(1).lowbyte, TA_FemurPWM(1).highbyte, TA_FemurPWM(1).lowbyte, TA_CoxaPWM(1).highbyte, TA_CoxaPWM(1).lowbyte |
,TA_TibiaPWM(2).highbyte, TA_TibiaPWM(2).lowbyte, TA_FemurPWM(2).highbyte, TA_FemurPWM(2).lowbyte, TA_CoxaPWM(2).highbyte, TA_CoxaPWM(2).lowbyte |
,TA_TibiaPWM(3).highbyte, TA_TibiaPWM(3).lowbyte, TA_FemurPWM(3).highbyte, TA_FemurPWM(3).lowbyte, TA_CoxaPWM(3).highbyte, TA_CoxaPWM(3).lowbyte |
,TA_TibiaPWM(4).highbyte, TA_TibiaPWM(4).lowbyte, TA_FemurPWM(4).highbyte, TA_FemurPWM(4).lowbyte, TA_CoxaPWM(4).highbyte, TA_CoxaPWM(4).lowbyte |
,TA_TibiaPWM(5).highbyte, TA_TibiaPWM(5).lowbyte, TA_FemurPWM(5).highbyte, TA_FemurPWM(5).lowbyte, TA_CoxaPWM(5).highbyte, TA_CoxaPWM(5).lowbyte]
return
;--------------------------------------------------------------------

Xan

_________________
Share, Use and Improve!

Guru ( offline )
Posts: 2131
Posted: 2010-12-28 16:38
 Post subject: Re: Hybrid Terrain adaption
Hi Xan!

This looks very interesting and it looks like you've had some "quality time". I hope to try this out too one time. Thanks for sharing!

_________________
Kåre Halvorsen, Zenta
-----------------------------------------
Zenta's blog
http://zentasrobots.com/
-----------------------------------------

Guru ( offline )
Posts: 4937
Posted: 2010-12-28 18:16
 Post subject: Re: Hybrid Terrain adaption
Looks great.

It has been awhile since I played with the TA type code. Back then I had code some basic code to do some experiments. What I was curious about was which would give me better approximation of where the leg servos were when the contact happened. Asking the SSC-32 about it. This took the time to respond to the contact happening, plus the time to issue the command and then for it to respond. Or to approximate the position, by knowing when we issued the last command, where the servo was at that time, where the servo was moving to and how long the command was supposed to take and when the interrupt happened. My last set of code for this included:
Code:

;--------------------------------------------------------------------
;[ComputeFKYA] Compute FK for Y given the Femur and Tibia Angles in
;         our coordinate system

#ifdef ENABLE_TA
; first try at figuring out FK for Y
FKYA   var   sword
FEA1   var   sword
TEA1   var   sword
FKY      var   sword
ComputeFKYA[FEA1, TEA1]:
gosub GetSinCos[900-FEA1]
FKY = (cos4 * cFemurLength)/10000      ; Sin or Cos - ???
gosub GetSinCos[(900-FEA1)+(TEA1-900)]
FKY = FKY + (cos4*cTibiaLength)/10000   ; Double check these...
return FKY

FES1   var   word
TES1   var word
FYKSS   var   sword   ; do we need to invert the value
ComputeFKYS[FES1, TES1, FYKSS]
gosub ComputeFKYA[(((FES1-650)*1059)/1000-900)*FYKSS, (((TES1-650)*1059)/1000-900)*FYKSS], FKY
return FKY

WKPINTTABLE   bytetable WKPINT_0, WKPINT_1, WKPINT_2, WKPINT_3, WKPINT_4, WKPINT_5

#endif

'=====================================================

=======================================
'
' Handle the WKPINT interrupt - This happens when a leg is moving down and the contract switch is
'     triggered.
#ifdef ENABLE_TA

_bWhichWKP      var byte      ' Which WKP happened.
_lTimerWKP      var   long      ' Time when the WKP happened
_wDeltaTimeWKP   var   word      ' Delta time between start of command and when the WKP happened
_wWKPFemur      var word      ' Guess for Femur
_wWKPTibia       var   word
_wFEMFromSSC   var   word
_wTIBFromSSC   var word
_FKYFS         var   sword
_wFEMFromSSC2   var   word
_wTIBFromSSC2   var word
_FKYFS2         var   sword

Handle_WKP0:
_bWhichWKP = 0
disable WKPINT_0   ; only interrupt once per leg...
goto Handle_WKP

Handle_WKP1:
_bWhichWKP = 1
disable WKPINT_1   ; only interrupt once per leg...
goto Handle_WKP

Handle_WKP2:
_bWhichWKP = 2
disable WKPINT_2   ; only interrupt once per leg...
goto Handle_WKP

Handle_WKP3:
_bWhichWKP = 3
disable WKPINT_3   ; only interrupt once per leg...
goto Handle_WKP

Handle_WKP4:
_bWhichWKP = 4
disable WKPINT_4   ; only interrupt once per leg...
goto Handle_WKP

Handle_WKP5:
disable WKPINT_5   ; only interrupt once per leg...
_bWhichWKP = 5

Handle_WKP:
; Get the current time - interrupts not enabled so need to fix if a rollover happens
enable
gosub GetCurrentTime[], _lTimerWKP

' Pass 1 lets see where we think the Y is by a few different methods...
_wDeltaTimeWKP = ((_lTimerWKP-lTimerStart) * WTIMERTICSPERMSMUL) / WTIMERTICSPERMSDIV

' Stop all servos...
disable   ' let the serouts work
serout cSSC_OUT, cSSC_BAUD, [0xA2]      ; Stop command...

' BUGBUG: using 38400 right now so can use serin/serout...
_wFEMFromSSC = 0
_wTIBFromSSC = 0
serout cSSC_OUT, cSSC_BAUD, ["QP", dec cFemurPin(_bWhichWKP), "QP", dec cTibiaPin(_bWhichWKP),13]
serin cSSC_IN, cSSC_BAUD, 10000, _HWKP_TO, [_wFEMFromSSC.lowbyte, _wTIBFromSSC.lowbyte]
_HWKP_TO:
_wFEMFromSSC = _wFEMFromSSC * 10
_wTIBFromSSC = _wTIBFromSSC * 10
enable
disable
serin cSSC_In, cSSC_BAUD, 10000, _HWKP_TO2,[_wFEMFromSSC2.highbyte, _wFEMFromSSC2.lowbyte,_wTIBFromSSC2.highbyte, _wTIBFromSSC2.lowbyte];
_HWKP_TO2:

if prevssctime then

_wWKPFemur = awSSCFemurAnglePrev(_bWhichWKP) + |
((awSSCFemurAngle(_bWhichWKP)-awSSCFemurAnglePrev(_bWhichWKP)) * _wDeltaTimeWKP) / PrevSSCTime
_wWKPTibia = awSSCTibiaAnglePrev(_bWhichWKP) + |
((awSSCTibiaAnglePrev(_bWhichWKP)-awSSCTibiaAngle(_bWhichWKP)) * _wDeltaTimeWKP) / PrevSSCTime

if _bWhichWKP < 3 then
gosub ComputeFKYS[_wFEMFromSSC, _wTIBFromSSC, -1], _FKYFS
gosub ComputeFKYS[_wFEMFromSSC2, _wTIBFromSSC2, -1], _FKYFS2
gosub ComputeFKYS[_wWKPFemur, _wWKPTibia, -1]
else
gosub ComputeFKYS[_wTIBFromSSC, _wTIBFromSSC, 1], _FKYFS
gosub ComputeFKYS[_wTIBFromSSC2, _wTIBFromSSC2, 1], _FKYFS2
gosub ComputeFKYS[_wWKPFemur, _wWKPTibia, 1]
endif
#ifdef HSP_DEBUG
hserout HSP_DEBUG, [13, "WC: ", dec _bWhichWKP, " ", dec awSSCFemurAnglePrev(_bWhichWKP) ,"-",dec awSSCFemurAngle(_bWhichWKP),|
" ", dec awSSCTibiaAnglePrev(_bWhichWKP), "-", dec awSSCTibiaAngle(_bWhichWKP), |
" T:",  dec _wDeltaTimeWKP, ":", dec prevssctime, |
"(", dec _wWKPFemur,",",dec _wWKPTibia,"=",sdec FKY,")"]
hserout HSP_DEBUG, ["{", dec _wFEMFromSSC, ",",dec _wTIBFromSSC, "=", sdec _FKYFS,"}","<", dec _wFEMFromSSC2, ",",dec _wTIBFromSSC2, "=", sdec _FKYFS2,">",13];
#else
disable
serout s_out, i9600, ["WC: ", dec _bWhichWKP, "(", dec _wWKPFemur,",",dec _wWKPTibia,"=",sdec FKY,")",13];
enable
#endif
endif
resume
#endif

This code is where I found the offset issue with the SSC-32. Should try it again, now that the bug was fixed. Also need to try on a hard surface to see if I can get better triggering with the SSC-32. If the approximation code looks at all promising, I may change the actual interrupt code to be in ASM, where it captures which leg and the time, and then probably does the rest in basic. Could be another triggered interrupt or could have the code check a state variable at several key points in the program...

I am also glad that you are getting some time to work on this again and can not wait to see how you process the leg information when contact is made.

Great work!
Kurt

Guru ( offline )
Posts: 1132
Posted: 2010-12-29 09:46
 Post subject: Re: Hybrid Terrain adaption
Hi Kurt,

sounds interesting. Calculating position from taking a point in time. So if it takes 200mS to get from point A to point B and the tars sensor get tripped after 50mS this will say that it traveled 25% of it's movement. Interesting theory, I'm curious about how accurate that will be. This will remove the need to do FK btw. And it will be easier to adjust by an overshoot as well. Just take 23% or so.

Xan

_________________
Share, Use and Improve!

Guru ( offline )
Posts: 1132
Posted: 2011-03-13 08:56
 Post subject: Re: Hybrid Terrain adaption
Hi guys,

With the T(A)-Hex coming together pretty fast and Kurt willing to join me on this project I want to share some thoughts and work I did on this.

TA Methods
The following methods came up to my path. There might be more or better ones. Feel free to fill me in.
1. Small steps
I won't go in to detail on this one since I've already demonstrated this in a video on youtube and talked about this a lot in my previous posts. It is pretty easy since there is no need to do FK for the legs and IK for the body. But it is very slow.
2. Stop command
Like explained earlier, the leg goes down until it hits an object (ground). The BAP will see this end sends the stop all command to the SSC to stop further movement. Then the servo positions will be queried. The positions of the legs and body will be determined using Forward Kinematics for the legs and Inverse Kinematics for the Body. With the new known position the gait can move to his next step.
3. Time measurement
I read this idea from Kurt on the forum. The idea is that once the leg is going down. The full sequence should take 200mS to travel from position A(0,0,0) to position B(12,20,40). If the leg hits the ground after 150mS it means that it only took 3/4 of the total time. This should mean that the distance traveled is also 3/4 of the total distance. The final position will be at (4,15,30).

Route to follow
With the 3 TA methods laid out I want to talk about which method would be the best.
Method 1 is shown in this youtube video. As I said, it is to slow. It sure can be improved with the faster binary command set and the full speed connection. It even can be increased a bit by using the ARC since there is no communication between the 2 boards. But still, the hex should take really small steps to decrease the amount of overshoot and accuracy. Method 3 shouldn't be to hard to implement. But I've got kinda doubts about how accurate it will be. And I kinda have a strange feeling about determine position by measuring time. This would only work if we have the exact time of the movement and the movement should be fully linear. Maybe the errors will be small enough to get away with it though. Method 2 is the hardest of 3 but also the most accurate, has almost no overshoot and is pretty fast. The reason why this method is so hard to accomplish is that once the leg touches the ground all servos stop and a lot of positions are lost! it is possible to query the servo angles but we still need to calculate so see where the leg(s) and body really are. This doubles the calculations needed.

I've been currently working to method 3 since I think this is the most professional way to go...

Balance Calculations are the key to success
I'm convinced that Zenta's Balance Calculations are the key to success then wit comes to Terrain Adaption. As most of you may know the balance calculation ensures that the body always stays relative to the position of the 6 tars. This is not only in all positions (x,y,z) but also in all angles (pitch, yaw, roll). Since TA will make our Gait engine into a full closed-loop system needs to take care of the environment. This means that the origin = ground will change from now on. To show this I made a small drawing.

In the first set of drawings you can see that the origin will stay put when the hex crawls over an object. Even if we increase the height Y it will still become a problem since it isn't possible to put a infinite large number in a word

With the balance calculations turned on, the origin will move with the hex. This makes the height Y always the relatively height between the tars and the body. Not the height from the origin starting point to the body.

This is why the balance calculations is the key to success

Next up I will talk more into detail about the needed calculations for method 3 and how to implement in the current phoenix code.

_________________
Share, Use and Improve!