Looks a lot like mine. Thanks for posting. I didn’t hear the beeps.
Tried to follow the legs, but too short for me to get a handle on the gaits.
Thanks for the update. I do like working with the code in this format. No rush for libs. I suppose you could save it in github both ways?
You are welcome. As I mentioned, I think the gait with Balance mode turned on, that I showed at the end is probably running about as good as they had going when Xan finished the work. It was good enough to get some quick film segments for the SES kit main video.
Hopefully if your SQ3 looks about the same, then you should be able to experiment with the different gaits and hopefully find a gait that works well for you. As you do figure out improvements, it would be great to get them into the code base. I will be happy to help here or you could always do a fork of the code on github and do a pull request…
I am in the process of folding the different changes (on several fronts). Teensy support, PhantomX changes on Teensy/Megas where I have Terminal commands, Now I can turn on tracking servos, that allow me to hand move servos and verify that mins/maxs look reasonable and the like. Also ability to turn of Single Leg mode… I have updated a few of the projects up on github yesterday. Still in the process of updating the main project. Want to verify that I did not do something that obviously screwed other things up. Later yesterday was trying it out on Phoenix. Need to recharge battery and probably add 9v…
Also I installed MarkDown Pad 2 and upgraded it to have support for the Github flavor, so I have been updating several of the Readme.md files of different projects.
If needed/wanted can set up SQ3 project, like I did for PhantomX…
I did the phantomX one as there are quite a few of them out there and there is interest by Trossen. For example they have setup web page on using it. learn.trossenrobotics.com/10-int … oenix-code Note: there are things in the document that I think should be changed, but I appreciate that they took the time and have updated it some. Will be taking another pass at the page and making suggestions and/or changes to code to address things that they find.
I played around a little more with observing the legs through gate selection (on a test stand). I can’t see much change in the gait, but I’m still experimenting. I’m not hearing a lot of beeps. I may not be operating like I think I am. I’m tempted to add an annotate to the controls, send a word or message to the debug terminal so that I’m sure I’m selecting the command I think I am. I’ve got the command chart. I’ve gone through the code many times. I do detect what might be joystick offset, as the walk controls don’t seem to center, or are ignored.
That’s a lot of support! Tracking servos only on PhantomX servos, right? Or maybe HV-220 servos. MarkDown Pad 2? An editing program?
I’d like to see an SQ3 project. What did you do for PhantomX exactly? Something on Trossen? OK, you said that. The Quick Start Guide is a good idea too. Maybe LM would fund it.
I’m anxious to build up a hex and run this code. I know how a hex should work, I wonder if a 'quad is more difficult for some reason? My first hex runs on my converted (from PowerPod) ‘C’ code for the PIC. the tripod gait is easier, of course. Maybe I’ll learn something from running Phoenix code on these legs.
Well, I’ve got family coming over, so the remainder of the day is committed. Maybe I’ll get my brother to shoot some video.
Alan KM6VV
Yep - Sometimes the beeps don’t give too much information. On my Linux versions, I have an option to turn on ESpeak, where when I select something it may say something, like the name of the gait, or Balance On…
Tracking servos only on Arbotix (AX) servos. Also I think I may have something like this coded up in the Orion Servo version as well.
For PhantomX, I did the implementation of the AX servo driver, plus the Commander Input driver… They were also interested in having it updated to their version 2 of the PhantomX, so they supplied the parts for me to convert my V1 to a V2… I have also experimented with updates to their Arbotix package that installs on Arduino 1.0.x. I forked their github and updated it to be compatible with 1.0.5. They are (or have) done a pull request to get those changes back into their main fork. I have also worked on it with the Arduino 1.5.x branch, to hopefully get rid of their whole hardware code base except for the variants definitions, which gives the pin information. I found a deadlock condition in the HardwareSerial code base and suggested some changes both to fix and to speed up to Arduino. My changes were folded into some other fixes for this and some of my speedups are in the 1.5.6 release… I have version of the Arbotix libraries and the like where I go directly to using the Serialx objects instead of private code base, which for me works great. They have an open Issue up on their github about doing this, not sure what will happen there. I may create a Branch on my Fork with all of this, so they can do a pull request if they so desire. This is also the version of libraries I use for the AX servos with the Teensy (and similar on Linux boxes)… Probably enough on Ax servo support.
Today, I thought I would have some fun and replace the SSC-32 and the Botboarduino and PS2 on my SQ3 with just my Teensy breakout board.
Over the last few days, I updated my ServoEx library to work with the Teensy, so I thought this might be a good test case. It did help me find a bug in the ServoEx I uploaded yesterday. So I created a copy of the sketch that uses the ServoEx servo driver and the Command Input device and connected up the 12 servos to the Teensy breakout board. I found that I needed to make a few more fixes to the servo driver as it assumed one of my older shields which had an I2cEEPROM on it, as some of the boards (chipkit? Due?) did not have EEPROMS. So I now have it so I can configure it to use either. So far as I can tell, the driver appears to be working pretty well. Note: the ServoEx code is based off of the Servo library and allows you to connect up to 12 servo for timer. The Teensy code base emulates having one such timer, so by default it supports 16 servos. Others up on the Teensy forums have pushed this number higher, including one as high as 18, but the main issue with this, is beyond 12 servos you may not get a full 50 servo cycles per second…
Github has been updated. Can upload a zip file with the actual project (.ino and quad_cfg.h) if anyone is interested.
Kurt
Well, I got my new parts, and put together an inline BH3 hex, with 3DOF T-Hex legs. I got sidetracked a little from the 'quad. I think getting this 'hex together and walking might be helpful.
I downloaded Lynxmotion-3DOF-4DOF-Hex-fc0154a.zip referenced from:
“The Complete H3/H3-R Tutorial v2.0”
lynxmotion.com/images/html/build99f.htm
I haven’t figured out the parameter(s) to change from inline to round. Under PowerPod, I used an array to select the legs at their appropriate (radial) angle for around 'hex.
I changed the SSC-32 pin definitions and the baud rate to 38400.
It seems the ‘O’ servo offset works and moves the legs, but not under PS2.
I then set the cSSC_BINARYMODE parameter off. But it doesn’t compile.
phoenix_driver_ssc32.cpp:269: error: 'ServoMoveTime' was not declared in this scopeI also took the old LSQuadA_PS2_SSC32_Complete build, made a new project, and started adapting it. I know I started out with a “Quad” build, but as the QUADMODE parameter was there I figured the intent was to build either 'quad or 'hex. Almost compiled. I found the missing #defines for the middle legs in Hex_Cfg.h and added in my own. It compiles! I could use a real HexCfg.h for the inline BH3 'bot.
I figured the leg segment lengths would be off from the “// This is for CH3-R with Type 3 legs” comments. I substituted my own.
The “[START POSITIONS FEET]” I mad a stab at it, but they’re probably wrong as I need inline, not radial (45 deg) positions. a real HexCfg.h for the inline BH3 'bot would help here.
Result was the rear legs looking appropriate on start-up positioning, but the front legs looking weird, and the middle not much better.
I guess I can figure out the start positions with some more work. I do wish I could find a JPG of the coordinates for the inline 'bot. X is left-right, Z forward, and Y up (down). Not sure of the signs, I’ve probably got some wrong.
Comments on the BH3 chassis kit:
Nice crisp chassis plates.
1/4" holes for the switches a little tight, should instruct people to slightly enlarge them (before) assembling much.
Also found the 2-56 clearance holes on the servo hubs a little too tight for 2-56 hardware. Might be OK for self-taping hub screws. I’m using metal servo horns.
Could use a 9v battery clip. (and holes for clip).
Need slots for 6v battery tie-wraps.
Need a slight notch to clear the three switch holes in one the ACB-01 chassis brackets. Otherwise the switches sit cocked.
Might be nice to indicate how and where to mount a PS/2 xcvr. Parts?
All together, nice chassis.
Alan KM6VV
Note: several threads on compile error when you turn the Binary mode off. Change the variable name ServoMoveTime -> wMoveTime
I put a pull request in for this a long time ago, which never went anywhere…
Wow, that was simple. Which threads? On LM?
Is this build able to do inline as well as round?
Alan KM6VV
Next morning on the hex:
Made the simple edit.
Coleman,
maybe we can fold in some changes? This BotBoarduino_CH3R_PS2 code may be OK for a round 'bot, but need to be tweaked for an inline. I probably need a round chassis as well.
After two swaps of leg servo wires (oops), the legs are all moving in the right direction. Hadn’t calibrated legs yet, or I would have caught that.
However, The coxa swings are too far. Probably due to being inline hex, and not the round hex. Some changes in the [MIN/MAX ANGLES] table should help there. Should probably be two tables, one for inline, one for round. I seem to remember some other differences between inline and round calcs. The moves of the round legs have to be rotated for other then the middle legs, no?
I’ll play with the BH3 for a while before I get back to the 'quad. Might even fold changes into the old LSQuadA_PS2_SSC32_Complete code I started with, and/or make this code do duty for both inline and round 'bots.
Alan KM6VV
Jeffrey is more programming related, so we’ll get his input into this.
As for the pull request, we’ll take a look in GitHub (appreciate the updates and sincere apologies if it was overlooked).
Thanks for the response. I’ll play with it for a while. Need to tweak a little more…
Jeffry:
Here’s a little of what I’ve found so far:
[code]//[LEG DIMENSIONS]
//Universal dimensions for each leg in mm revise for inline and T-HEX legs alm
#define cXXCoxaLength 29 //29 This is for CH3-R with Type 3 legs OK
#define cXXFemurLength 74 //57 on type 3 legs, 74 on T-REX legs
#define cXXTibiaLength 105 //141 on type 3 legs, 105 on T-REX legs
#define cXXTarsLength 85 // 4DOF only…
//--------------------------------------------------------------------
//[MIN/MAX ANGLES]
// these limits must be for round 'bots. change coxas from 650 to 450 alm
#define cRRCoxaMin1 -450 // 550 Mechanical limits of the Right Rear Leg
#define cRRCoxaMax1 450 // 650
#define cRRFemurMin1 -1050
#define cRRFemurMax1 750
#define cRRTibiaMin1 -530
#define cRRTibiaMax1 900
#define cRRTarsMin1 -1300 //4DOF ONLY - In theory the kinematics can reach about -160 deg
#define cRRTarsMax1 500 //4DOF ONLY - The kinematics will never exceed 23 deg though…
#define cRMCoxaMin1 -450 //Mechanical limits of the Right Middle Leg
#define cRMCoxaMax1 450
#define cRMFemurMin1 -1050
#define cRMFemurMax1 750
#define cRMTibiaMin1 -530
#define cRMTibiaMax1 900
#define cRMTarsMin1 -1300 //4DOF ONLY - In theory the kinematics can reach about -160 deg
#define cRMTarsMax1 500 //4DOF ONLY - The kinematics will never exceed 23 deg though…
#define cRFCoxaMin1 -450 //Mechanical limits of the Right Front Leg
#define cRFCoxaMax1 450
#define cRFFemurMin1 -1050
#define cRFFemurMax1 750
#define cRFTibiaMin1 -530
#define cRFTibiaMax1 900
#define cRFTarsMin1 -1300 //4DOF ONLY - In theory the kinematics can reach about -160 deg
#define cRFTarsMax1 500 //4DOF ONLY - The kinematics will never exceed 23 deg though…
#define cLRCoxaMin1 -450 //Mechanical limits of the Left Rear Leg
#define cLRCoxaMax1 450
#define cLRFemurMin1 -1050
#define cLRFemurMax1 750
#define cLRTibiaMin1 -530
#define cLRTibiaMax1 900
#define cLRTarsMin1 -1300 //4DOF ONLY - In theory the kinematics can reach about -160 deg
#define cLRTarsMax1 500 //4DOF ONLY - The kinematics will never exceed 23 deg though…
#define cLMCoxaMin1 -450 //Mechanical limits of the Left Middle Leg
#define cLMCoxaMax1 450
#define cLMFemurMin1 -1050
#define cLMFemurMax1 750
#define cLMTibiaMin1 -530
#define cLMTibiaMax1 900
#define cLMTarsMin1 -1300 //4DOF ONLY - In theory the kinematics can reach about -160 deg
#define cLMTarsMax1 500 //4DOF ONLY - The kinematics will never exceed 23 deg though…
#define cLFCoxaMin1 -450 //Mechanical limits of the Left Front Leg
#define cLFCoxaMax1 450
#define cLFFemurMin1 -1050
#define cLFFemurMax1 750
#define cLFTibiaMin1 -530
#define cLFTibiaMax1 900
#define cLFTarsMin1 -1300 //4DOF ONLY - In theory the kinematics can reach about -160 deg
#define cLFTarsMax1 500 //4DOF ONLY - The kinematics will never exceed 23 deg though…
[/code]
Mind you, I’m putting 3DOF T-HEX legs on a BH3. More conditional compiles for different legs sets, and different body shape (inline, round, T-HEX, ?) should be investigated.
The Servo limits probably depend both on body shape and leg type. A servo limit test would be a nice option for the code. It would allow a servo to be swung across it’s range and limits determined.
I’d like to have a matrix of code sets (program code) for different bodies, sizes and legs. All the parameters for these combinations would be available.
As a start, do you have a list of the URL’s for the code for the different 'bots you sell? Do you have a lab set up with all the different 'bots? hexapeds and quadrupeds would be a start. Then add the bipeds. Do you have a list of all the leg types?
Thanks for any help you can provide. I’d like to see a complete tested set of programs for the legged 'bots.
Alan KM6VV
I’m looking at the start positions again and trying to figure them out. In part:
[code]//[START POSITIONS FEET]
#define cHexInitXZ 80
#define CHexInitXZCos60 40 // COS(60) = .5
#define CHexInitXZSin60 69 // sin(60) = .866
#define CHexInitY 80 //30
#define cRRInitPosX CHexInitXZCos60 //Start positions of the Right Rear leg
#define cRRInitPosY CHexInitY
#define cRRInitPosZ CHexInitXZSin60
[/code]
I think these are the coxa hub locations for each of the legs. Rotation from a front/back center line. Leg 0 is at 30 degrees.
2.625/5.25 = .5 = sin(30) = cos(60)
What is cHexInitXZ, 0 deg?
What are the 40, 69, 80 values? 8 bit trig values?
Any more insight?
Alan KM6VV
80 is the distance out the legs are. So yes if 0 degrees, then either x or z would be 80mm. If the leg is at 60 degrees, the cos of 60 degrees is .5, so either the x or z will be 80*.5=40, the other will be sin 60 .866*80= 69mm. If you rotate the legs the values will obviously change as well. Wish you could simply use sin,cos in the constant tables, but I did not have much luck…
80mm? 3.14? does not seem to correlate with the physical dimensions of the CHR3 'bot. The radial distance of the servo hub hole patterns on the CHR3 is 5.25", I think. Maybe these are the distances X,Y,Z of the foot **FROM **the servo hub hole patterns? That makes sense. If I’m still using the radial leg starting positions, then I should be seeing the legs more splayed out, I’m not.
I did dig up this table (expanded) from old BASIC code for the legs (A, B, C). I knew I’d seen something somewhere.
[code]//--------------------------------------------------------------------//****************************************************
// 3DOF-A Leg Dimensions (TibiaAngle constant = 0)
// HipV_HipH con 38 ;1.50" = 38mm (1.50 * 25.4)
// Femur_Length con 57 ;2.25" = 57mm (2.25 * 25.4)
// Tibia_Length con 124 ;4.875" = 124mm (4.875 * 25.4)
//
// 3DOF-B Leg Dimensions (TibiaAngle constant = 0)
// HipV_HipH con 29 ;1.14" = 29mm (1.14 * 25.4)
// Femur_Length con 57 ;2.25" = 57mm (2.25 * 25.4)
// Tibia_Length con 108 ;4.25" = 108mm (4.25 * 25.4)
//
// 3DOF-C Leg Dimensions (TibiaAngle constant = 20)
// HipV_HipH con 29 ;1.14" = 29mm (1.14 * 25.4)
// Femur_Length con 57 ;2.25" = 57mm (2.25 * 25.4)
// Tibia_Length con 141 ;5.55" = 141mm (5.55 * 25.4)
//
// 3DOF-(Old) Leg Dimensions (TibiaAngle constant = 0)
// HipV_HipH con 32 ;1.25" = 32mm (1.25 * 25.4)
// Femur_Length con 70 ;2.75" = 70mm (2.75 * 25.4)
// Tibia_Length con 108 ;4.25" = 108mm (4.25 * 25.4)
// T-REX 3DOF
// cCoxaLength con 29 ;1.14" = 29mm (1.14 * 25.4)
// cFemurLength con 76 ;2.98" = 76mm (2.98 * 25.4)
// cTibiaLength con 104 ;4.04" = 103mm (4.04 * 25.4)
// T-REX 4DOF
// cCoxaLength con 29 ;Length of the Coxa [mm]
// cFemurLength con 75 ;Length of the Femur [mm]
// cTibiaLength con 71 ;Length of the Tibia [mm]
// cTarsLength con 85 ;Length of the Tars [mm]
//
//
//****************************************************[/code]
Could build this table into a conditional compile, now that we’re in C. (Obviously no “con” ).
Some of this is starting to come back to me.
Now to find and/or construct a BODY table.
Alan KM6VV
Yep, I believe from coxa mount to where foot should be.
and Yep - The Hex_Cfg (or Quad_Cfg), where mostly derived from the Basic versions. Some of the later ones had sort-of equations there as to not have to duplicate for each leg
I traced their use out and the values get loaded into a table, and on into LegPosX, where I assume they get used. Maybe they get overwritten before being used. I don’t see any affect in changing them.
Alan KM6VV
Might help to see your config file. Maybe checking to see if there is any other magic going on.
For example some extract from my Phoenix quad cfg stuff;
[code]// Lets try some multi leg positions depending on height settings.
#define DYNAMIC_INIT_XZ
#define CNT_HEX_INITS 3
#define MAX_BODY_Y 150
// For Inits we may want to tell system actual angles we are initiing servos to…
// In some cases like some quads may not want legs straight out…
#define cRRInitCoxaAngle1 -300 //Default Coxa setup angle, decimals = 1
#define cRFInitCoxaAngle1 300 //Default Coxa setup angle, decimals = 1
#define cLRInitCoxaAngle1 -300 //Default Coxa setup angle, decimals = 1
#define cLFInitCoxaAngle1 300 //Default Coxa setup angle, decimals = 1
#ifdef DEFINE_HEX_GLOBALS
const byte g_abHexIntXZ] PROGMEM = {cHexInitXZ, 130, 110};
const byte g_abHexMaxBodyY] PROGMEM = { 30, 60, MAX_BODY_Y};
#else
extern const byte g_abHexIntXZ] PROGMEM;
extern const byte g_abHexMaxBodyY] PROGMEM;
#endif[/code]
Some of the special stuff is that the code can reconfigure the leg positions, depending on the body height, so there is code that if CNT_HEX_INITS is defined the code will do the sin/cos itself to recompute the leg positions as the robot gets lifted. Up to 30 it uses the first, up to 2nd… So you might want to check.
Also code is in place to allow you to dynamically change leg positions on the fly… I have not tested that much with PS2. But I think I also put in command to allow you to set these with debug terminal as well.
Kurt
I don’t see a #define for cRRInitCoxaAngle1, just #ifdef statements. But that could explain why I don’t see new angles.
I’m playing with the CH3R hex code version referenced in the build99f for now. But as I mentioned, it’s not really set up for inline. I first thought the supplied code would plug and play, but it isn’t (BotBoarduino_CH3R_PS2). So I’m further sidetracked in getting the code to work for inline (vs round) body.
300 is straight out? In What scale? Must not be 500-2500 in servo pulses.
The angle of the servo hubs, or at leas the neutral angle of the leg would make a difference!
As I understand it, the direction vector of the requesting move (heading) must be translated into the reference frame of the particular leg in order to compute a move. It gets “added” to the vector of the leg. I’d like to follow that whole sequence. Seems I’ve studied it before from my old C code, but I’ve apparently forgotten most of it!
From Hex project BotBoarduino
Hex_Cfg.h (14.5 KB)
From Quad project
Quad_Cfg.h (11.1 KB)
Back to studies.
Alan KM6VV
With the Hex: 300 implies 30 degrees. All of the information in these files try to be in units like degrees or mm and the like as to make it easier to then use different back ends to do the actual conversion to servo units, which are different for SSC-32, versus AX-12, versus Orion…
With the Inline Hex, not sure what you want for initial leg positions. I could easily imagine it, with all legs inline, in which case you need to change the initial leg positions.
[code]define cHexInitXZ 80
#define CHexInitXZCos60 40 // COS(60) = .5
#define CHexInitXZSin60 69 // sin(60) = .866
#define CHexInitY 80 //30
#define cRRInitPosX CHexInitXZCos60 //Start positions of the Right Rear leg
#define cRRInitPosY CHexInitY
#define cRRInitPosZ CHexInitXZSin60
#define cRMInitPosX cHexInitXZ //Start positions of the Right Middle leg
#define cRMInitPosY CHexInitY
#define cRMInitPosZ 0
#define cRFInitPosX CHexInitXZCos60 //Start positions of the Right Front leg
#define cRFInitPosY CHexInitY
#define cRFInitPosZ -CHexInitXZSin60
…[/code]
The Front And Rear legs would be configured the same as middle legs here. Could simply change it. or you could change the defines
for:
#define CHexInitXZCos60 cHexInitXZ
#define CHexInitXZSin60 0
But if doing so, would probably change variable name to not have 60 in it, like I did in the quad cfg where I used names like: cRobotInitXZCos
It is these settings that actually change the position of the legs, the values in cRRCoxaAngle1 and the like are then used in the math, that once we know
the desired angle to move the leg to, it has to use this to compute the servo angle needed to get the actual position. Hope that makes sense.
Edit: The value CHexInitY is an initial offset for the Y body of the robot, I know that the value can be computed and the like (in mm), but I usually find, I need to play with this. You can put in a larger value, tell it to start (start button), should position legs, so they are just touching the ground, with the body more or less touching… If up in air, then decrease, try again… If too little, I have seen times in the past where some computations don’t work right and maybe legs stand straight up…
Kurt
Something different happened this time. I fired up the 'bot with the original values, and the front and back legs powered up at what looks like close to a 60 degree angles! I substituted the above two lines, and the legs are at 90 degrees, as predicted.
I don’t know why I never saw this action before. Maybe some other parameter prevented it. I’ve been changing a few. But at least I can see an effect now. I didn’t see one before when I set terms to new values.
Oh well.
Thanks for the new values.
After looking at the “sprawled” legs (at 60), I think they may be better! Sort of like the T-Hex layout I’ve been studying.
I did some walking and turning in place with the sprawled legs. It’s nice to not have the legs banging together!
I still have to get the walk modes and joystick control modes better in my mind. But I can walk forward/bakward with the left joystick. But it doesn’t steer that well. Translates nice! Right joystick turns OK. not good forward backward. But I may just be confusing myself.
Thanks for the interest.
Alan KM6VV
EDIT: Oh wait, If the legs neutral position is now to be “sprayed” at 60 degrees, then the coxa servos probably need to be neutral at the new angle.
Back on the 'Quad.
I incorporated the proper leg data and new starting positions into the LSQuadA_PS2_SSC32 code I’m using as a test bed.
Seems to walk! Albeit with a very drunk swagger. I’ll start experimenting with the height and balance corrections next.
I can set the starting leg positions to be inline with the servo hubs, or at right angles to the body. The angled leg positions spread out the legs more, which keeps the legs from slamming into each other. Also seems to make translations easier.
Alan KM6VV