all my test are as above>
that is what im after! so far i havent had much luck in even programming the legs to keep dropping. or stop when sensor is down. i have nothing. need help. 
You may want to revisit some of my previous post on tinkering with foot contact detection(below). At the end of the first link below is some basic code I used on my pc for control of the ssc-32 during my tinkering. The bottom link and video show the simple test setup I used. Please excuse the popcicle stick, paperclip, and aluminum foil, but they get the testing done apparently to the dismay of others. 
viewtopic.php?f=28&t=3655&p=45718
viewtopic.php?f=8&t=4658l
youtube.com/watch?v=3zQalB0bfNE
thanks. missed those threads completely. interesting test. not sure i know how to use/convert your code into the phoenix code but i will start looking though it now. great work, thanks.
The key points are that the latest version of the ssc-32 has a servo “stop” command and the last position sent to the servo during a timed move can be obtained from the ssc-32. So a servo can be given a timed move, when contact is detected, the servo can be stopped, and the ssc-32 can supply the ~position at which the servo was stopped during the timed move.
that’s what i need help on. i will look though your posts but im not sure i understand how to write it. also i will look again though the manual. always useful. thanks.
your code is very help full. maybe i might be able to work on it using some of the parts. 8)
What you may want to do is write a simple pc program in something like just basic to just move the legs on one side of your bot up and down in sequence to test the contact switches. Using a pc for testing may be the easiest first thing to do to see how the contact switches will work. In my video the servo was shakey as every thing including the servo was being powered off the USB port of my laptop, along with running the ssc-32 program while uploading the live video to youtube. With the servo using an independent 5.7v power supply and the laptop only running the JB program, the servo motion was very smooth and controlled.
Rather than stopping the servos and retrieving the servo position from the SSC, perhaps you could just lower the foot in small increments and every loop (or every time you lower the leg a little), check to see if the switches are engaged. This would allow for a straighter vertical movement with the leg.
My $0.02.
im not sure that would be solving the math IK but yes that is what my first intentions are!
im not a programmer but i expected it to be something like this?
[code]RightFront:
IF RF_FSR = 0 THEN RightFront ;check sensor state
IF RF_FSR = 1 THEN RFDown ;check if switch is on if so goto label RFDown
goto RightFront ;will continue to loop until switch active
RFDown:
cRRInitPosY = cRRInitPosY-1 ;Lower Leg
goto RightFront ;goes back to main loop and starts over again
END[/code]
i have also been looking at other functions of the AtomPro. the Repeat & **Until ** function.
[code]Repeat
cRFInitPosY = cRFInitPosY + 1
pause 75
Until RF_FSR>0[/code]
unfortunately i cannot test this as my battery’s need charging.
The good news is i have my FSR sensors. 
The bad news is i need to rewire them. i didnt make my wires long enough! Doh! i didn’t really leave much of a tail to connect the sensors too.
Yesterday (finally) I started to wire up the sensors from the legs of the hexapod. That is when I found out that I had to redo a few of them as the connections were either too lose or shorting out… Now in the process of wiring them up to the Bap28. I am trying to wire them in with LEDs such that I can see when they make or break contact. So far it looks like my best bet is to have the LED on when the leg is lifted. The LED is not very bright as the +5v is coming from the pull-up resistor. I am also still putting a resistor in from the LED to ground as I don’t want a dead short if I by accident put the IO pin high…
I should hopefully have this part done in the next few days depending on whatever else catches my interest 
After I wire it in, I will experiment with trying to catch exactly when a switch happens and stop the leg. Will try a couple of different approaches. One is to simply tell the SSC-32 to stop those servos. The next approach will be to try to determine where the servos should be and tell them to go there. I am hoping this approach should work well.
Assuming this works well, I am not sure what the next step should be. That is if the leg is going down and makes contact, do you simply stop that leg until it is directed to lift up? Or do you detect how far up from where it hits something versus where it expects ground to be and if going down subtract that delta from it? Not sure yet. Lots to experiment with.
Kurt
Sounds like a fun project Kurt.
Using LED sounds like a good idea, I’ve seen other people also used LED in combination with ground contact switches, a very simple and effective indicator.
I’m pretty sure you’ll come up with something clever when it comes to the code part
I’d suggest starting the leg high, moving the leg down (using a single servo if possible), stop the moving servo when contact is detected, then query the current position of the servo. I would think IK is generally out of play as IK should be sending the leg to a specific point on a flat surface, which is unknown on uneven terrain. The relative positions of the servos should be checked often to ensure the overall position of the bot is not creeping up or down, and adjust as needed.
i was thinking that maybe the leg could be lowered by incremental drops 'that can be counted, then once the sensor is on the ground then the “counted number” can then determine how far the servo has dropped. then this data can be used to the the IK know were the leg is. … so how. 
my first thoughts when trying to evolve the IK for terrain differences was first to make the Initpos a variable and then use this to drop the leg. or be changed by adding the “counted increment number”.
im no programmer so im not sure that will work. i fully understand there is a huge amount of Math involved but im just hoping that maybe a simple idea like this can be allied!?
I think the hard part for me is to figure out the math, after I have a general idea of that the coding may not be that hard.
Zoomkat - I understand what you are saying, but I would like to semi-solve this for walking in the different gaits. For example if we are walking using one of the tripod gaits on a normal surface i believe the three legs still on the ground may push the body up some while the other three legs lift up, I notice this more when for example balance mode is turned on. So this would not work if we simply stop when we make contact.
What I think may be needed in this case is to do something like:
a) know what the logical Y location for the ground. My guess is that we probably already know that. Call it LGY
b) When a leg is logically moving down, when the leg hits the ground we need to calculate the Y of where we found ground. this is probably done in a couple of steps.
- get the servo angles - Ask SSC-32 and/or guess. the guess would be knowing the delta time from when we started the move, we know how long we told the servo to take to get there and we know where we started and where we were going. My guess is a simple linear approximation may be as or more accurate than telling the servos to stop and then asking the servos where they are…
- Given the two angles plus the lengths of the two parts of the legs, we should be able to calculate the actual Y of where we hit. Probably something like a sin or cos of the angles times length… (My math is rusty here
) bug call it AGY for actual ground y
) bug call it AGY for actual ground yc) if the Y of where we hit was where we expected ground, we let the leg continue to the calculated position. If there is a deltaY and our end Y was not at logical groundY we recompute a new Y which is something like: NewY = DesiredY - (LGY-AGY) and tell that leg to go there…
questions:
- What to do if the leg gets to end position and it does not hit ground? should we instruct it to continue down a little farther to try to find the bottom of the divit?
- If the leg is logically going up, do we need to do anything?
- how does this work if we find we are starting to walk up or down an incline?
- Do we have enough horse power to do this?
Well I guess I should get started, I keep dragging my feet on wiring this up.
Kurt
Too funny…
I think in order to properly do this you need an accelerometer on the body. We are all assuming the robot is totally level when walking then suddenly, as it’s walking, the ground is no longer flat. Sure you can detect the ground with the switch on the feet. But if you have no idea of the orientation of the body, we can’t truly know if the leg is below or above the true ground plane.
If you are using an ssc-32 (latest version), you don’t have to count. When the ssc-32 is given a timed move, the move is made internally in the ssc-32 in a lot of small position increments. When the servo movement is stopped, the ssc-32 can provide the last incremental position the servo was sent to (not the final position given in the origional command). Bottom is test data obtained using my popcicle stick setup that shows the position where the servo was stopped and the stopped position obtained from the ssc-32. The initial leg position was “#0P2500” (full up) with a timed move to “#0P500T3000” (full down).
You can only find the logical distance between the bottom of the bot body and ground by examining the current leg up/down servo positions. To start, with bot sitting with legs full up, move all legs downward until they make contact and stop. Get the leg positions, get an adverage position of all legs, then compare the average to a normal flat ground standing servo position. Add the difference between the avaraged position and normal position to all legs to move the bot up to ~normal distance from the ground. Repeat every step or two to keep the bot from gradually sitting down or standing up too high. In the real world the ground can be anywhere between the leg fullup position to the full down position. I suggest starting out testng with three legs on one side of the bot just going up and down in sequence, and see what it tales to keep that side of the bot from gradually tilting up or down. Then start sliding objects of varing thickness in and out under the feet to see how well the leg responds to the changing heights. It will probably easier to use a pc program to do the initial testing instead of a microcontroller.
=============================
step 1
starting 2 second start delay
voltage byte is 0
position byte is Ã…
servo position is 1380
step 2
starting 2 second start delay
voltage byte is 0
position byte is ‡
servo position is 1350
step 3
starting 2 second start delay
voltage byte is 3
position byte is Ã…
servo position is 1380
step 4
starting 2 second start delay
voltage byte is 19
position byte is ‹
servo position is 1390
step 5
starting 2 second start delay
voltage byte is 6
position byte is ‹
servo position is 1390
step 6
starting 2 second start delay
voltage byte is 2
position byte is ‹
servo position is 1390
step 7
starting 2 second start delay
voltage byte is 0
position byte is Ã…
servo position is 1380
step 8
starting 2 second start delay
voltage byte is 1
position byte is Ã…
servo position is 1380
step 9
starting 2 second start delay
voltage byte is 0
position byte is Ã…
servo position is 1380
step 10
starting 2 second start delay
voltage byte is 6
position byte is ‹
servo position is 1390
done
You are probably right if I get that far. I will try to remember to order one in my next order. Sure wish you had the cheap $5 shipping for small priority mail size packages. I would order things like this when I needed it… (Different subject)
I have played around some on this. I have the 6 legs wired up, 6 LEDs and the like going to a breadboard. I think I should probably wire this up better with solder as I find the connections are not as reliable on the breadboard. But with this initial setup I found that I have issues with the switches being reliably triggered when the leg hit the ground. This is especially true on my CHR-3 that the initial position had the legs never going straight up and down. I initially had set this such that when the body was on the ground and you folded the legs up as far as they would go… I experimented with different values and now have the legs much closer to having the tibia be much closer to vertical and that has helped.
I have been looking over the code and will probably start off ignoring balance mode. With that off, I believe the code will not push the robot up as part of the gait. Looking over the different variables, I believe that if I at first only concentrate on the Y positions of the legs I need to deal with certain variables:
LegPosY(leg) - I believe this is more or less a contact that is set to the initial position of each leg.
BodyPosY - This is set by the User interface. This is how far up to raise the body. One value used on all legs.
GaitPosY(leg) - Set by the gait engine. Full down I believe is 0
There are a a few more variables/arrays like TotalTransY that are used but I think these only come into play when balance mode is on.
So next will be to probably print out several Y values as I walk through the different gaits to see if my assumptions look correct. I may take a small diversion here to do some more XBEE packet mode work. In particular I may set it up such that I control the Hex by the XBEE, but the robot will also be able to send debug messages over the XBEE to a different XBEE on the PC that will display the debug messages. Pro - don’t have to hang up the robot while waiting for bitbang serial to complete. Also debug stuff should not be corrupted by other interrupts that are happening…
Then try experiments of when the leg hits and the switch triggers try a couple of ways to see where it is.
a) Ask SSC-32 where the servos are and write the FK code to compute the Y of where we hit.
b) Guess the servo locations by interpolating how far we were moving, how long the move was supposed to take and how long it took to hit something. Again write FK code to compute the Y.
c) I wonder if I can shortcut all of this and simply interpolate Ys? That is if the leg is moving from LY1 to Ly2 in time Tm and the we stopped in Time Tn can we reasonably assume that we covered Tm/Tn percentage of the delta from LY1 to LY2? That is can we ignore the servos and computing the FK, but just assume we got that percentage of that position there. That would also be true for X and Z as well. - I am thinking this simplification may be worth trying…
That is all for now.
Kurt
I never know when someone orders. Please let me know when you are ordering something for this sort of research. I would gladly send you an accelerometer for free. Just give me a heads up.
Sounds like a fast method to know where the legs are with simple math. Could be the answer! 
I have been playing around some this weekend. I rewired and got rid of the breadboard. I now wired each one separate, with their own 3 wire plug. I have the pull-up (I used a 2.2K) and then from there I wired an LED to ground. I know that if I power up the pin to high, I could blow the LED, as it is they are not bright… With 6 sets of wires coming up with the LED it sort-of looks like a medusa…
I now have the code remembering what Y locations we are going to and the previous y locations. Also my current code already remembered what pulses I ask the SSC-32 to generate for each servo. It now also remembers the previous one.
I then wanted to be able to calculate the Y given the femur and tibia angles as well as the lengths… (IE the FK). With the help of Zentas PEP I am now able to calculate it given the angels in 10ths of a degree that the phoenix code uses:
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
This gets me pretty close. I then wanted to be able to do it from the actual servo pulse widths. That can be done by reversing the code that generate the pulses in the ServoDriver code.
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
Not sure yet if I will need to do the same for the X or Z directions yet…
I now have worked up some code to handle the 6 WKP interrupts, which will see how close my guess is by delta time is to the values I query back from the SSC-32.
Will probably debug this tomorrow. The issue I am running into now is I am running out of code space on the Bap28. I can now choose to get rid of some stuff like faster SSC-32 communications, or I am now thinking of moving it over to an Arc32. But if I do that not sure yet if I should go with it doing everything like I have it do with the phoenix or should I still use the SSC-32 to do some of it…
That is all for now.
Kurt