Thing about Mega is it is still an 8 bit 16mhz processor. Does have some nice things like more memory, more IO pins, more USARTS… But question is, do you do baby steps, or take a giant leap? Again have no details on SES V2, Do you continue with RC servos, then having lots of 3 pin headers is real useful. But if you instead go to some other form of servo that uses some form of Serial data (like Robotis, Dangbu (sp), …), then maybe something else would work better.
Actually for the lower end here, I think my two Teensy 3.1 carrier boards work great. Still have the quick startup of Arduinos… Runs at 96mhz 32 bit… Others are going a similar approaches. Like Robotis has releases a low end open source controller using an Arm Cortex M3 (trossenrobotics.com/open-cm-904b) for about $20 Does not have all of the IO pins brought out in 3 pin headers, but again all of your servos can be handled by the couple of serial connectors…
Yep, I do have some cameras with Video. I do from time to time post some poor quality videos to show the status of things.
My rebuild will only use 645mg servos. Nope I don’t have any servo programmers as I don’t have any of the digital servos that need to be reprogrammed. For doing the zeroing, it is easy to do quick and dirty program to tell all servos to go to 1500. Often it is in my Debug Terminal command list.
That’s true, still 8 bits. If the ChipKit had better support, it’s PIC processor might be a good choice. What does your teensy have? I haven’t looked at the Arm Cortex M3, I do have an old Spartan development kit. A lot to keep up with! But with C on them, it’s a much easier path. I have tons of Hitec servos, and a few of the new HV220 servos as well. Probably won’t be buying a huge amount of hardware in the future, I’ve got plenty of stuff to play with. I could machine a chassis for an in-line hexapod, but it’s hardly worth it, unless I make something really custom. I have a few digital servos as well, but they have limited range. Programming them only makes the range smaller (?). Right now, they are on the tilt/pan assemblies I’m working on.
The Teensy 3.1 (pjrc.com/teensy/index.html) is an MK20DX256 32 bit ARM Cortex-M4 clock 72mhz most of the time overclocked to 96mhz, 256K rom, 64K memory ram, 2K EEPROM.
One of the things I like about the 3.1 is that is is a 3.2v processor but all pins that support digital are 5v tolerant. There are a few Analog only pins which only support 3.2v. Versus the 3.0 and the Pic32s and the Arduino Due are also 32 bit, but they are only 3.2v, so you have to be careful on what you hook them up to.
The Teensy 3.1 currently only installs on Arduino 1.0.5 and simply shows up as a new board type. He has worked pretty hard to keep as much compatible as possible. So for example you have a Servo library, which supports a reasonable number of servos. There is still a lot for me to learn here, like all IO pins support interrupts and the like. There are priorities on Interrupt handlers…
Kurt
P.S - Just picked up my package with all of the parts
Yep installs on 1.0.5. His Teensy 2.0s are Atmega and he also has setup for makefiles. I have not tried yet to see if you can get a setup that works that way for 3.1 or not.
Libraries: He has quite a few working. For those that have issues, he tries to work with owners of library to get fixes in, else he hosts updated versions. I made a few tweaks to get the Lynxmotion PS3 V3 to work, which is up in my fork. I have many/most of the Phoenix code base up and running, have not tried to do everything yet, like RC input. My DIY Remote code is with the TFT display is getting there. I am in the process of reworking my protocol. To test the DIY remote update, using my Teensy with the Arduino Shield connectors, with an XBee shield which I have configured to use D0/D1 (Serial1) as well as an Adafruit 1.8" TFT display using Adafruit’s display and graphics library (modified version from PJRC). Also have modified versions of libraries for RoboClaw (both hacked up version done like how Nathan handles Arduino Due as well as what I think is a cleaner version where you pass in a stream object… So as I said a pretty good amount of stuff up and running.
As for building, I probably should have ordered a new 1600mah battery, most of mine don’t hold much of a charge. Not sure if room for 2800mah yet. For sure not enough room for 3600mah LifePO4. Could potentially use Lipo with …
Now trying to decide how much to break down the old legs… These were from my old Spare parts CHR-3… As you can see not all of the parts match
I probably have all of the parts to make all black, but sort of like the mixed look
I like black, but it probably scratches easily. I’m probably going to stick with the brushed aluminum. I have a 2800 mAh battery, it fits quite nicely. I also have an old 1600 mAh battery (lighter), I should see how long it will power it. But I need to get it walking first.
I see the old CH3 legs, I thought at first you were going to use them as-is!
I’m wondering if I can use the build 82b 3DOF ‘A’ legs on an in-line hex (aluminum BH3). The pictures all show old Lexan 3DOF legs. Should work. But I’ve got to get the 'Quad running before I buy parts for a new 'bot.
Any of the legs should work with a hex, may (should) adjust all of the leg parameters…
I have converted two of the legs so far. I have other stuff to get done this morning/afternoon so maybe get back to it later this afternoon.
I remember when I first started working on the quads, I wondered some about these leg designs. Will be interesting to see how these work. Earlier I wondered about modifying the legs some to see if it helps. The idea is to hopefully get all 4 legs squarely on the ground, probably without the body having to be too high up. Things I wondered at the time was, are these 3" tubes the best size to try or maybe something shorter? So at the time Jim sent me some shorter ones as well.
Also wonder if you look how Trossen updated the legs from their V1 to their V2, They added Angles into their brackets/legs. So wonder if C brackets maybe would be better with offset versions on one or both… Not sure how far I will take that part, I don’t think I have enough of those brackets to try it out, without having to break apart something else like my 4DOF (T-Hex legs) Round.
That’s what I was thinking. I know and have worked with the leg parameters on my old hex.
Have fun building!
I have a set of four 4DOF legs, minus some servos. A bit much for early 'quad experiments. But they have the 1.5" aluminum tubes and angle ‘C’ brackets you describe. I was going to use the other parts on a hex, but these parts would be available for experiments.
I’ll see if I can track the Trossen updates you mention. The 4DOF legs should also work on the 'quad as-is.
There is the diagonal symmetry issue. Result is very nice left-right and fore-aft symmetry. Apperantly an improvement over the previous arrangement. The tubes (tibias) of the legs are directly aligned with the center of the coxa, with either hand. Other then servo rotation directions being mirrored, I don’t see any differences. Let me know what you see when you build the 'quad.
One thing the L-R and F-B mirroring does is off-center mass of the coxa servos on the sides of the 'quad, rather then on the ends, which give them slightly better travel. Looks nicer too! Good Engineering!
I have an aluminum 'quad body that I designed and made some time ago. Predates the current 'quad, I think. Four-legged animals (I’m thinking cats and dogs) have a rectangular footprint. A little longer, and slightly wider then the SQ3, (rectangular) but would also be a good platform for experimentation, now that I have a little more time.
I still want a rectangular hex! Can I get a few samples here…?
I think it has to do with the first two reasons, lower CG, more freedom, plus maybe less strain on some servos? Again, I think a lot of the changes were driven by one or more people working on making a better bot for in this case Mechwar. Which I am not really that interested in Mechwar, but the things they needed, like stability, ability to handle adding things like cameras and the like are useable outside of that.
Just got back. probably a few other things to get done here and then maybe build some more.
The T-Hex legs look interesting. I have the 4DOF set made up (except a bunch of 645 servos), maybe I’ll populate with 475’s. I think the 3DOF T-Hex legs would be a good starting choice, after I play around with the stock 3DOF ‘A’ legs.
I have most of the pieces in place now. Although right now it is sitting on a stand, the Teensy board is sitting on the desk with longer Servo extension wire connecting it up to SSC-32… Program is built for SSC-32 and PS2 and it is responding. Since my Teensy board also has XBee on it, trying to decide if I will first debug using it or if I will port some of the Commander additions I did to the PS2 input code. This includes the ability to play with the angles and positions of the legs. I also have my code setup to import the walking gaits of the Pypose version of the PhantomX Quad. It compiles for Botboarduino, but has no debug support turned on (i.e. no Debug terminal)… SQ3_PS2_SSC32-140411a.zip (3.63 KB)
I had a pleasant afternoon rebuilding my 4DOF legs into 3DOF. I copied the symmetry of the legs of the SQ3. I bolted the legs onto my aluminum 'quad chassis so far. I don’t really need a second 'quad, but it’s a quick way to check out the legs while I’m waiting.
Any thoughts on how the T-Rex leg measurements compare? I can measure whatever I want, but the angled ‘C’ bracket could be confusing.
Nope, still sitting on stand. Playing with some other fun stuff!
As for the leg measurements… There are two things.
Length is the length between the two pivots as if it was a straight line between the two.
But you need to figure out the angle to rotate a servo in order to make the line between the two pivots either horizontal or vertical (depending one which DOF). So for example for PhantomX V2, I am still experimenting with values: but it is something like:
With T-Hex there were two ways to do this. One is to remove the center screw for the servo, pull servo horn off of servo, rotate by one click and remount on servo (15 degrees) or like I do with the 4 DOF version I define:
Hope that makes sense. Now back to figuring out what I want to do today.
Edit: Not sure anyone here cares of why the differences in offsets I am experimenting with on PhantomX V2. The 7 degrees and 38 degrees were the values that I measured earlier, but then looking at the Official arbotix code base, I saw in their code (nuke.cpp doIK function), everything is hard coded in servo units. If you look at the femur calculations, they are based off of a logical center point of 524, where center of servo is 512, so a delta of 12 servo units. My calculations or converting that back to an angle gives me: 12*375/128= 35.168 (or about 3.5 degrees) …
[code]//==============================================================================
// Define Gait structure/class - Hopefully allow specific robots to define their
// own gaits and/or define which of the standard ones they want.
//==============================================================================
typedef struct _PhoenixGait {
short NomGaitSpeed; //Nominal speed of the gait
byte StepsInGait; //Number of steps in gait
byte NrLiftedPos; //Number of positions that a single leg is lifted [1-3]
byte FrontDownPos; //Where the leg should be put down to ground
byte LiftDivFactor; //Normaly: 2, when NrLiftedPos=5: 4
byte TLDivFactor; //Number of steps that a leg is on the floor while walking
byte HalfLiftHeight; // How high to lift at halfway up.
#ifdef QUADMODE
// Extra information used in the Quad balance mode
word COGAngleStart1; // COG shifting starting angle
word COGAngleStep1; // COG Angle Steps in degrees
byte COGRadius; // COG Radius; the amount the body shifts
boolean COGCCW; // COG Gait sequence runs counter clock wise #endif
byte GaitLegNr[CNT_LEGS]; //Init position of the leg #ifdef DISPLAY_GAIT_NAMES
PGM_P pszName; // The gait name #endif
}
PHOENIXGAIT;[/code]
I get this in the older version I’m working with in Phoenix_code.h
I’m not following the gait leg number GaitLegNr[cRR], Those aren’t pin numbers, what are they? What construct determines the leg order?
Seems there was a paper on how the gait code worked, but I can’t find my copy. I only remember a little. So many periods of time in a gait cycle. Lift times, down times, something like that.
Good to here the hardware is talking! Will the code fit the BotBoarduino? I’m anxious to get the new code on my board, hopefully with a few tools (servo offset and terminal). Maybe a Mega at some point. I guess I can calibrate first with a LSQuadA build, then switch over.
What exactly are the “Commander additions”? Trossen?
As for gait definitions and how things work. One of the best starting points is to look over Jeroen’s (Xan) write up that he did back for Version 2 (or was it 1…) lynxmotion.com/images/html/proj102.htm
Also I tried to explain it earlier in this thread. Look at posting on April 1st at 6.41am (time may be different)…
Looking at the older code for example
GaitLegNr[cRR] = 5;
GaitLegNr[cRF] = 9;
GaitLegNr[cLR] = 1;
GaitLegNr[cLF] = 13;
the cRR cRF, CLR, cLF are just some defines to make it easier to look at. What controls the order the legs lift is, the values here. (I will simplify a little as it may lift a step before or after…, but should give the idea).
In the above the order of the legs lifint is: LR, RR, RF, LF, LR… As the values in this array is the step number within the gait that a given leg should be lifted. So in the example I just showed, only one leg at a time is lifted… But for example with the Pypose version, the Amble gaits assume good stability and it lifts two legs at a time.
I got that the T-hex legs need to be set up Horz and vert per pix, (forgot about the 15 degrees), that would be the correction that’s needed, and I can put that in w/ offsets, right?
And this value gets added to the stored offset?? What was the reason for the 15 degree offset anyway?
I now have the 3DOF T-Hex legs. Putting them side-to-side with the 3DOF ‘A’ legs, it looks like a simple Horz femur and Vertical tibia would do it. There is an additional vertical component between femur and tibia. Do they need the 15 degrees?
But I’m getting ahead of myself. ‘A’ legs are good enough for now.
I’ll let you get back to it!
Do the Phantom II legs have a vertical (tibia?) and horizontal (fermur) leg elements to align, similar to T-Hex or 3DOF ‘A’ legs?
If you look at the complete T-Hex tutorial: lynxmotion.com/images/html/build172.htm It shows aligning the horizontal/vertical… Once you get those pieces horizontal you don’t need to have any other adjustments (off by 15 degrees or the like). As Math wise it does not care if between points A and B there is some other stuff going on…
As you know 15 degrees is simply the spacing of the splines on the hitec servo. But in this case it may be the angle that the offset bracket used as well.
As for PhantomX legs Math wise yes. The Femur horizontal is from the two servo pivots, which physically is off by the 3.5 or 7 degrees. Likewise the tibia is from the last servo pivot to the top of the foot.
I did a little playing today and have it now building with Commander for input. Also currently have it setup right now to run on one battery. It does look like it will walk some now with the Pypos Ripple gait. Note: there is an issue with the CFG file that was part of my zip file uploaded yesterday. Two of the Coxa servos are going the wrong direction.
That section should look like:
Somehow, I don’t think I’ve read that tutorial. That simplifies it. I was thinking the long ‘C’ bracket had to be horizontal.
I know the servo splines are at 15 degrees spacing, and that the C bracket is 45. I should post the alignment diagrams up on my wall, I keep forgetting little points about the alignment!
No Phoenix file changes to go along with the two SQ3_PS2_SSC32 files of yesterday? OK, I’ll see what I can do with them. The inverse table above doesn’t seem to be used in my older files. They are both coxa servos, so I’d probably see that error when the 'quad does a rotate in place.
