New take on an old problem... Ground contact!

The tactile switches I suggest are just for mechanical leg testing and code development. People have been sitting idle for 2+ years waiting on the perfect foot switch which may/may not ever appear at a reasonable cost. The tactile switches may provide a quick and inexpensive way to start dealing with design issues that can’t be addressed without a working test bed. The FRS and first mechanical switch designs appear to have bee abandoned for this project for what ever reason, so the tactile switches haven’t actually been shown to be any better/worse than these designs (except for time and $$$ spent). As to issues such as sand, dirt, or rocks, I rarely see hexipods of any type being operated in this type of environment except for one off filming. As to strength, I can quickly and easily attach a tactile switch to the bottom of a hexapod foot using removable hot glue that will still be in place long after the leg bends and fails (assuming a servo could actually ever generate that much force). I’m not knocking what has been so far, I’m just saying simple test setups can be developed to allow development and testing of working walking code and such while the ultimate foot switch is still being developed. Idle time is generally lost and not recoverable.

Thanks for posting your resent findings. Very interesting responses. I had similar problems using the FSR switches. Contact could only be made when vertical movements are performed. This opens the door for more compatible and complex designs. As we only have one point of contact per foot, it can mean more change of detection error, so maybe a redesign so that the foot displays in a more spread out way. MattDenton used a triangle design so that each foot had its own ‘tripod’ to make contact. Then the switch has 3 sensors per foot to activate. I think the main issue with sand etc, is surface area vs force. Maybe use a larger surface area like a moon landers foot, or disc like application.

Zoomcat, The tactile switches will not work, even for testing, due to not being able to actuate them at any angle other than straight up and down. They offer no traction leaving the hexapod with a Bambi on ice scenario. I fail to see how this would aid in any useful way. You seem to be focused on the fact that 2 years have gone by since we made the first foot sensor. The fact that no terrain adopting behavior has been published as a project. The fact is it’s not easy, and as I said before, just because there hasn’t been a perfect published solution does not mean the sensors do not work. It only means they are being used in the wrong way. The pressure sensor does exactly what it is intended to do. It provides a variable voltage in proportion to the pressure applied, and at varying angles. They offer the ability to, in software, make sure all the legs are doing the same amount of work when standing still. To detect the ground on the legs walking forward to not walk down stairs. Both of these functions can easily be done with the pressure sensors. Not TA walking, but pretty cool. I have seen TA walking with only simple switches, so I do not see why the pressure sensors could not do the same thing.

A test bed for TA requires fully functional feedback. Sensors that will work reliably at angles approaching 45 degrees. Without that the code can never develop because of potential sensor failure. It’s really a very complex problem to overcome. You need a sensor that can handle a few pounds of load. It needs to be robust handling a fair amount of side loading. It needs to actuate with very little pressure and very little travel. It needs to release reliably with only lifting the leg. This is what is needed to do TA.

The pressure sensor and the first ground contact switch do have finicky setups. I was able to make them work reliably with little effort, but if they are not assembled correctly they can be problematic.

I knew a long time ago the current method would be the best for this, as they do not have any finicky setups. But they will require long laser time to manufacture which will affect the cost. It’s the old, cheap, fast, good, pick two scenario.

Tried to do a footswitch instead on my FSR
viewtopic.php?f=8&t=6958&p=70869#p70869

Hey there. Sorry I’m a bit slow on the updates on this end. Anyway, I’ve tested the new mode in the code you posted. Each leg goes up and down as it should, but the motions don’t stop once the switch is triggered. They will make a beep, but not stop. Looking at your code, I see the line
serout cSSC_OUT, cSSC_BAUD, [0xA2]
Does this mean that I should be using the binary firmware?

Ok. Update:
I used the binary firmware and it works as it should. Except the legs, after stopping, will quickly jump back down to a standing position when the next leg starts to move.

It works!!! Video at 11.

Yep, the single leg mode, when you choose a new leg it restores the previous one back to default position… I used the single leg mode to try it out as I thought it would be the easiest without making more changes to the main robot code…

:slight_smile: 8)

Kurt

Here you go!

Great work with the switches and the test-code. They seem to work perfect! :smiley:

progress! yes. well done.
now put it out side… go on… put it out side. uneven terrain here we come! :laughing: :smiley:

Great work guys!

Can you say anything about the overshoot? The vid shows little or no overshoot but it’s hard to say. Repeating the test without switching to another leg and leaving the leg at his stopped position should tell us more about the overhsoot.

Can’t wait to work on this again! :smiley:

Xan

Yep, me too. The code they are running is a real quick and dirty version that simply cycled through all of the legs. I was thinking of adding another button to the single leg mode that would only do it for the current leg and stop when it hit. That way we will see what is happening with that leg and could maybe play more with speed also. Right now I simply hack the speed variable and set it to some fixed speed. Would be nice to make that variable as well.

But do that now are wait until I have one to test it with?

Kurt

There is no detectable overshoot. Something we can feel, but difficult to see on the video. The shipping department is backed up so we are shipping these Monday. We would be happy to try some more test code but we have to get them boxed up so they are ready to go. Jeroen, you have moved so please send me your new address. :wink:

So since two years ago when we first started working on this we now have; better foot switches, 38.4kbaud increased to 115.2kbaud communications, more efficient binary communication mode, and most importantly two of the best programmers I know coding for them. Lets do this thing!!! :smiling_imp:

I’ll send you a PM.

Don’t forget I spend a lot of time digging trough the Applied Robotics book to get the Math done. :wink: It just have to work! :smiling_imp:

I suggest you write some simple code to move the legs in a tripod fashon, first set of three up, then down. Second set of three up, then down. Repeat in a continuing cycle to see if the bot eventually raises up on it toes due to overshoot, or gadually settles to the ground due to undershoot…

Wouldn’t that require the leg to stop moving before the switch triggered the interrupt. :unamused:

In my tinkering I found tthat a lightly actuated switch will stop the downward motion of the leg before the leg is actually supporting any weight. When other legs are lifted and the bot weight is actually placed on the leg, flex/sag may occurr. YMMV!

Hi Zoomkat,

I’m sorry to say but the tripod gait is the worst gait to start with. When you place just 3 legs on the ground the bot is always self balancing so it is very hard to see if the legs adapt to the ground or the whole hex does.

We going to start with a gait that has 1 leg going down at the time. Wave should be prefect. This way we can perfectly see if the leg stops at the right position.

Xan

Unless the foot switches are malfunctioning, the leg will adapt (stop moving down) when “ground” contact is made. As to the leg relation to the bot overall, you will probably need to do as I previously mentioned and evaluate the overall leg positions to the desired overall leg/bot position to correct overall leg positioning drift. As to weather the bot is walking on level ground or on the side of a hill, you will certainally need additional instrumentation for this determination.

I agree single leg operation is a good learning point for you to start. The the tripod gait should actually be easy to work with for basic testing and actually get the bot moving. As usual, YMMV.

Good Terrain adaption by little dog:

Alan KM6VV