Ground Contact Switch "Next steps"

Hi Kurt,

I just send yah a PM.

Hope it’s ok to jump in…

A bit more info about the walking part in 2.0. Maybe it’s all clear but just to be sure :wink:
When walking, the GaitEngine finds a new position in space where it wants to place the leg. The LegIK finds the needed servo angles to get the leg on the given point in space. With balance mode on, the body will keep in reference to all 6 legs at all time. Meaning that if one leg sticks out, the body will move a bit to that leg so it will be in the middle again. Also, if one leg goes up, the body goes up as well. This part is crucial to get TA to work.

For walking over small objects it will work to ONLY do FK for the legs and keep the balance mode off. This will not work for higher objects since the body position is reference is to the ground. If the object (or range of objects) will get higher then the body the bot will run in to problems. If the balance mode is on the body position is referred to all 6 legs. So if the legs are placed higher, the body will be places higher.

In the current code (2.0) the sub BodyIK handles the balance mode. But unlike the title of the sub says, the calculation is a global rotation matrix and not Inverse Kinematics. Actually, it is closer to FK. :unamused:

To get TA to work you need 2 extra parts of math. LegFK and BodyIK (Real IK this time :wink:)
How it should work:

  1. Drive the leg down to a given position (even can be in an angle)
  2. Once the TA switch is hit, stop all servos
  3. Query all positions from the SSC.
  4. Do FK for 3 outer legs which where on the ground during this step.
  5. Do body IK for from those 3 legs to the centerpoint of the body
  6. Do body IK for the 3 other legs (one or all of these legs where going down) This will give yah the XYZ position of the coxa.
  7. Those XYZ positions will be the starting point for to do FK from the body to the tars of the other 3 legs. This will give the XYZ position of where the leg stopped on the object.

In my tests I used this LegFK sub:

[code];--------------------------------------------------------------------
;[LEG FK] Calculates the position of the Tars corresponding to the given angles
LegFKLegNr var nib
LegFK [LegFKLegNr]

;Coxa angle
Gosub GetSinCos[CoxaAngle1(LegFKLegNr)-cCoxaAngle1(LegFKLegNr)]
FKSinC4 = Sin4
FKCosC4 = Cos4

;Femur angle
Gosub GetSinCos-FemurAngle1(LegFKLegNr)+900]
FKSinF4 = Sin4
FKCosF4 = Cos4

;Tibia angle
;Gosub GetSinCos(-FemurAngle1(LegFKLegNr)+900) + (TibiaAngle1(LegFKLegNr)-900)]
Gosub GetSinCos-FemurAngle1(LegFKLegNr) + TibiaAngle1(LegFKLegNr)]
FKSinT4 = Sin4
FKCosT4 = Cos4

;Distance between coxa and tars
FKSW2 = cCoxaLength + (FKSinF4cFemurLength + FKSinT4cTibiaLength)/c4DEC

;Position of the tars
FKFeetPosX = FKCosC4FKSW2/c4DEC
FKFeetPosY = (FKCosF4
cFemurLength + FKCosT4cTibiaLength)/c4DEC
FKFeetPosZ = FKSinC4
FKSW2/c4DEC

return
;--------------------------------------------------------------------[/code]
It is the inverse translation of the legIK sub. If I remember it correctly, this sub has some minor “round off?” errors. But I doubt it will matter with the given play in the servos.

This should give you the possibility to walk over small objects with balance mode off.

Now, to walk over larger objects you will need the balance mode. Step 3 gives 3 XYZ positions for the 3 coxas from the legs which where on the ground (known reference positions)
This will give a plain in 3D space. to get from those 3 coxa positions to the unknown 3 coxa positions we’ll need to do body IK. Since the body has a 3DOF rotation the best way to go is with a rotation matrix. To get a more precise function I’m rewriting the FK sub to a matrix version using the David Hartenberg method. This way I can include the body rotation in the leg FK so this will leave us with just one formula. Which will be easier to implement and more precise then the current method.

