wiping the sweat from my brow- 
does anyone have any good ideas on how to get the legs to “slowly” move down by one increment every .5sec in till the FSR switch goes high. then its to hold this position in till gait step has finished, then return to initpos or natural position, 'then loop?
i think im close but im getting large movements instead of small +1 increments.
The person who really needs to be involved is Jeroen himself. Maybe someone needs to email him to see if he’s gotten all moved into his new house. 
i spoke with him a few days ago, he is still about but very busy with things at the moment. but yes your right, we need him back.
he has a few things to sort out with his house but from what i gather he is settled nicely. 
Hi,
I think Jeroen should answer for himself about when he is “back in the robotic business”. I just wanted to shoot in that I visited him last week for 4 days. I don’t think I’ve ever spoken to anyone so much about robotics ever, we had a really fun time together. 
When it comes to TA, we talked about it a lot. Jeroen convinced me that the kinematics (FK, IK and Rotation) method used in the Phoenix code need some improvements for making TA work properly. I think there is a reason for why we doesn’t see many TA hexapods out there… Also, the balance mode is the key for TA success. And thats where the hard part comes in, because of the forward kinematics (FK). FK is totally necessary for making TA work properly. You can use the step-by-step method like Jeroen used in his demo of the hybrid, but it isn’t very effective and its also very slow.
yes, xan had outline this to be the other week.
He tried 2 methods;
1: Move a leg down in small steps and check if it touches something.
pros: you know where the leg is at all times
negs: slow, inaccurate
2: Move a leg down, stop the leg as soon as it hits something.
pros: Fast, accurate
negs: *the end position is unknown. a lot of math is involved to get the leg position.
*
Also
Option 1: is tested but since the leg was so slow.video I dropped this option.
Option 2: like explained, a leg will drop down until it reaches the ground or an object. Once the sensor is hit the BAP sends a STOP command to the SSC. This will stop all servos at an unknown position.
The next thing to do is do FK for the legs to return there positions. This is done. But to get the position of the body we need to do IK for the body. But since this is a plain with 2x3 joints it is a bit complexer then a link with 1x2 joints.
The Math is really hard and it is getting really deep in to the math/code to fully understand the problem.
Looks like i have a bit more play time. should get sensors in a few weeks so more testing will follow.
Zenta, it sounds like you had lots of fun! I hope Xan can start to play soon! But I fully understand how many other things there are to do when you move into a new place.
#1 does not sound very good if it is both slow and inaccurate 
Sometime soon I will start trying to do #2. I have the switches now, but may choose to reorder the tubing as my first original CHR-3 (before I changed the legs) had 3" tubings, The 1.5" tubing with the contact switches is considerably smaller. So thinking of maybe ordering the 2.25" tubes…
What I want to try is how far off will we be if we know the three(in my case) servos of a leg are going from Pulse widths of:
pw1Coxa, pw1Femur, pw1Tibia to new pulse widths pw2Coxa, pw2Femur, pw2Tiba in time dT. Now if contact is made during this move, how far off will we be if we calculate what we think the angles will be at that time. That is if if we are asking the coxa to change its pulse width from 1500 to 1700 in 100ms and the contact happened at delta time 80ms, how far off would we be if we assumed that the coxa was out:
1500 + 200*80/100 = 1660? This is assuming linear… It will be interesting to see if this is more accurate or is it more accurate to try to tell the ssc-32 to stop and get it’s values, which may be off by how long it took you to tell the servos to stop…
Note: we may not need to use the Pulse widths here, instead we could do the same calculations using the angles in 10ths of degree that we pass into ServoDriver for this. Given the three angles and the lengths, I would hope it would not be difficult to determine the position of the leg.
But I know that is only step one. We really need someone like Xan and Zenta who understand the math to get TA to work… I will just be fun to see if I can get some of the rudimentary things to work.
Kurt
#2 may not be totally accurate. In my testing with the popcicle stick/paperclip ssc-32 setup, I always knew where the servo stopped. All I did was ask the ssc-32 what the current position of the servo (the last position sent to the servo before it was stopped). It was sufficiently accurate and repeatable.
In CNC, I handle an interrupted cut by decelerating, and then reading the position of the 4 axis. I can then re-calculate the remaining move to get to the next Gcode block if desired (continue), or abort. Seems like you’d want the same thing for a leg move.
Alan KM6VV
Yes at the moment im only trying to get the basics laid out. For instance:
with TA off, each step happens by cycling though each gait step, and once each leg has returned to its initpos the cycle moves to the next leg. But…
With TA on, these initpos positions change with the terrain. But they are constants not variables’ There for im only looking at getting each leg to cycle though, and at each instant that the switch is active then the cycle moves to the next leg. To do this we need to make the initpos a variable.
In my code my #initposY is con 18. Needs to be #initposY =18. Small details here but you know what i mean. Anyway, we could increment the variable by say +1 in till the sensor is activated. Then save that variable by knowing how many increments have been made before it switched. And once gait cycle has moved to the next leg then the initpos returns to #initposY=18. Make sense?
OK, i have changed the InitposY to variable.
when turning on the robot everything works correctly in till a sensor connects. from this point the SSC light turns off and resets! power is good! ???
im only testing the legs to drop when no switch is active. once i have sorted out this problem i will try adding the next part. holding new initpos in till cycle moves to the next leg.
ps2
;Terrain adaption mode on/off
IF (DualShock(2).bit6 = 0) and LastButton(1).bit6 THEN ;Cross Button test
FSROn = FSROn^1
IF FSROn THEN
sound P9,[250\3000]
ELSE
sound P9,[100\4000, 50\8000]
ENDIF
ENDIF
;Initial start positions
cRRInitPosY var sword
cRFInitPosY var sword
cLRInitPosY var sword
cLFInitPosY var sword
in [init]
[code];[START POSITIONS FEET]
cRRInitPosY = 18
cRFInitPosY = 18
cLRInitPosY = 18
cLFInitPosY = 18
FSROn = 0
[/code]
in Main
;Terrain adaption *Get input from Tars pressure sensors*
IF FSROn THEN
gosub ReadFSR
gosub RightFront
gosub RightRear
gosub LeftFront
gosub LeftRear
ELSE
RF_FSR =0
RR_FSR =0
LF_FSR =0
LR_FSR =0
ENDIF
subs
[code];[ReadFSR] Reading input from Foot Sensing Resistor
ReadFSR:
RF_FSR = in16
RR_FSR = in17
LR_FSR = in18
LF_FSR = in19
return
;----------------------------------------------
RightFront
IF RF_FSR=0 THEN
cRFInitPosY = cRFInitPosY +1
Pause 100
goto RightFront
Else
cRFInitPosY = 18
ENDIF
return
;-----------------
RightRear
IF RR_FSR=0 THEN
cRRInitPosY = cRRInitPosY +1
Pause 100
goto RightRear
Else
cRRInitPosY = 18
ENDIF
return
;---------------------------------------
LeftFront
IF LF_FSR=0 THEN
cLFInitPosY = cLFInitPosY +1
Pause 100
goto RightFront
Else
cLFInitPosY = 18
ENDIF
return
;-----------------
LeftRear
IF LR_FSR=0 THEN
cLRInitPosY = cLRInitPosY +1
Pause 100
goto LeftRear
Else
cLRInitPosY = 18
ENDIF
return[/code]
Hi, I am not sure about these functions:
RightFront
IF RF_FSR=0 THEN
cRFInitPosY = cRFInitPosY +1
Pause 100
goto RightFront
Else
cRFInitPosY = 18
ENDIF
returnIf I am reading this right if RF_FSR=0 you will hang forever as nothing will change this value, you will simply increment a different variable, pause and then go back to test the variable that did not change…
Kurt
Jonny,
Do you use a resistor to +5 to the “hot” end of the sensor? It sounds like you might be pulling the +5 to ground.
Alan KM6VV
I’ve checked over the wiring and it looks to be correct. If there were a wiring error it would be shorting the BotBoards 5vdc line to ground. This couldn’t reset the SSC-32.
Personally I think is code is hung as I mentioned in my previous post… The SSC-32 is not blinking anymore as it is not receiving any data.
Kurt
Agree with Kurt, as long as the FSR value doesn’t get updated within the loop, the loop is endless.
Another thing, I wouldn’t recommend messing with the cXXInitPos constants as variables, you could simply add a new variable. And add the new variable in the “adding strings” in the call of the BalCalcOneLeg, BodyIK and LegIK subs. The init constant are meant to be a reference for the initial positions.
Yes this also seemed the case from this end. but jim is also correct, my connections are fine.
i have changed back the initpos to con as you mentioned zenta.
i have also gone another way rather than editing the BalCalcOneLeg, BodyIK and LegIK subs.
Anyway Result, i have something…
when the FSR mode is turned on the legs start to drop, they stop when connection made, gait cycle and loop!!! yay. all will be clear when i done some more testing.
Sounds like you are doing some progress Jonny, and having some fun too!
yes. sadly iv been testing hard over the last few days so now i charging up those 9v’s ready for tomorrow nights test.
looks promising. i will aim to get a progress report by the weekend, but no promises just yet. really busy at the mo with other stuff. as always.
hopefully my switches will arrive soon 'just in time for a video, maybe in the next few weeks. hows that sound?
Did somebody miss me? 