Well i feel like that should have worked but it just went all weird. The comment for the “inity” is thirty maybe i should give it an integer higher than 30.
With the unmodified code it tripods ok but i cant seem to switch gaits. At one point i did get to wave but it was too sloppy to really walk.
Also now the d-pad up lowers the bot and d-pad down raises the body.
Oh you mentioned something about the way i powered can you elaborate?
Is there a way to fine tune it? The walking i mean.
It sounds like the calibration needs to be re-done - and it also needs to be close to perfect. Ensure that it actually saves to the SSC-32U.
Regarding the power, most people just use a 6V battery rather than a much higher voltage battery and a regulator. What you are doing is not wrong, just different.
Power:
When walking in high speed the servos’s can easly draw up to 10 Amps. In some bot’s I use a 6V NiMH battery for the servos and a 9V battery for the board. In others I use a 7.4 lipo with a regulator for the servos. The board is directly feed by the battery since that got it’s own regulator onboard.
Calibrating:
I can not say this enough. Calibrating is the most important thing with a hexapod! If you don’t calibrate correctly you can not get fluent movements. See the phoenix manual for more information. Also make sure that your frond and back legs are in the 60 deg configuration. Use the SSC-32 memory to store the offsets.
PWM to Angle:
It can happen that the servo’s vary in PWM to angle range. I even found that some Hitec servo’s (same type) do not all have the same conversion factor. If you take a look in the servo driver function you will see that there is a conversion factor calculating the PWM to angle. This is an average from the servo’s I use on my phoenix
It could be that this is different on yours. Try setting your servo’s to +/- 90 deg and see what PWM comes with that. Compare those values with the ones in the code.
IK:
Since you build your own bot you need to enter the dimensions of your bot. Dimensions are, length of the tibia (servo axis to tip) femur (axis to axis) coxa (axis to axis horizontal only) and all coxa positions (relative from the center of the body)
Starting pos:
The starting position can be set using the values you already found. The values are X, Y, Z positions so this should be pretty forward.
Also for some reason i cant get the lynxmotion calibrate tool to recognize that there is a board connected to it. Could it be the baud rate. Ive got the board set to 38400 does the calibrate tool run on a different baud rate.
I can use both lynxterm and the servo sequencer utility and i was wondering how exactly do you save the settings to the board after calibration? Theres a button on the sequencer at the top right but i think its only saving it to my computer.
Can you show me a pic of 60 degree configuration please?
I looked at all the code files and im not seeing the conversion factor.
I commented out all the 4dof stuff in the config file, does this need to be done in the rest of the program files as well?
Temporarily use Lynxterm (legacy software, so our apologies if there are installation issues). This needs to be connected directly to the SSC-32U.
You ten go to “Setup” and choose baud rate etc.
Once that is done, connect the board.
You can then click “Firmware” and then “Read” to see the offsets. Adjust accordingly and then click “write”.
Still need to know how to change the servo angle conversion factor and which of the files has the conversion factor. Xan’s right with out the correct PWM in the code it will just keep acting the way it does.
#define cPwmDiv 936;
#define cPfconst 538; // 900*(1000/cPwmDiv)+cPFconst must always be 1500
// 900 * 1000 / 936 + 538 = 1499.54
I also noticed un that file a couple lines that look like they define 3dof or 4dof. Do i need to comment out the define 4dof?
I ran across this in the hex_globals.h file and was wondering if it needed changed too.
[code]#define WTIMERTICSPERMSMUL 64 //BAP28 is 16mhz need a multiplyer and divider to make the conversion with /8192
#define WTIMERTICSPERMSMUL 125
#define USRINT_TIMERAV
[/code]
When i put the bot on a pedestal and apply power and hit the start button, then try to walk it, the front legs come all the way to thier most forward position. And all the femurs push the tibias (or Try) down further than ground level.
Do i need to change the mechanical limits in the config file?
Im trying to phoenix a small hexapod using MG90 servos, an SSC-32U, ps2 TX/RX pair and a 3d printed frame.
I was hoping you guys could help me finish my project. Ive changed alot of the code to match my bot but i still cant get it to walk properly so must be something i either have wrong or dont know it needs changing.
I have no problems using the single leg movements or raising and lowering the bot and even turns on the spot okish but it goes haywire when you try to make it walk. It doesnt lift the leg high enough but brings the leg down farther than it needs to go. Also the coxa rotation is way out there bringing the leg to farthest limit.
The list below are the modifications to the code for my hexapo.
The 645MG accepts a signal from 500 to 2500, not 900 to 2100. Most RC servos operate the same way and it seems odd that the MG90 would be different.
We understand why you are modifying the values in the code, but keep in mind that the Phoenix code is used as-is for a range of hexapods (different sizes and configurations), so ideally there should not be any need to change the code unless the servos you are using are either in a different configuration (0 and 180 are reversed) or the pulse range is different (to be confirmed).
Can you reiterate the current state of the robot? From what we recall, it does respond to PS2 input, and does seem to want to walk, but doesn’t walk properly? Can you post a video?
Yep i got the PS2 controller to work. All i had to do was remove the level shifter from the RX and it started working. I can make the bot sway back and forth just fine, up and down, and even the single leg functions work. But when I use the joysticks it will not raise the femur much and pushes farther down than it needs to go. It also rotates the coxas way to forward.
I can change any modifications i have done to the code back but it actually works better modified.
Im actually thinking i need to change the mechanical limits. As they are now at the front left coxa the leg swings so far out maybe if i change the limit it will swing right.
Another problem i was thinking about was the calibration tool. I know that it saves the legs positions but does it save the body configuration? So if i have it on phoenix body or ch3 body does it save that i calibrated it to phoenix or ch3?
Heres the link to the last video i made. I havent altered the bot since…
Earlier i mentioned to you that D-pad up lowered the bot while D-pad down lifts the body up. According to the code and the tutorial its reversed. D-pad up should bring the bot up and vice versa.
Now ive also been saying that the legs go farther down than they come up when trying to walk. So that leads me to conclude that the down strokes are supposed to going up the upstrokes are supposed to be bringing the leg down to ground level.
Also want to point out again that turning left or right is pretty good.
Ok just double checked everything. First i checked it using the sequencer to make sure the everything was moving in the right direction according to the slider and all is good. But when moving the stick reverse or forward causes the femurs to go down on the upstroke and up in the down stroke. So the femurs are moving in the wrong direction.
Heres a video of it on the pedestal and you can see the femurs directions are reversed…
I’m still not convinced the shoulder and knee servos are plugged in the wrong way around, but so long as you have confirmed…
In terms of the code itself, Xan is indeed in the best position to indicate what might need to be changed.
The SSC-32 / 32U would only save the offset for each servo - it does not know what each servo does or where it’s located.
Ok i dont think the plugs can be reversed, wouldnt that kill my servo? Other wise the connections are proper and have been tested many times over. The servos are definitely hooked up right according to the hex_config.h file and tested using the sequencer.