The David Hartenberg method is explained in the book “Applied Robotics” in chapter 5. Some additional information can be found on this wiki page

Other then the IK/FK we used in the code, this method uses global and local coordinate system. This makes it to flip the XYZ orientation. This makes it a bit hard to follow. Once this is done we can add the IK translation matrix for a spherical joint from Chapter 6.

Have you got this book? This would make it much easier to explain.

Hope this helps. Or maybe you’re thinking -> what is this guy talking about??? :open_mouth:

Xan

Thanks Xan,

I will read over this a few (hundred) times. I appreciate this. Yes I do have the book, although it hurts my head as I have forgotten so much math. When I graduated with my BS in Computer Science (Carter was president) I also received a math minor and was only 3 classes away from a dual major and now I find it hard to do simple trig :laughing:

Need to figure out what I will do next to gain program space(strip down code or go to Arc32 (or the Bap40 I have sitting in a Lab board…)

Thanks again
Kurt

Denavit-Hartenberg Parameters? That’s an impressive undertaking for a hobby robot!

I’m anxious to see what you develop. Hopefully, we’ll be able to follow all the transforms!

Alan KM6VV

great to see you are making progress, well done. you may have already done the obvious and striped out most of the gaits down to just one. i know these really dont take up much space but maybe also taking out some of the control function etc might help. would be good to see this on the Bap28. i will certainly benefit. When i first took on the idea of adding TA to a robot i never imagined just how much math/code was needed. even with all things considered!

i agree about the functionality of the switches when it comes to making contact. sometimes they dont suppress as well as the next or they just need more force than others. i believe this is all down to the assembly. Well saying that, i was using the 1.5 tubes so not much room for movement of wire. i think they would work best with longer tubes? 3"+. although saying that i did have to modify some of the springs!

good luck with everything Kurt i hope it works out for you. :wink:

Thanks Jonny,

So far I have gone to the other approach. That is, I converted this code to run on the Arc32 that I had on my desk and I was using for testing things out. This is different than the first port to the Arc32 in that I am still using the SSC-32. The upside of going to the Arc32 was that It gains me anther 25K or so of code space. Also I converted all of the serout to S_OUT to use hserout so debug is easier. I think I have the CHR-3 now working again with this configuration. Only my own hardware assisted serial functions appear to have some problems at the baud rate at 115200. Currently running at 38400. Will work on that later… May simply go back to standard serout and save some space and them maybe later go back to Bap28…

I have found that the switches don’t always trigger as well, This is more noticeable as I can watch the LEDS on the wires. Maybe more weight, but My CHR-3 already has a 6v 2800mah battery for servos and a 6v 1600mah battery for logic. May also work better on hard floor instead of carpet will experiment more later.

Kurt

yes carpet would be an obvious reason for this also. i have only tested them on a hard surface and even then they act like this. that was one of the main reasons for making the springs looser so they don’t need as much force to suppress the switch.

the design is great but sometimes the function lets them down. again i think its all down to the wires either rubbing on the inside of the tube or catching on the hub.

Maybe a little 3 in 1 oil, may help keep things moving freely?

The only thing in the switch that would cause this, is if the wire connected to the plunger is adding mechanical friction to the assembly. If the wire is too long, or too thick, or bent the wrong way, etc. The pressure required to fully press the plunger against the spring should be very low. I think I was able to get the force down to 3 ounces.

yes as i said the design is faultless. its all in the wire assembly. :wink: user error. :unamused:

Well if I had designed it properly it wouldn’t require any of this “fine tuning”! lol

Let me know if you’ve got some questions. I can always see if I already figured them out. But since I’m still working on this (pretty much for the last few weeks) I don’t have all the answers. :wink:

LOL, you know, just 4 months after Carter retired I was born. And still it took me some time to figure out the math. :stuck_out_tongue:

Damn, this kinda worries me. Is your (XBEE) version much bigger then my original 2.0 version?

I thought you should know that I’m always trying to bring hobby robotics to the next level :smiley:

Xan

Thanks Xan,

I have been playing around with the side issues of this first. Like trying to get the WKP interrupt handler working OK. Will get back to the main/Math stuff soon.

Code size: The newer XBEE stuff may be a little larger, but some can be stripped out. For example can strip out all of the feedback information. In addition to this, the code was using my own implementations of Serin/Serout that can be stripped out. I was using them as I could get the code to drive the SSC-32 at 115200 instead of 38400. Will probably go back to that at some point, but like debugging using the Arc32(or Bap40) as the having the hardware serial port for debug output is nice.

On a differnt part of this work, I am thinking about maybe adding something below the lower deck of the CHR-3, such that the bottom does not go all of the way to the ground, That will make it easier to setup the initial leg positions to be more directly under the body such that we can get straight up and down for the legs which should help my reliability of the switch contacts.

Kurt

Hi Kurt,

Good to hear you can clean up some unused stuff in your code. It’s been a while that I spend my robotic time programming rather then sitting with my nose in the math book. I could be wrong but I thought I had the trigger part already working in the hybrid. Are you improving the trigger part?

I don’t totally get your point with adding stuff under your lower deck but I have to apologize for not reading through this whole topic about your ground sensors. I’m using the switches Jim made for the Hybrid. They simply work brilliant!

I just finished the FK formula using Denavit Hartenberg Translation. The full leg is simulated in SciLab and works like a charm. I will move up to IK of the body which will be something like a triangular plane. More on that when I made some progress.

Xan

Maybe I should take another look at that design. :stuck_out_tongue: Maybe I can do it with PVC, now that I have a place to laser it.

any excuse to use it hay jim. lol.

Could be fun. I do like the look of those type of legs…

Xan - I probably should look at the code you guys have for the hybrid… Right now I am just experimenting. I should look to see where that code is in which thread…

Right Now I am just trying to figure out the values being returned to me by the SSC-32. That is during my WKP interrupt handler, I output to the
SSC-32 a <0xA2> Which should tell the SSC-32 to stop all servos.
I then tried a QP command: I output QP1QP2 and was returned: A6 98 which I know needs to be multiplied by 10 which give me the value
1660 and 1520

I then tried the binary version of the command: I output 0xB6 0 0 0 0 which is the binary query for pins 1 and 2. The values returned are:
06 A7 06 02 which converted to decimal: 1703 and 1538.
My guess is that one of these two approaches did not take the servo offsets (SSC-32 registers 32-63) into account as I had my program print these values and for servos 1 and 2 the values are: 39 and 16.

Back to figuring it out. I wonder if by chance the fact that I have output a complete new binary command for the next position minus the time will cause it any problems…

Kurt

I forgot to mention in the previous post why I think it might help to maybe put a deck below the bottom deck… The following picture shows the closest I can get the current legs to the body when the body is on the ground.CHR3-leg-body-on-ground.jpg
With this configuration, the initial position for the robot needs to be at least that far out, which leaves the legs a little splayed. Alternative is to setup the legs such that are under the robot, but this makes it very possible that the 645 servos may not have the power to make it stand up properly.

If however I put something like a battery pack under the robot as seen in the following picture:CHR3-leg-body-up-battery-he.jpg
The leg can be easily positioned closer to the body which may make it more likely to have the legs be vertical. There are probably other ways to do this as well…

On the foot sensors, I think I may try rewiring them again. Currently I am using the smallest stranded wire that Radioshack had… I think it is a 20 gage, which is still pretty stiff. I am thinking of using a single strand off of a ribbon cable which is very flimsy and should give a lot less friction.

Kurt

Have you thought about changing the outside short “C” brackets to the offset version? This should get the foot much closer to under the servo.

I was thinking about that as that looked like it might help out! I just don’t have any… Sounds like time for another order…

Kurt

Let me know when you place this order. I will donate them, and a black aluminum chassis for that bot. 8)