My Bluesmirf modules connect to a controller rather then directly to the SSC-32, but if you’ve gotten a reply to version, then you’ve got your connection and can proceed to command the SSC-32. I do like to run at 115k, 'tho.
Alan KM6VV
Hi Alan,
Yeah that’s true that the connection between my BluSmirf module and SSC-32 is successfull since I am able to run the servos through SEQ. But at this point the communication is at 9600 Baud Rate. In the tutorial its been mentioned to switch to the 11.5k Baud rate before creating sequences, so I thought it might be a pre-requisite or something mandatory.
Should I go with the 9600 baud rate or is it mandatory to have 11.5k baud rate for an effective communication?
Thanks Alan,
Umar
You don’t HAVE to run 115K, it’s just faster! My BlueSmirf comes up that way. I think I re-strapped the SSC-32 to be 115K as well. That’s about 10 X as fast!
Alan KM6VV
So, does that mean 9600 Baud rate is sufficient for communicating with BluSmirf? I believe it maynot make any significant differences in running the sequences.
By “fast”, do you mean SSC-32 would run the sequences faster? which means faster servos speed?
Still, I am curious about why am I not getting a respnse from the “+++” and “AT” commands.
Any thoughts?
Thanks,
Umar
heh, by faster he means the data gets from the pc or whatever to the ssc-32 in less time. for the most part this has very little effect because relative to the time a command takes to execute the data transfer time is very small. however if you were commanding lots of servos with commands that take very short amounts of time to execute this could become significant because you are transfering large amounts of data required in very short amounts of time and failing to meet the time requirements will make the movements jerky or un-smooth between steps. the downside to using a higher baud rate is it can make the communications more prone to electrical noise screwing up a command. just to throw some rough numbers out, at 9600 baud a single bit is roughly 104uS long vs at 115K baud the bit is 8.7uS long. So if you had a lot of noise in your system due to poor ground wiring or motors in servos starting to wear out it would take significantly more noise to corrupt the 9600 baud bit than the 115K baud bit.
Hi All,
I did some testing with SEQ and zenta’s PEP and have come with alot of questions. Here are my updates.
SSC-32 Configuration
- I have used the Lynxmotion Phoenix tutorial in configuring the SSC-32 for all the servos. I am using
BlueSmirf for the communication. And in this respect I really appreciate the lynxmotion team for providing such a explanatory and easy to understand tutorial to accomplish a successful serial connection over bluetooth.
- Connected SEQ through BLuSmirf and centred all the servos from the SSC-32 configuration panel.
- coxa is inline with tibia.
- femur is parallel to the ground.
- I rotated tibia servos +/-15 degrees through SEQ so the line from the tibia servo axis to the tip of the tibia is perpendicular to the ground.
-Saved the settings as a new SSC-32 configuration file.
Now the very first question is about the starting position of the robot.By that I mean,when the power is switched ON, should the bot achieve the position determined above? or should it go in a sitting position.Here, i am talking about the very first position from where the robot starts its gait.
PEP Setup
http://img178.imageshack.us/img178/8290/18853483oj1.jpg
Here are some angles I determined. I am not certain about my findings since I just took the values which apparently looked max/min. While determining these max/minvalues, do I need to consider the line of motions of the neighbouring servos as well or the max/min value of a coxa is determined only by isolating it from the body? because if I donot isolate a coxa, then the angles drop to even smaller values since the area of motion gets obstructed by other legs.
Kindly correct me in the following concepts used in PEP.
-The femur length is the horizontal distance from coxa servo axis to the tibia servo axis.
-Tibia length is the perpendicular distance from the tibia servo's axis to the tipd of the tibia.
-what about coxa length?
-coxa offset is the angle between two lines drawn through the two front or rear coxas?
“Xan”, my design is almost a replica of yours, since I used the same dimensions of the body parts, so I believe if you provide me with your PEP Setup sheet, I may easily manipulate it accordingly.
Sequences
once Setup is done, the next stage is creating simple sequences. “plingboot”, here I need your assisstance in particular, since you started from the very basic steps, so kindly give me some brief outlines on how to create some basic steps. I think the workflow would something like:
-move the legs in zenta's PEP, and for each move clicking "write" to write a sequence.
-after creating some steps/sequences, save the Export_import sheet to a csv file. Am i right here in exporting the data?
-Then connect SEQ, import the project and play the sequences.
“plingboot”, if possible, kindly provide me some example for this workflow if I am right in my inferences.
And here, I thank all of you who have contributed so far with their knowledge and assisstance and I really appreciate your help and thoughts for the future correspondences as well.
I believe achieving the above would provide significant confidence in my knowledge and would pave a path for creating a gait.
Thanks again,
Umar
Hi Umar,
I have to start that I’ve never used the BlueSmirf in combination with the SSC directly. There are a lot around here who do so it sure is possible. I’m using the BlueSmirf in combination with the Atom and what I had to do is make sure that the Atom, PC AND BlueSmirf are all configured for the same baud rate. Once this was configured, everything worked fine in both directions.
I never used the PEP to control my bot so I don’t have one ready to use. I used the PEP to figure out the IK. But I think that one of the first versions (before LM released the phoenix) has got Zenta’s Phoenix setup. Since BlackWido is a almost copy of that you don’t need a lot to change. BlackWido is build using just photos so the dimensions could be slight off…
Xan
Hi,
I’m not sure if I understand what you mean here. Are just refering to the coxa angles? The coxa angle values are limited by the body or its neighbour legs. When I calibrate the coxa servo I place the neighbour legs in the “best case” position.
No, the femur length is the distance between the femur servo and the tibia servo axis.
Tibia length is the shortest distance between tibia servo axis and the tip of tibia (tars).
The coxa length is the horisontal distance between the coxa servo axis and the femur servo axis. (Hip horisontal -> Hip vertical).
Coxa offset:
For an inline hexapod are all legs in a parallel position relative to eachother (pardon my bad english… 
) when the coxa’s are in the center (0 deg) position. The coxa offset are only a value of how much the center postion for the front and rear legs differ from the inline position. For Phoenix we have defined that it should be 60 deg. But it could also be set to 45 or 55 deg, its really just a definiton question.
Please read the manual about this.
Thanks zenta for the clarifications. I have read the PEP manual a number of times and now the contents are making sense and are quite understandable. I hope i would soon experiment some basic moves as explained in the PEP manual.
Thanks again,
Best regards.
Hi zenta,
I crunched down the information in PEP manual a number of times and I must say you have done a great job in compiling all the details along with screen shots; things are getting clear and understandable now.
A couple of question for you please.
img300.imageshack.us/img300/9059/pepzr4.jpg
img300.imageshack.us/img300/pepzr4.jpg/1/w1212.png
The above figure is the sequence I created following your tutorial example which includes steps “All legs on the ground–>7cm down”. Here I see that, the angles for all the servos are calculated in “-ve”. Import into the SEQ is successful, but when I run this sequence, RIGHT legs move in opposite directions. I edited the sequence file manually and changed all the angles which I have marked with a red rectangle in the above figure to “+ve” values. This time when I ran the sequence the RIGHT legs moved in the right direction. So , do i need to reverse the servos connected to the right legs of my bot or is there any option in PEP to reverse the angles/step-values for servos connected on PIN 0,1,2,4,5,6,8,9,10 ?
Secondly, when I run the sequences by clicking the "play sequence"button in the Sequencer, it runs the sequences at a very high speed. But when it is run by clicking the “Run Project” button, the sequences are run at somewhat lower speed. Is this a normal behavior?
A few more question about the setup sheet please 
The field “Lowest part of body”, what does this value specify?
FCX= the x-distance from center of the body to coxa servo axis?
FCZ= the z-distance/perpendicular-distance from center of the body to coxa servo axis?
SCX=?BCX=?
“The center of body”, does this point lies in the middle of just the upper plate of the body or in the middle of the distance between upper and lower plates of the body?
Actually I couldn’t manage to get the accurate knowledge of these values so I didn’t change them. When I ran the sequence I didn’t find any abnormality in the motion while lifting the legs , still I need to understand these variables.
The IK Phoenix sheet is quite an impressive effort as well. I have been struggling with writing my own IK with simple transformations and geometric calculations for simple 2-link mechanism in 2D, but haven’t been successful yet , so to me IK Phoenix sheet is really an impressive real time IK solution. I just wanted to ask that you didn’t mention anything about this sheet in the PEP tutorial, and similarly I don’t find much description in the sheet itself. Can I use this sheet to understand the IK by some means if possible?
Thanks alot for your time.
I really appreciate your cooperation and concern.
Best regards,
Umar
Hi,
Take a look at page 4 in the PEP manual. 
The right legs has to be reversed in SEQ SSC32 configuration.
I don’t have any good answer about that. What are your time settings/value? The speed should be the same I think.
The lowest part of body is the vertical distance between center of femur servo axis to the lowest part of body.
All the FCX, FCZ… defines the body dimensions relative to center of the body seen from above (this point are not defined along the Y-axis).
The SCX defines the position of the left and right middle leg, always at Z=0, it is the distance from center of body to center of coxa servo axis.
The BCX and BCZ are the same as for the the FCX and FCZ.
BC = rear coxa (the B comes from a norwegian word “bakre”, sorry).
FC = front coxa.
I can’t take the credit for everything in the IK/FK Phoenix sheets, because they are based upon an excel sheet made by Mike Keesling.
I’m glad to hear that I’m not the only one that copies
[size=150]share, use and improve![/size]
That’s the spirit! 
I totaly agree with you Xan! Instead of keeping your code to your cheast, share it and maybe you and the rest of the community can learn more and finaly make a much better product/code together!
Hi,
Thanks zenta for the explanation about the PEP setup. It resolved my queries
And my bot finally stood up on its legs, lifted its body to some height and performed some body rotations about its leg as described in the PEP manual
I am really happy to find PEP tutorial and PEP sheet working so effectively. Thanks Zenta, it has been a great help
Some questions here please
I noticed that when the bot lifted itself to some height, there was some sort of teethering sound coming from some servos. I suspected that the sound was coming from only femur servos and I am not sure whether all of the fermur servos were responsible or some of them. I feared the noise might be coming from wrongly meshed gears in the servos which made me to switch off the bot, and unfortunately on losing the power the bot fell on the table with a large bump. The bot might have felt bad of it
Anyhow, I am really concious about this sound. what could be the possible reasons of its occurence? I think I may find slight vibration in the servo producing such sound either. Is all this a normal behaviour of HS645MG servos? if not than I am fearful!!
Secondly, PEP sheet is extremly good in making some cool moves and executing them effortlessly through SEQ, but I have not been successful in creating a gait through PEP. I spent some time understanding the 12 leg tripod gait but couldnt make it run on my bot. I believe 12 leg tripod gait is the easiest one, right?
Zenta can you propose me some easy way of approaching this task. I mean, would you recommend me creating the 12 leg tripod gait myself from the scratch or use the one available at the lynxmotion phoenix project page? Creating a tripod gait in PEP need what basic steps to follow? I mean can you please outline the basic workflow of creating the gait in PEP?
Finally, I am looking forward to switching to Atom pro with bot board once I am successful with creating a smooth gait using PEP. I’d be moving to Xan’s code which I see has been very propular around these days . But I see that its based on PS2 controller, which means unplugging BlueSmirf and plugging-in either PS2 or some RC link, right? I would be very happy if I could use that code with my BluSmirf too
Thanks a lot for the cooperation.
Best regards,
umar
Hi,
Here is a little tutorial how to create a 12 step ripple gait with PEP:
How to make a 12 step ripple gait (walking forward):
-
Center all legs (all coxa = 0 deg)
-
Set step value = 1.0cm (just an example)
-
Hit the Bwrd button in the move actions section 5 times to translate all legs forward (in reality your body moves backward)
-
In the generate walking gait sequences:
-
Select gait Ripplegait 12 steps
-
The textbox should be “Ripple 12s #1 start position”.
-
Hit the red Write step button once
-
Now the textbox should be “Ripple 12s #2”
-
This means that you have to tell the generator where position 2 are, do this by clicking the Fwrd button once in the Move actions section.
-
Hit the Write step button once
-
Now the textbox should be “Ripple 12s #3”
-
Ok, do you get the picture? Repeat step 9. to 11. until the textbox shows: “Ripple 12s #11 leg up end pos”
-
Since all your (Phoenix’s) legs are moved to the end position you have to define how high the leg should be lifted while walking, do this by clicking the blue (UP/ DOWN) spinbutton several times to move the legs upwards. (Oh, I forgot to mention that I reversed this button in the PEP 2.01beta version, because I felt it more logic that phoenix rised her body when clicking the UP button (moving the legs down) when having live control).
-
When you have positioned your leg in the height you want them, hit the Write Step button once.
-
Now the textbox should show: “Ripple 12s # leg up start position”
-
This means that we have to move all legs to the start position ( the position we wrote in step 7.), do this by clicking the right arrow on the spinbutton under the textbox. The textbox should now be:“Ripple 12s #1 start position”. Hit the green Read step button. Then move all legs upwards to the same height you did in step 13.
-
Now click the left arrow on the spinbutton under the textbox, the textbox should be:“Ripple 12s # leg up start position”. Hit the the Write step button once.
-
In the write sequences section select an vacant sequence/step. In the comment field give the sequence a name if you want.
-
Hit the red Generate gait! once. Don’t do anything while PEP generates the gait sequence. DONE.
-
Now you should be able to run the 12 step walking gait
Hi Umar,
The latest released version includes only support for PS2 remote. My code organized with subroutes. The Input is also a subroute so if you replace this one with the subroute for the Wii you will be able to use the BlueSmirf. I’ll ensure that you will get the latest version of the code when you reach that point.
Xan
Thanks a lot zenta for such an explanatory response. I’ll look into the details later at the end of the day.
I hope I’ll get some response for my following query as well.
Thanks,
Umar
Hi all,
I had been struggling with the Kinematics of phoenix for the last few days and eventually devised a way to determine the Forward Kinematics of phoenix leg. I am posting my workout and looking forward to your suggestions and comments around any aspect.
img227.imageshack.us/img227/7227/fkjl6.jpg
img227.imageshack.us/img227/fkjl6.jpg/1/w1150.png
I crunched down the equations in a small MATLAB program and the tabulated results you see at the bottom of the image is the ouput I got. To my surprise the results came out to be comparable with the ones obtained from PEP, so fortunatley I struck the right strings
I am now moving to the Inverse Kinematics, which is ofcourse the real part of the phoenix kinematics,but before doing so,I’d appreciate if you drop in any of your comments or suggestions which may help in improving any part of it.
Thanks,
Umar
Hi everyone,
Struggling with the inverse kinematics methodologies, I am finding a tough time to assimilate the different concepts obtained from different sources.
Has anyone here got some basic conceptual work flow which may aid me in determining IK of phoenix leg? When I look into the IK sheet included in PEP, few terms are quite difficult to understand which includes:
- It takes X & Y coordinate positions of the foot and return femur angle and tibia angle. Why does not it include the Z-coordinate and determine the coxa angle as well? “thus completing the IK for 3DOF leg”.
-Tibia angle is determined by the following equation
*ACOS(((B7B7)+(B9B9)-(I14I14))/((2B7)B9))
which can be simplified to
*=ACOS(((LfLf)+(LtLt)-(SWSW))/((2Lf)Lt))
where Lf=length of femur, Lt=length of tibia, SW=line from Shoulder to Wrist.
what is the generic form of the above equation? I mean how has this angle been determined? I tried making projections of the leg on X & Y coordinates and tried determining the Tibia angle but never came to understand this equation. Any thoughts?
- Angle A2 which is the angle SW line forms with the humerus. and given by
*=ACOS(((LfLf)-(LtLt)+(SWSW))/((2Lf)SW))
Any explanation on how to determine this angle? I am totally blank in making a concept of these angles when I visualize them on a generic 3DOF link-joint system.
Thanks,
Best regards,
Umar
Hi Umar,
It looks like you have spent some time trying to understand kinematics too
Forward kinematics might be useful when doing terrain adaption if you are able to get the correct angel for each joint (servo). This would probably be easier with an AX-12 instead of common RC servos?
This is simply done because its easier when using plain trigonometry and because I based my PEP sheet upon Mike Keesling’s sheet. I did write my own equations for IK one time but I didn’t use them.
If you want me to help you understand Mike Keeslings work I probably have to spend some time getting my old notes about that ( I know I have them somewhere 
)
I understand that you really want to know how this work and I wish you good luck! I bet you’ll figure it out. Like Xan said earlier “share, use and improve”, if someone have invented the wheel why trying to do it again instead of just using the wheel to make something great
If you find a way how to solve the full 3 DOF IK by using more advanced math (matrix) I would really like to know. It seems like you have better math skills than me anyway.