Alright. Saying I know anything about git hub is a huge lie; However, I just set one up correctly… I think… Have a look and let me know if i messed anything up or if i need to do anything.
Dito - to say I know anything about Git hub would be a lie… I have only used (abused) it enough to post a couple of fixes for the PS2 code… That is also true about my knowledge of the other locations like: SourceForge and Google code… I will have to get back up there and see if I can recreate the steps to enlist… Probably someone needs to go through their helper guides and come up with a quick and dirty cheat sheet to say, to enlist do: X, to fork do Y, to push in changes, do…
Thanks
Kurt
Guys,
Totally correct! The PEP can also be very usefull finding good values for the init position. I used the PEP to find good init positions for the T-Hex
Just a note: As you know a 32-bits processor processes it’s instructions with the full 32 bits. Converting variables to 32-bits will add some additional steps and always slows down the calculations. If you have enough memory free to store your variables, it is always better to make your variables match the amount of bits used in the CPU instruction set. But this is easy talking for me, as I develop programs for big massive servers on a daily basis 
Xan
We’re making an announcement on the forum about the github page. We’re hoping that some more knowledgeable users can help us out with this project.
Saw it… Thanks.
One issue so far, is that Arduino wants the main sketch file (xxx.ino) to have the same name as the directory it is contained in. So far example when I open the BotBoardDuino_CHR3_PS2.ino file in the BotBoarduino directory it will complain that the file is not correct and would you like it to create a folder…
Kurt
Hi,
Are you still having the bugs you posted in the video or does it perform ok now?
Yes, while in translate or rotate mode the bot crashes when you increase the body y offset to the max.
I have not see the crash on my CHR-3, but maybe I am not doing what you are doing to reproduce this. Or maybe this is because of the mechanical limits of the CHR-3 that the it can not go up any higher as the tibia parts run into the C-Bracket. Might be different if I used Tall c brackets, but I didn’t…
What we may need is for you to instrument the PS2 code or the like to see what inputs are causing it to crash…
Like maybe right at the end of the PS2 input like where the code is:
//Calculate g_InControlState.BodyPos.y
g_InControlState.BodyPos.y = max(g_BodyYOffset + g_BodyYShift, 0);
Maybe print out some variables… like:
The g_InControlState.BodyPos.x and g_InControlState.BodyPos.y and g_InControlState.BodyPos.z, g_InControlState.BodyRot1.y, maybe also (g_BodyYShift, g_BodyYOffset). Could put this in conditionally and with the ability to turn on and off…
#ifdef DEBUG
if (g_fDebugOutput) {
Serial.print(...)
}
#endif
If you go that route and you have the serial connection, then hit D at debug terminal to turn debug on or off…
If it is only at the extreme values we should probably update the code, that looks like:
[code] if (ps2x.ButtonPressed(PSB_PAD_UP))// D-Up - Button Test
g_BodyYOffset += 10;
if (ps2x.ButtonPressed(PSB_PAD_DOWN))// D-Down - Button Test
g_BodyYOffset -= 10;
[/code]
And maybe add some defines in the …CFG…H file that says something like:
#define MAXBODYYOFFSET xxx ;
And then update the above code to make sure we don’t exceed that maximum… Maybe need for minimum as well???
Kurt
Hi,
I’ve been looking at the files too. The Body Y values seem to be way off the chart here.
EDIT: From the cfg file:
#define CHexInitY 80Must be wrong. Looking at the pictures of AH3-R my guess would be a value of 45 to 50.
Also, setting the g_BodyYOffset = 65; in the PS2_controller file make no sense. It should be 0. Adding 80 + 65 gives a range that the AH3-R never would reach in a normal way.
Kurt,
Your suggestion of making a max/min range for the bodyposY sounds like a good idea.
The value of 80 was a trial and error value I did on my CHR-3 that got the init of the body more or less at the ground… It could be possible that I need to recheck out my legs, like maybe I was supposed to adjust something by a click or two and did not or did and should not…
The 65 was a change the Devon wanted back in May (page 1 of this thread), which I put in. I think they liked the idea that when you initially hit the start button, you are at a height that you can walk at. Personally I like the behavior where it starts at the ground, I hit the triangle to get to my walking height and walk from there…
Yes I do think the Min/Max is a good idea and pretty simple to implement. Would probably put in CFG files, plus #ifdef check in main code to some defaults, like 0 for min…
Kurt
Ok, I see. That explains it.
I’ve been watching the video several times.
I’m wondering, can the feet on the AH3 really reach the initpositions mechanically? Placing the robot with the body on ground and then center the coxa and manually place the foot on the ground and as close to the body as possible. Doing that, whats the horizontal distance from center foot to the center femur servo horn?
I don’t have an AH3, but a CH3… But doing the measurement on it, I think that it is about 103 or 104mm…
Kurt
Ok, I guess I should have asked for the horizontal distance between the coxa horn and the foot, I assume that’s the 104mm in your case.
This also explains why the AH3 on the video has problem when lowering the body to ground. In the cfg file the
#define cHexInitXZ 80
Is to short, also the other XZ values need to be adjusted to match this position.
EDIT:
It looks like it would be an idea to introduce some of the code I’ve used on MorpHex. The init positions you probably want for walking doesn’t match the init positions when lowering the body to ground. I’ll see if I can do something with it later.
have to go…
Thanks Zenta,
I do not think this is a new issue. I remember playing with similar issues back with the basic versions. The initial position that best walked did not let it lower completely to the ground. I also remember having to semi preposition the hex to start it up… But it does help refresh my mind on the InitY position stuff… You can see this even in some of the product photos:
Awhile ago when I was working on the 4DOF stuff with my other (main test Th4-R), before I had offset brackets in place, I played around with a 2 position init as the problem was pretty bad there. Not sure if I have any of this anymore… One option would be for me to change some of my C Brackets to either long ones or maybe offset ones, but that would not solve it for the others, unless they did as well…
I might experiment some with my CH3-R and maybe introduce a set of CInitPos(XYZ)2 values, that if some Y (probably g_InControlState.BodyPos.y) is < than some value you use one set of values for LegPosX/y/Z else you use the main ones… Need to be careful as the BotBoarduino only has 30K of code space and using maybe 27K on PS2 version… Probably stuff can be trimmed when necessary. May give it a try… But again this is not a new issue…
EDIT: Thinking back what I was playing with was using some FK code to know where the legs servos were and when I pressed or button or something, I would recalculate where I think an ideal position would be for the leg to point straight down… Could do something like this here as well, where as the Body Y changes we recompute a LegPosXYZ to work with it. With some robots, might imply they can get higher off the ground, but CHR will be limited by other C-bracket…
But we still need to figure out what is going on with the AH3-R back at Lynxmotion with the rotate and translate mode crash. Would help to have the data I mentioned in previous post. If we can find a threshold, we could simply limit it before that point. If it looks like it should not be limited at that point, then we would need to figure out which calculations are probably overflowing and resolve that…
Kurt
Also, I’ve been playing with my CH3-R and the bot crashed in the same ways that the AH3-R does in the video. So that means that the solution to the AH3 crashes would also apply to the CH3-R?
Actually what I am saying is, there are multiple things going on here in these posts.
-
Crash at the upper end - Need to solve - Need input from you on what values cause it to crash. Will probably solve by simply limiting the values, which we should do anyway…
-
InitialXYZ/BodyXYZ - This is a problem that has been around since the day these round Hex robots were created. The position the feet can be at and have the body touch the ground is not the best location for them to walk… Since this is an old issue, I don’t see this as a show stopper to saying you have a released version of the software… Several ways to address:
a) Punt
b) change hardware
c) Two step init. Init position is such that robot sits down, but when you tell it to go up, it moves the feet in to a 2nd Init position.
d) Dynamic position (either on demand or automatic) - I think Zenta and I have had versions of this. I know his is a lot more refined and developed. There are issues on when to do, how it effects different modes, balance, …
This code is not necessarily any type of robot specific. Some may need it more than others, but for example would be Phoenix benefit of moving it’s feet in or out as the body goes higher or lower?
So again I think 1) has to be solved now. 2) is something we can play at and see where it takes us.
Kurt
Quick update: So far I have not found my old code for repositioning the legs depending on height. I did this quite awhile ago when I was first trying to do some TA work with the CHR-3 with the first style leg contacts, which I was having problems with. At the time I thought I would have better luck if the leg was straight up and down for the contact… Will keep looking.
Devon: have you tried instrumenting the code on the AH3-R there to see where it starts to fail?
Kurt
I haven’t yet no. Been working on updating my program manuals and finishing up code for other bots. I’ll look into it soon.
Hi,
I’ve been playing a little with PEP for simulating the AH3-R. I’m using PosY = 45mm defined as ground level.
At theoretical ideal walking pose when femur = tibia = 0 deg I get a coxa-tars (or InitXZ) value of 86mm. This is simply CoxaLength + FemurLength. And the LegPosY = Tibialength = 124mm, this should give a ground clearance of 79mm. Since the tibia is limited to about -45 deg this gives a maximum leg lift height of 50mm (LegPosY = 74mm), it get worse if the leg is in the walking state and moving towards the coxa. This mean that the body still are almost 30mm above the ground.
The coxa-tars (InitXZ) must be increased to 111mm if we want the body to touch the ground.
As a test you could change these constants in the cfg file to this:
#define cHexInitXZ 111
#define CHexInitXZCos60 56 // COS(60) = .5
#define CHexInitXZSin60 96 // sin(60) = .866
This will not solve the other problems (probably make it a little worse) though. But the Hex should be able to move from the ground position without servo crashes.
The other main problem here is the leg design on the A and CH3-R, the -45 deg limit on the tibia combined with a relative short femur set limits to the body height combined with body rotations or translations. The video also seem to demonstrate this fact.
We are using a code that are optimized for the phoenix leg design, this mean that we probably need to decrease some values or combination of values. Since the PS2 values often jumps the max/mins this bug gets even more visible. Kurt, if you are using the DIY remote you could probably find these values at a more accurate level.
Using a dynamic function for the init positions would be fun to try out one day.