As for QTC, David Greenberg pointed out to me a while ago that those little black foam pads that chips are distributed on exhibit precisely that behavior. I promptly checked it out for myself and sure enough, pressing pieces of it between metal plates shows a nice steady decrease in resistance. The downside with both of these things is the physical size of it while uncompressed. The FSRs use essentially the same exact tech, but do it with a very thin flim instead of a thick foam. I tried trimming the foam down to various sizes and thickness and could get them quite small still showing good response, but no where near the size of the FSR film. There are some suppliers of a resistive rubber of a similar sort as well.
Nice board layout Andy, very clean. I just received a dozen FSR’s myself and I am need of a good interface solution. I was wondering if you had a schematic that you were willing to share. Or perhaps a source for one. This fellow roboteer would greatly appreciate your help.
Sure, Flash, I’ll draw one up.
source code in CCS C
I left the VREF+ pin open for a POT to adjust sensitivity if required. Code is using only 8 bits of A/D and I seems to have plenty of sensitivity as it is.
well, I ended up adding that pot after all to get some more sensitivity at the lower end. Data is looking good.
Awesome!!! Thanks Andy.
Hey, I recently designed (and successfully tested) a dual interface board for (2) GP2D12 Sharp IR sensors with schematic and pics if you are interested. Also I’m in the short throws of design and test of a lithium polymer fuel guage/temp monitor board.
Oh yea I also have code for the IR sensor board in PBasic.
If someone’s going to try this, the pins on the FSR don’t fit in those 2 pin bergs we’re all using. Well they fit, but they’re not snug. I soldered on some PCB pins and it solved the issue nicely.
Just throwing this out there…
Have you guys thought of using sensors on the underside of your hex’s instead of on the feet themselves?
One notable bot that uses this is iRobot’s Genghis II:
pbs.org/wgbh/nova/robots/clips/genghis.html
I hadn’t considered that, it’s certainly an interesting idea. It solves a different set of problems than I am to at the moment however. I’m planning on tackling the uneven terrain issue and need to be able to step and determine when ground contact is made. I’ll then use the body position to determine the bots orientation to an approximate ground plane.
But, if you’re going up an incline, won’t it register the back feet as encountering more pressure than the front feet?
So, your hex would correct by raising the back legs even farther than necessary, and either have the butt hit the ground, or simply flip end over end down the hill.
How are you going to fix those types of things?
Solved by having the rear legs angle the Feet further aft to avoid tumbling over. Would that not solve this issue?
This would have to be a sub-routine programmed to the controller. If the rear sensors indicate greater pressure than the front by a predetermined amount, tell the rear servos the appropiate action of pitching the feet aft as well as the rear legs up to maintain horizontal of the robots platform.
Something similiar is used in aerospace as a pitch indicator, works very simple, a small weighted arm translates horizontal (constant) in reference to the aircrafts actual and tells the flight computor adjust flight controls to keep airframe at level. A very simplistic explaination of how auto pilot keeps the aircraft level.
Instead of using pressure sensors in the feet as the robot would, the weighted arm operates using a small potentiometer.
You might could even try something like that on your bot.
Tinman
At the moment, I’m trying to go down the PCT road. Today I’m working on creating the 6 perceptions in the Archy simulator (Height, Forwards, Right, Heading, Pitch, and Roll) for handling by hierarchically connected PIDs.
Kenneway found that the only way for Archy to climb a significant incline was for the body to be oriented approximately to the ground, rather than to gravity. Taking that cue, I’m doing the same by calculating Pitch and Roll of the deck relative to a best fit plane of the feet. The relative pressure of the feet in this model (at least for the moment) is irrelevant and I’ll be checking those values against a threshold only to determine if the foot is on the ground or in the air.
So in terms of writing algorithms to deal with things such as balance, well that’s sort of the antithesis of the PCT approach. I plan to give it the relevant orientation perceptions and then some means of decreasing error from it’s refrences.
I thought of using an inclinometer not unlike the pitch device tinman1 alluded to. Then I came across this little jewel
parallax.com/detail.asp?product_id=28017
I have used it sccessfully on a couple of bots.
I am also playing with the FSR method of sensing contact with the ground. I came some micro pressure switches that fit nicely inside the rubber boots on the hexapod legs. I have a few extras if someone is interested. All I ask is pay s/h.
Spark Fun has a lot of accelerometers, gyros, and magnetometers worth taking a look at. I’ve got one, but I’m going to work on aligning with the ground, not gravity first.
Forgive me, I forget you gentlemen are more savvy than the folks I am used to conversing with. 
Flashburns, you are correct, this is exactly what I was describing, a inclinometer.
I think that the position of the bots frame in relation to the ground would provide optimal traction, but gravity could not be discounted.
Think of it as if you where crawling on all fours up hill, the force of gravity pressing down on (in this case back legs) would lend the vehicle to better traction. although the issue of orientation to the surface would most certainly play into the equation the downward force of gravity would play a greater role I would think.
Tinman
I have one of these coming (its backorder). Its kinda of pricy but it is a 3-axis doodad. i’ll let you know.
Andy I’m getting into PCT myself and the references that I’m establishing are based on as many sensory inputs that I can provide. Then I intend to develop various error detecion/recovery methods to enhance the bots perception of its environment. I would be very interested to hear of any insights that you come across along the way. I will do same same if you like.
Oops was so excited about PCT that I forgot the link to the 3-Axis doodad
freescale.com/webapp/sps/sit … 6911184209
Flash, sure!
I just finished all 6 perceptions (I HATE 3d geometry!), time to code up the PIDs. With any luck I’ll have something to report by the end of the day!
Cool deal Andy.
Hey I was wondering what microcontroller you chose for your PCT enabled bot brain. I’m playing around with an Atmel ATMega128 and an ARM7 running at 21Mips and 60Mips respectively. Just felt like the more processor bandwidth the better. Your thoughts?
I’m running over a radio so I’ve got all the processing power I can throw at it. 