Lol.
Thanks, having some fun.
Have not made as much progress on this lately… Been busy with other things as well. Started merging back in some of the changes I made on the Venom Quad code back into our Phoenix Arduino code base. I uploaded my latest WIP to my Quad fork of the code. Some of the changes are currently completely experiments that have not been integrated in yet. Like defining a Gait Class. Would like to get it to a point where specific robots can pass in their own classes… Not there yet, but has one bogus instance of a class in the code to get it to compile…
Also I ripped out the Balance shift table as this is not the approach will be using. Started adding in the Dynamic Shifting code. Currently it tries to only add those legs I think are on the ground to the balance… Still need to handle some other issues, like knowing when it is not walking and probably zeroing out other balance values… Currently turns quad into pretzel when I turn it on 
Also I made some random changes in Gait engine that were unnecessary, but helped me understand what was going on and maybe sped up/code size differences. That was, there were quite a few place where the code would:
GaitStep==GaitLegNr[GaitCurrentLegNr])
Often with checking ± 1 or 2…
So I created a variable: int LegIndex = GaitStep-GaitLegNr[GaitCurrentLegNr];
So the code simply needed to check Legindex versus values like 0, +1, -1, +2, -2… Thought also about changing the code to be more like Orion code and have all gaits to start to move leg up on 0, that way you don’t have to check for StepsInGait-, but decided that while it made several parts simpler, the half height code added complications which probably made it a wash…
As I said this is all very much WIP but did upload current changes to the Guad fork of my github code…
Also experimenting with where should the legs be on the Lynxmotion quad as one axis is longer than other. Currently experimenting with 45 degrees, but still have the zero points with legs servo zero points with left and right legs parallel with each other…
Leg me know if anyone is interested with progress on WIP…
Kurt
Kurt,
Is the progress on WIP progress? 
Orion code (and all this code?) is in C?
3DOF per leg, or have you figured out a way to add a 4th DOF?
Alan KM6VV
Yep - At least I hope it is progress…
Orion Code - A Mix - The code on the DaVinci is Arduino ©. The code on the Orion Shield is standard Arc32 like code. The underlying compiler has added support for example for their servos to be able to get feedback informatoin.
I have not worked on 4DOF stuff yet, except that the underlying code base uses them the same way that it always has.
Kurt
So are you saying you can combine the code bases? ARC32 basic or C?
Alan KM6VV
What I am saying that there are two processors involved and how much of the work goes on one processor and how much goes on the other is sort of up to you. Nathan’s main code base defined an interface between the two processors using SPI(Arduino) and 2nd Usart on Orion. He has defined an Arduino library to allow you to call off to code on the Orion. When I first started experimenting with these, I used a set on on my CHR-3 (the one that had it’s parts stollen for the Lynxmotion Quad… I wrote a Phoenix Servo Driver using the Orion (code up on github). In this version I used the Orion like an SSC-32, where I simply used the Orion.SetAngle(pin number, angle), where angle is in 10ths of degree… I used other calls to tell the Orion how long the move should take and then to Execute it.
Nathan’s current code base, still has a lot of the code base still on the Arduino, including inputs like pS2, Gait Engine and the like, but then passes the data for a leg (like it was a 3dof ARM) to the Orion, where the IK code is run and servos are handled.
There is also the idea/potential to move all of the Gait engine as well into the ORION code. Also potentially one could potentially start off with our Arc32 version of the code base and run almost all of it on the Orion, with maybe defining the interface to have the Orion tell the Arduino to do a few things or for a few inputs (buttons, LEDS, the 8 IO pins…).
So it will be interesting to see where we will normally drop the line.
Kurt
Yes, you do have a lot of options. Hard even to keep up with. I’ve got two 4DOF quads needing new processors that I could port to. But I don’t know when I’ll get back to them.
I’ve got a RoboMagellan to get working…
Alan KM6VV
Still busy here, with first pass at making my quad walk well…
I have been playing around trying to figure out ways to calculate values to dynamically balance the Quads. So far I have started off by trying to calculate the average of the legs that are on the ground. That is in the BalCalcOneLeg function I check to see if the GaitPosY is >= 0 before I add the values to the TotalTrans(xyz) values… Then in the BalanceBody function I divide the totals by the number of legs that are on the ground. I have debug stuff in the code where I can turn on debug output during this. My Gait so far is:
//Wave 16 steps - Clockwise...
GaitLegNr[cRF] = 1;
GaitLegNr[cRR] = 5;
GaitLegNr[cLR] = 9;
GaitLegNr[cLF] = 13;
NrLiftedPos = 3;
FrontDownPos = 2;
LiftDivFactor = 2;
HalfLiftHeigth = 3;
TLDivFactor = 12;
StepsInGait = 16;
NomGaitSpeed = DEFAULT_GAIT_SPEED;
With this, I only have one GaitStep where I have all legs on the ground before I start lifting the next leg. May need to increase this to 2 or 3…
Currently by averages print out values, that Compute to the X,Z offsets are:
RF – (46, 47) (42, 52) (38, 57)
All down (2,-1)
RR – (46, -59) (42, -54) (38, -49)
All down (2, -1)
LR – (-34, -59), (-38, -54)(-42, -49)
All down (2, -1)
LF – (-34, 47), (-38, 52), (-42, 57)
All down (2, -1)
Repeat…
Where the center value of the groups of 3 sets is the numbers is the GaitStep value where the leg is full up. I don’t think these raw values will work. That is especially with the positions where all legs are on the ground. Instead the leg that just went down should have some influence as well as the leg that is about to go up… Will add this in next. Also not sure if I will need to scale these factors and/or potentially offset them by N degrees…
That is all for now.
Kurt
Hi Kurt,
Looking at some other quads I would suggest to change the order in the gait to RR, RF, LR, LF. Like Xan suggested one time, making the starting leg dynamic depending on what direction you are walking is a good idea. Always start with the leg that are rear or oposite to the direction you are walking.
Thanks Kåre,
Will try changing to that. Also will change back to 24 step gait. I am also may try some other hacks to see if it helps or not. That is currently my code says a leg is off the ground so don’t count it. But that also implies that with NrLiftedPos=3, we will have 3 GaitSteps where all 4 legs are on the ground before the next leg starts to lift. I am thinking that maybe playing with adding partial percentages of a leg as it goes through a step to the next leg. Maybe something like, assume N is the position where the leg is full up, so maybe something like:
N-3(2/3), N-2(1/3), N-1 (0), N (0), N+1 (1/3), N+2(2/3), N+3(3/3)…
Maybe over fewer or more steps… Will at least be fun to experiment with. First pass will probably be complete hack, that is have a WORD per LegStep with a Nibble per leg of percentage… Could calculate, but this would be easy. Will need to take into account that we already incremented GaitStep so will look like off by 1…
The reason for the above, is that without it, it will shift body away from leg moving, then move back to center, then move to next leg, but for example on steps where we are going from RR to RF or LR to LF, you may not want to go to center but continue to lean to one side or the other…
Hopefully will have time today to see if this works or not.
Kurt
I made the changes to the Gait mentioned above. So far I have not changed to weight how much each leg contributes to the balance stuff per step, but still using if the leg is on the ground, it adds, else not…
Here is a real poor quality video showing it. The first part is without the balance code turned on, the 2nd part is after I hit Square button to tun on…
I will also update my Github with this stuff before I add in changes to weight and maybe figure out how to start with the right leg…
Kurt
Thanks for sharing Kurt! Well, it certainly keep the COG inside the tripod. Like you mentioned, what to do when all legs are down, maybe just keep the previous cog shift or move to a middle pos.
Anyway,it looks like your having fun. Looking forward to join this challenge.
Thanks Kåre,
Yep having some fun. I did a little more playing around today, where I compute a percentage each leg should be used in balance per Gaitstep. So can play around with this, like the GaitStep before a leg starts to lift, say to use the position by only 50%…
Also added the ability with Debut terminal to set how much we should use our balance X, Z (default 100%). So we can experiment.
Ripped out some earlier debug stuff like trying to use buttons on botboarduino to step one gaitstep…
And a few unnecessary changes, Like remove LastLeg variable…
My Gaithub Quad branch has been updated.
Kurt
P.S. - Wish you could play too 
Another quick update: Github updated.
First pass at when not walking and get initial movement request, try to setup GaitStep such that the appropriate leg starts the motion. Also hacked in another debug command that allows me to play with the Gait. So I can do something like: G 16
to try a 16 step gait… Or: G 24 5
That goes 24 steps with 5 leg up…
Or something like: G 24 3 3 9 15 21
To set 24 step gait, 3 up, RR=3, RF=9, LR=15, LF= 21 (not the actual values but the value in the gait array…)
Next may be to add few more things I can set here, and maybe have it write these values out to EEPROM, so I can then try it without cables and the like…
Kurt
Hi Guys,
Kurt I hope I’m not hacking your thread here but I want to post my findings from the last couple of weeks and start some discussion.
My idea is/was to use the translation from Kåre’s balance sub. except that the lift who is in the air, is extracted from the equation. This way the body, and COG will be placed within the 3 supporting legs. I added a divider to decrease body movement. So this is what I made: Once the leg makes a touchdown I figure out which leg will be lifted next. This leg is excluded from the balance calculations. Then the body will shift to the “safe zone”, calculated by the balance calculations. This shifting is done as long as all 4 feed are on the ground. If this is just one gaitstep, it will go really quick. If there are a couple of steps between the lifts, it will go slowly.
I found that this looks kinda silly. When moving in a straight line forwards the body shifts sideways and also forwards/backwards. Especially the forwards/backwards movements look silly. Since the bod is kinda standing still and then moving forwards really fast. So what I did is add a function that only allows body movements which is perpendicular to the walking direction. This seems to work (a bit) but results in really ugly square movements.
I’m thinking of leaving this idea for what it is now and try to go back to a simple circle. But I would like to start a discussion on what is the best way to go for a quad.
After doing some playing with the quad I also think that a square/fully symmetrical body will result in better movements.
I’ve included a zip with my WIP files. Feel free to look them over or try them out.
Xan
QUAD WIP.zip (149 KB)
Hi Xan,
You are not Hijacking the thread, this is the purpose for the thread!
I have taken a look at the code and it looks like a lot is similar to my C version. I detected which leg was up differently (by detecting when Y < 0). Will try making the same changes you made after that and see if it helps. I agree that it will be interesting to try different motions as you mentioned…
I agree with you that a more symmetrical body would probably be better. So I will also go back to making similar changes to the Orion code base s that body is symmetrical.
Kurt
Xan, Kurt,
The idea of Dropping the next leg out if the equations seems a very logical way to solve that, but as you say it seems to have problems.
I totally agree that a symmetrical body witn a circular shift is best. Although saying this I managed to get the shift table to work, while having an irregular body shape. And I know the gait seemed to struggle on the first step after a change of direction, I did work.
Doing away with the shift table and solving it with math is really the only true way to do it.
I do have 12x spare 645mg servos sitting in a box on my desk… I would join you in this QuadQuest but I sold all my SES. Lol
Maybe after I have completed the 4 projects im currently tied too, then ill print off some parts and also get some designs to Eric to cut me some g10 plates.
Good luck with your findings. 
Xan,
Might be nice to see a video of how it works. I’m interested for one of my Quads.
Maybe add an IMU?
Alan KM6VV
Hi Guys,
Thanks for the quick reply. I kinda feel like a mole leaving and returning home in the dark. That’s why I didn’t shoot a video yet. I’ll try to shoot one this weekend.
On a touchdown the next COG position is calculated. The body (slowly) moves to that position and stays there until the next touchdown. This results in pretty static movements. The body only shifts to the next position when all legs are on the ground.
When using a circular movement the body keeps shifting. It moves quickly at the start and slowly keeps moving in kind of an overshoot before it turns back. I think this will result in a more natural movement.
It indeed would be cool to try different approaches.
@Jonny:
The first step of the gait is always a problem since the COG is not in place yet. So I want to build in a safe method which makes sure the leg which is about to be lifted, is not supporting the weight. Can be done with math. This way the gait just starts one leg later.
I’m also thinking of making the “start” leg dynamic. I mentioned that starting to walk with one of the back legs gives a better result. This since the body (read COG) is automatically moving away from that leg.
Would be cool if you could also join the Quad Madness
@Alan: I don’t think an IMU would be of any help here. With the IMU I could “see” that the bot is falling. Personally I think this is to late. It’s better to plan the steps and prevent the bot from falling. It would be cool to do something with an IMU and a more dynamic/balancing gait. But that’s for the future
Thanks for the feedback guys!
Xan
Hi Guys,
I try to keep my Quad fork of the Arduino_Phoenix_parts: up to date with my latest hacks. I will try to update the readme up there to show easier how to install the code. Probably needed as several different people are installing it (mainly the Main branch) up on Trossen for the PhantomX… The code is mainly set up to have all of the folders in this project be in the Arduino Libraries area. On my machine for me that is in the directory: C:\Users\Kurt\Documents\Arduino\Libraries where my sketchbook is in: C:\Users\Kurt\Documents\Arduino. More of the history of why most if not all of the code is in header files is in the thread(viewtopic.php?f=8&t=8187)
The main code is in the Phoenix directory, where Phoenix.h contains the main header stuff and Phoenix_Code.h is the main code for most stuff, like Phoenix_Core.bas is in the Bap code base.
I was playing around with some similar stuff done slightly differently… I will try to explain what/where/why I changed code. This includes:
When the robot starts walking it tries to guess the best foot to start. This is done in GaitSeq. It looks to see that it was not walking and it has a TravelRequest. It then tries to guess an appropriate GaitStep that is just before the leg farthest from the direction…
Then GaitSeq calls Gait for each leg. In here I filled in an array of how much each leg should contribute to the balance calculation. If the leg was up: 0, but not sure if all ups should be 0, that is if the leg is up for NrLiftedPos==3, should the leg still be zero on the half back down or should it start to contribute… When the leg is in the down position (Move Body Forward) it sees if the leg is about to lift and starts to remove the leg depending on how close in the motion it is.
In BalCalcOneLeg, assuming I am in balance mode, I add the values for the leg times my contribution value I mentioned above.
In BalanceBody, I use the sum of the percentages to divide by… Also in here I have a debug value I use to say how much of the calculated values to use. That is 100% looked like it was more than needed…
In TerminalMonitor and called functions I added a couple of debug commands. Note: Terminal monitor is only called when the Robot is not ON…
B : allows you to change the percentage of how much to use: like B 50
G ST NL RR RF LR LF: Is setup for me to experiment with the gait. That is currently using a 24 step gait. Does this work better than a 20 step gait? To try could simply type:
G 20
NL is the number lifted <default 3>
The next 4 are the GaitSteps for the 4 legs (if you set one, you need to set all).
Again these values are simply set in the Gait variables, so if you press something to change gait, or reset, or powercycle… Gone. May play with saving values to EEPROM…
That is all I have currently done. Will look into your changes to limit directions of which directions are used.
Kurt