Yeah - sound great 
Over the weekend I will try to have something for you to test out the switches. Not sure yet if it will be separate program or maybe some code added to T-Hex code connected to one of the PS2 buttons… Will use the pin numbers you suggested.
Kurt
Actually thinking about it, May want the switches on P0-P5 as first ideas was to use an interrupt to know when a switch contact has been made. We were using the WKP interrupt which have the interrupts pins on pins 0-5. Alternatively I could later explore using a timer interrupt to poll if any IO pins has changed, but that would add more overhead…
Kurt
Can i have a set… I will help to developp the software too…
Big LOLLL…!
Can’t wait to see it in action. You should make a video of the test phase too.
Are the FSR not usable ?
I never say anything won’t work. As soon as I do someone proves me wrong. The FSR sensor works as it is supposed to. However I have not heard anyone use them successfully in a build. That doesn’t mean they don’t work, it only means if they were used no one has bothered to tell us about it yet. Lots of college level projects are never published.
Ok we will move them to 0-5. Thats where James wanted to put them in the first place. lol We still have 16-19 as analog inputs too.
If you gurus cant make it work, neither can I
too bad i have six of them … ok, I’ll line up in queue to buy the other new footswitches allong whith you others …
Ive continued my experiments and i have seen continued difficulties to stop the downgoing motion using FSR (HFS-01) especially when i put the Rubber Foot Tip Bumper on, and i have therefor orderd six microswitsches D2F-01L. My idea is to use the same tubing (AT-01) and endcap (HUB-09), and just make a small “window” in the tube and put the switch in there … well well lets se if it works, i’ll get the switches next week
Yes, i was looking at them, but i dont think they will hold … aleast not the small ones fitting on the end of a leg (6x6mm)
A microswitsch has a little notch, and when it is fully pressed the whole microswitsch chassie takes the preasureforce, but on a Tach-switch all force comes on the button, between 15 to 30 N, and this is way over specifications. Maby it will hold … but then for how long ?
At only ~$1 each, the tactile switches seem like something to try. They seem to be pretty tough, but do take some force to actuate.
I have not had as much time this weekend as I hoped for. I have been busy building an 8’x10’ cedar chicken coup. This weekend I shingled the roof.
But I did get a little playing time. So I put a Bap28 on my CHR-3 (had Arduino Mega) and downloaded the 3DOF T-Hex zip file mentioned in the tutorial. Compiled it and the PS2 did not work… Found I grabbed on old Atom Bot Board instead of a Bot Board 2, so I swapped it out… Works… Did not test walking as my configuration is different than T-Hex…
I added some code to the Single Leg Mode (hit Circle button on Ps2). If you now hit the R1 button in this mode, it will walk through the six legs, lift them up some and put them back down, somewhat slowly. Took me longer to do this than I expected as at first the legs just wiggled. Figured out that was because the main code only waits for the previous SSC-32 move to complete if we are part of a gait… So I added a flag variable (fForceWaitForSSC), that the controller can sets that says wait for the previous move to complete before issuing the next one. Now it goes through all six legs. I set this part up as sort-of state machine:
SelectLeg:(needed this one as the Single Leg mode hard coded when you choose a new leg to move the y a fixed amount ignoring what you passed in.
RaiseLeg: Moves up some
LowerLeg: Moves back down
WaitforLowerLeg : waits until the lower leg completes before it goes up to select a new leg…
That part appears to be limping along. I wrote a quick and very dirty set of WKP interrupt handlers. That sends out a stop byte to the SSC-32, outputs a message to the debug terminal and beeps (each beep is different as it depends on which WKP interupt… This part is not tested much yet as I ran out of time and my old contact switches are not doing very well… May try to TLC them some today to verify this works at all…
As I mentioned in a previous post, I think we should do P0-P5 as we will probably be using the WKP0-WKP5 interrupts to process the contact switches.
Also I wonder if we should define them in the order that the other byte tables in the code are defined? Could add another byte table to convert, but maybe we could avoid the need for it. The other tables are defined in the order: Right Rear, Right Middle, Right Front, Left Rear, Left Middle, Left Front. The code in the zip file assumes this, but again it would be easy to change the function: EnableLegContactSwitch[_bWhichLeg]:
That is all for now.
Warning: I just updated the file again, with more updated interrupt stuff. Still not sure if it is working yet… Need to play with my switches. Also Some of the code at the start:
IEGR2.bit0 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit1 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit2 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit3 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit4 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit5 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
The value of 0 or 1 for these will depend on how these switches work. Does the value go high or low when the switch contact is made.
Kurt
T-HEX-Contact.zip (17.4 KB)
Ok, I will update the bots. So then it should be this, right? Right rear: P0
Right middle: P1
Right front: P2
Left rear: P3
Left middle: P4
Left front: P5
Yep that look correct 
In the end it may not matter which order we put them in as I will probably cleanup the code that does a set of if leg=0 then… and have it be a bytetable with the WKP mask to use… But it might make it easier for others to follow along.
Thanks James.
Kurt
Well, it’s much easier in my opinion to just plug in the things in the same order as they are used in the code. No need to swap values in code that way.
Totally agree.
I did a quick and dirty test to see if the WKP interrupts, should trigger when the switch is closed. My assumption is that the switch is connected up with a pull-up resistor, so it is high when the switch is open and low when it is closed… I used a large pushbutton I had sitting around and servo wire (that had the end removed off one end… I connected ground to one poll of the switch and the signal wire to other along with the plus through a 1K resistor… I then ran on quick test using a Bap28 (on an ABB) with the following code:
[code]fIntPending var bit
; Setup to use WKPINT for interrupts for
; for test will probably just use basic…
oninterrupt WKPINT_0, handle_WKP0
oninterrupt WKPINT_1, handle_WKP1
oninterrupt WKPINT_2, handle_WKP2
oninterrupt WKPINT_3, handle_WKP3
oninterrupt WKPINT_4, handle_WKP4
oninterrupt WKPINT_5, handle_WKP5
;----------------------------- Init System components ---------------------------------------
PMR5.bit0 = 1 ;enables pin as WKP interrupt instead of normal I/O
PMR5.bit1 = 1 ;enables pin as WKP interrupt instead of normal I/O
PMR5.bit2 = 1 ;enables pin as WKP interrupt instead of normal I/O
PMR5.bit3 = 1 ;enables pin as WKP interrupt instead of normal I/O
PMR5.bit4 = 1 ;enables pin as WKP interrupt instead of normal I/O
PMR5.bit5 = 1 ;enables pin as WKP interrupt instead of normal I/O
IEGR2.bit0 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit1 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit2 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit3 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit4 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
IEGR2.bit5 = 0 ;0 = Pin will interrupt on a falling edge, 1 to interrupt on a rising edge.
enable
sound p9, [50\4000, 50\4500, 50\5000]
pause 500
Main:
fIntPending = 1
enable WKPINT_0
sound p9, [50\4000]
while fIntPending
wend
pause 500
goto main
; simple interrupt handler to see when a contact switch hits the ground…
bWhichWKP var byte
Handle_WKP0:
bWhichWKP = 0
disable WKPINT_0
goto Handle_WKP
Handle_WKP1:
bWhichWKP = 1
disable WKPINT_1
goto Handle_WKP
Handle_WKP2:
bWhichWKP = 2
disable WKPINT_2
goto Handle_WKP
Handle_WKP3:
bWhichWKP = 3
disable WKPINT_3
goto Handle_WKP
Handle_WKP4:
bWhichWKP = 4
disable WKPINT_4
goto Handle_WKP
Handle_WKP5:
bWhichWKP = 5
disable WKPINT_5
Handle_WKP:
; simple one for now…
; serout cSSC_OUT, cSSC_BAUD, [0xA2] ; Tell the SSC to stop all servos - Requires special SSC firmware
serout s_out, i9600, "WKP: Contact Made ", dec bWhichWKP, 13];
sound P9, [50\3000+bWhichWKP*200]
fIntPending = 0
resume
[/code]
Note: I still had it set up for all of the WKP interrupts but only tested for 0… I got the beeps when I thought I should. So it will be interesting to see if the program I uploaded earlier detects the foot switches properly… I may try moving my switch to the CHR-3 and manually trying it to see. But now off to the bird house…
Kurt
one note. Interrupts are disabled automatically on entry to an interrupt handler. You can manually re-enable them so that other interrupts can pre-empt the currently executing interrupt but you don’t need to disable the interrupt on entry unless you want it to be a one shot only.
Just a note to say, I made the foot pressure sensors to do the simple task of providing a variable voltage depending on the amount of force that was applied. This works well and has many uses for a walking robot beyond the elusive terrain adopting walking. Just because no one has posted about their success in a project doesn’t mean they will not work. 
The major problem with these switches is the lack of any method of putting something substantial between the tip of the foot and the ground. The switch by itself will only work on a hard flat smooth surface. It will not work in sand, dirt, or rocks. It also does not have the ability to actuate in any position other than straight up and down. There needs to be a foot that can take the stresses of the weight of the body and the rotation that happen on the end of the foot. I actually have an injection molded foot tip that was supposed to address some of these issues, but we could never make it support the weight without doing so through the switch itself. The snap switches are inexpensive as well. You just have to build an assembly to handle the weight and only allow a portion of the weight to contact the switch.
Thanks Nathan,
Yep I want them to be one shot. That is when the foot comes down I only want it to trigger once (in case of bounce and the like) and only reactivate when a leg is up and starting to come down…
Thanks again
Kurt
P.S - All of the simple code I have is currently throw away, will probably use ASM version, although not sure yet especially if we are going to send out a byte of serial data. It may depend on what we do once we know the leg hit the ground.