I’m not seeing the Leg Torque Calculator, just the tutorial.
I see you wrote the tutorial, nice job!
Alan KM6VV
What is interesting in the video that Coleman linked to, is if you go to the actual project page:
serva.cz/konstrukce/quadruped/
You will see that the servos used on this were: 4 5645s (Coxa) 4 635hbs (Femur) and 4 475hb(Tibia). So the strongest servos are used for the Coxa?
Not much progress today, doing other stuff, also started to suspect bad gear, so update my botboarduino test program to move each servo back and forth and sure enough one of my Tiba servos is hanging up… (Bad gear). So need to swap it out. First need to see where the my spares are.
There was a question over the last few days up on Trossen about stable gaits and one of the answers pointed to a paper about this, which looks sort of interesting. www-clmc.usc.edu/publications/P/ … RA2007.pdf (But math makes my head hurt 
Kurt
So do you speak czech?
That doesn’t sound right. Coxa doesn’t require a strong servo, it’s probably the 475. 635 is not as strong as 645, 5645 is stronger then 645 from what I can read. Order is probably Tibia, Femur, Coxa.
Yeah, I didn’t get anything done either. Ouch. Bad break. Must be nice to have spares! I’ve already committed my few 475 servo left. I ordered two more 645 servos yesterday, along with a hex-inline chassis, and a few parts to make a total of six 3DOF T-REX legs (I had four). I will only have four 645 servos for the legs.
PDF loading real slow, almost like a TTY! Sounds interesting, 'tho. Oh I know, I’m running AntiVirus scan, that always slows things down. Yeah, almost need to be a mechanical or robotic engineer to under some of the latest Jacobin calculations. A quick glance shows they’re using a diagonal sequence. More later, after I get a chance (attempt) to read their paper!
Alan KM6VV
Nope about the only language is speak is English , but when i load the page there is a google translate drop down list on the left hand side. As for which servo does what, I was looking at pictures on page and I was surprised…
Yep the 4 legs I am using originally were from my spare parts hex, so broke apart one of the other two legs to extract servos.
It’s amazing how many servos I’ve accumulated. Various robots, a heli, I keep finding more. Just found a crab robot with little miniature servos. Speaking of crabs, what did you think of my idea to make a crab robot? Walk my old wide 'quad sideways…? Just a thought.
I did notice that the paper liked a diagonal gait, is one of the gaits on the SQ2 diagonal? I guess I can edit the code. Is there more then one sequence, or do they all share the same order?
Alan KM6VV
I have been doing some playing around and replaced the one bad servo (which definitely helps make it work…
I also did a real quick and dirty video of the SQ3 more or less walking on my desk:
Again this video is raw. At the beginning it is using the ripple gait. Note: I changed the speed setting for these gaits to say go as fast as possible…
Then the next gait (after the beep), is where I tried to put a gait in that uses the figure 8 pattern instead of a circle for which legs go when. Also put a one step do nothing between each leg moving. Lots more can be experimented with this.
Then two beeps (two presses of the select button)as I ignore the Amble gait and go for the first gait that was built into the Lynxmotion gait. Does not walk well at all without balance turned on. Then you hear a different beep when I press the Square button and turn on balance. You can then see it shifting it’s balance in a circular motion and you see that it can walk (slowly) with this…
I have also included the current code that I used for this here. I am not sure how much more I will do with this for now. Once I verify that I have not screwed up the PhantomX (Hex and Quad), I will update my github with any change I made and include the project as one of the examples
SQ3_PS2_SSC32-140418a.zip (40.4 KB)
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 scopeSo I’m guessing something is missing…
I 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