I just commented it out and it compiled fine…
1 Like
Thanks, I commented it out. Atleast there are something going on here. But looks like some corrections are need since it doesn’t move as it should. I’ll start looking at it when I get time. I need to go making pizza’s for my kids.
BTW, the PS4 gimbals are much better than the PS2. Much more linear values.
I agree as well. Much better than PS2…
Warning in the USB Phoenix code in my github project I pushed changes to that version of the phoenix code that now has some of the Servo Interpolation stuff like the old bioloid code did.
I think I left it on by default,
But if I did it right the ‘a’ command in debug terminal will toggle between this and servos doing it, although I maybe busted it in that I set to EM=0 and other code is calling moveT so timing is ignored…
Will play more later, but need to do some other stuff.
But feel free to play 
@zenta - @madmax - @xan and all
Going through the gait code and seeing a few things that are a bit confusing (basically don’t know what I am looking at). Trying to sort out units for the leg angles - are they in degrees or in 10, 100, 1000s. For instance if I look at the following equation:
CoxaAngle1[LegIKLegNr] = (((long)Atan4 * 180) / 3141) + (short)pgm_read_word(&cCoxaAngle1[LegIKLegNr]);180/pi is the usual conversion for rads to degrees but here it looks like Atan4 (180/(pi*1000). So wondering what the 1000 represents and what are the units for the coxa angle. Kind of see that all over the code base:
//IKFemurAngle
FemurAngle1[LegIKLegNr] = -(long)(IKA14 + IKA24) * 180 / 3141 + 900 + CFEMURHORNOFFSET1(LegIKLegNr);//Normaland see things like
lAtan = GetATan2(CPR_X, CPR_Y);
TotalZBal1 += ((lAtan * 1800) / 31415) - 900; //Rotate balance circle 90 deg
lAtan = GetATan2(CPR_Z, CPR_Y);
TotalXBal1 += ((lAtan * 1800) / 31415) - 900; //Rotate balance circle 90 deg
}
//--------------------------------------------------------------------
//[BalanceBody]
void BalanceBody(void)
{
TotalTransZ = TotalTransZ / BalanceDivFactor;
TotalTransX = TotalTransX / BalanceDivFactor;
TotalTransY = TotalTransY / BalanceDivFactor;
if (TotalZBal1 < -1800) //Compensate for extreme balance positions that causes overflow
TotalZBal1 += 3600;
if (TotalXBal1 < -1800) //Compensate for extreme balance positions that causes overflow
TotalXBal1 += 3600;So wondering if this is causing us some problems, i.e., units.
Now you may wonder why I ask. Well in the CFG I have angles set in tenths of a degree, 900 = 90degs, but if I change it to degrees instead of tenths of degrees the leg only moves a few degrees.
So that is why I ask what are the units of the angles from IK/BODYIK? Help in understanding - maybe one day I will figure it out.
@cyberpalin To be honest I haven’t looked or used the original Phoenix code at all. I had starred at it but it was not too clear for me… Looking at it it seems like the angles are all in 10s… so 90 is 900… on basis of that the 180 had to be 1800 and the 3.141 had to be 31.41. However, I am not sure why it is done like that… For better precision is only a guess.
I haven’t done it this way. However , having said that I have also started looking at the Phoenix code esp. the LSS_PhoenixUSB_Joystick code recently in order to get it working so any answers from @xan and @zenta is what I would be looking for as well…
my code for IK is like below… I have resorted to use float and standard libraries wherever possible
float thetaC;
thetaC = TO_DEGREES(atan2(z,x));
where TO_DEGREES is a macro
#define TO_DEGREES(angle) ((angle) * (180/M_PI))
On another note…to all interested … I remember @kurte saying we should get this converted to floats… Should we decide about this and update the code to floats? Or are we trying to get the original one to work first as a first step ?
@madmax - I agree. After looking at what I posted my impression was that it was in 10’s but then what didn’t make sense was 3141 or 31415 for PI which I don’t understand.
Problem is don’t know what I don’t know. Wondering if it is based on the PEP spreadsheet which is used to get the gaits/PWM positions? Have to wait for @zenta and/or @xan to confirm I guess
EDIT:
The other version I was working on that I can not seem to get work is the float version in @kurte’s repository and mine: Zenta_LSS_Phoenix_PhantomX_float. Which does just angles in degrees and floats. But was having problems with getting it to work. Maybe I have to go back and mod that for the wired controller.
Morning all (@cyberpalin @madmax @zenta @xan) and …
History: Back in the ealry Phoenix days, (and the older old hex), we were working with the Basic Atom Pro in basic. To speed up things in the Version 2 code Xan converted everything over to fixed point math, which was a lot faster on those lower end processors. When I converted over to C++ to run on Arduino, I kept the code, as sort of as close as possible to the basic code, for a few major reasons:
a) Again running on a real slow processor Botboarduino (Uno clone with extras, but same processor, which a few of us cobbled together) Could say more about it but not overly relevant here.
b) Needed to get it done quick… Jim really wanted to stop using BAPs… Again can say more but…
c) Wanted Zenta (and Xan) feel comfortable. As most of the major ideas, like balance mode and the like were coming from mostly Zenta. And he at the time was sounding uncomfortable transitioning to Arduino…
Later I had a version of the code base I converted back to floating point. And was mostly working, Kept meaning to get back to debug a few things, but I pretty sure that is where Zentas newer code started from and I am pretty sure he fixed those issues, but then completely diverged and he was completely reworking the gaits and the transitions between them.
This updated code base is the one we really should make work!
Under the SES-V2… github in my directory I have two versions:
Zenta_LSS_Phoenix_float - which I was starting conversion… But stopped
Zenta_LSS_Phoenix_PhantomX_float - which I was playing with more until other joined in. I was going to try to do it in steps…
a) Some gratuitous changes: Convert header files to cpp/h files - the usage of code before in header files was for the ability to use same code for multiple hexapods with different settings… Arduino is not the greatest for that.
Also wanted to remove lots of the globals and make then instance variables… I had it building.
b) Have it build and run using DIY remote and Dynamixel Servos, such that hopefully @zenta - can maybe be able to run it and say still works. i.e. I did not completely screw it up…
c) Create a USBHost Joystick version of input controller that works enough for as much of the basics as possible. Then again hopefully maybe Zenta could try it out… Plus I setup one of my PhantomX robots to test with. This was partially there… Need to pull over our more up to date stuff into the classes and see how it is working…
d) work on the LSS servo driver as well as the hex file for it, such that then test on these hexapods… Was hoping we can do c) and d) concurrently.
But then ran into roadblocks, kept having some issues with these servos. Messages not working right and getting errors. Moves were not working as I thought they should… So I then reverted back to test program to get a better understanding of how do these servo work.
Does this make sense?
Kurt
Morning all (@kurte @madmax @zenta @xan) and …
I already have a working version (kind of sort of was still in the process of working out kinks) with what @kurte had originally as I think I mentioned before. Right now I am in the process of updating with the new USBHost joystick and the S/W interpolation that @kurte put together. So maybe later today I will post the updates so we can use that as the base code going forward.
Please be advised though that I removed all dynamixel and commander code for now just for testing. Was planning on putting it back in later.
Quick FYI: As I mentioned recently, I was going to maybe add a method to allow you to control how long does the sketch have to wait on a timeout. Hopefully most of these occurrences of timeouts will be minimized with updated firmware, I still liked the idea of having the sketch have the ability to set their own timeouts…
As I mentioned I did create a new branch of the LSS library, with these changes and this morning I issued a Pull Request.
I also updated the LSS library that is in the SES beta github project under libraries.
Note: so far I only updated the LSS test program to call it, where I set the time outs for 20ms for a response to begin and 5 ms for additional characters. This helped minimize when packets got garbled and the call would timeout after 5ms instead of 100ms.
Next up will be to add it to Phoenix code… Hopefully the floating point version 
N that case let’s keep Zenta_LSS_Phoenix_PhantomX_float as the base one to get working for all and that way we all can start from a common code base.
I have seen that with Arduino and never really understood why an header got to have code in it. Not normally done this way.
Also looking at the code a bit more it certainly has lots of global variables especially around calculating the angles… and also others. I would strongly go for instance variables… Should we have open requests in github assigned to us so we can work on independent chunks. That way we all can work on independent chunks and get it committed for others to use…
Will that be on the Zenta_LSS_Phoenix_PhantomX_float code base ?? Let me know… I can switch to that one for testing and optimising…
With the wired one … LSS_PHOENIXUSBJOYSTICK I can get the bot to move but it is all wonky and really weird.
Video 1
Video 2
One thing I have noticed is that the servos… especially femur ones cut out, is it because of current protection setting ? the serial message says cut out because of servo status… something like that… I will copy the proper message later …
Need to understand and play more…
1 Like
Yes it will be. As @kurte said, he and I are playing with right now to get it working with the new code that he and I added over the last couple of days
By the way thanks for video’s - had a feeling it was going to be wonky. Kind of hampered with only having one leg - all I can confirm is code working - you all have to test on the full up hex’s. Sorry. Looks like some of the legs moved and some didn’t – you sure you have the servo assignments correct. Either way the zenta - float version will be the new base once we get it released.
Hi @zenta and @cyberpalin and others):
I keep wondering if we would all be better off if for the short term if a few of us maybe concentrated on my logical b) and developed the simple USB controller code that controlled a sufficient percentage of the capabilities of your DIY remote and try to it out on a servo driver that we understand and know that should work.
Zenta it would be great if it worked well on at least one or more of your hexapods that you showed in your video about the current code. Would like to have it running on at least one of my PhantomX as well.
CyberPalin do you by chance have any Dynamixels? If so but not enough for a hexapod, I will check to see if I have some others. Probably could cannibalize the quad that I probably won’t work on again and probably some from an arm.
Alternatives might be to see if we can easily adapt to RC servos using SSC-32. I could probably retrofit my Phoenix with an SSC-32. It currently has an Basic Atom Arc32 on it. Would then rig any Teensy board we have with USB and a serial port to it… Or use USB as well.
Again wondering if this makes sense? Also if we do temporarily divert down one of these approaches, wonder if we should take it offline and maybe handle by email and/or something like google chat?
Thoughts?
1 Like
Hi @kurte and @zenta
That may be a good idea to make sure all the gait code is working with the dynamixels first since that is what it was what that code was designed to be used with.
Unfortunately I don’t have any dynamixels or hexapods to play with. In the past my focus was on getting wheeled/tracked rovers working autonomously using sensors like sonar, LIDAR, and even the OpenMV camera. Most those projects were posted on the Teensy forum using the Teensy 3.5. My latest one using LIDAR uses a T3.5 as a motor controller for the old Rover5 chase and the T4.1 to do the obstacle avoidance stuff.
But think that may be a good idea for your guys to work on, I would follow along on google chat. When thats sorted out should be easier to get it working with the LSS’s, then you would know if its a servo issue or an algorithm issue.
I’ve done some testings and some minor corrections on the the LSS_PhoenixUSBJoystick code.
Have focused on to get translation correct. For some reason all tibia servos except the front left is off by 50 deg or so. But when debugging the angle values it looks ok. So I don’t get it.
The femurs seem to move correctly doing up/down translation. I often get a notice of some servos going limb and reset at startup and sometimes some coxa servos move in wrong direction.
But most of all I’m confused why 5 of 6 tibia servo have wrong positions.
You mean to test the new T4.1 board using a PS4 on one of my Dynamixel hex using my latest code?
2 Likes
Wondering if that has to do the zero position that I set up. I made one very large assumption. The zero position looks like the one I posted several post ago where the centerlines of the servos are basically lined up and the tibia points straight down. So I set the offsets based on that.
In code we config all the servos with the same offsets and right side as CCW - left side CW in the following table:
leg_info_t legs[] = {
{"Left Front", {cLFCoxaPin, LSS_GyreClockwise, 0, 600}, {cLFFemurPin, LSS_GyreClockwise, -104, 600}, {cLFTibiaPin, LSS_GyreClockwise, -137, 600}},
{"Left Middle", {cLMCoxaPin, LSS_GyreClockwise, 0, 600}, {cLMFemurPin, LSS_GyreClockwise, -104, 600}, {cLMTibiaPin, LSS_GyreClockwise, -137, 600}},
{"Left Rear", {cLRCoxaPin, LSS_GyreClockwise, 0, 600}, {cLRFemurPin, LSS_GyreClockwise, -104, 600}, {cLRTibiaPin, LSS_GyreClockwise, -137, 600}},
{"Right Front", {cRFCoxaPin, LSS_GyreCounterClockwise, 0, 600}, {cRFFemurPin, LSS_GyreCounterClockwise, -104, 600}, {cRFTibiaPin, LSS_GyreCounterClockwise, -137, 600}},
{"Right Middle", {cRMCoxaPin, LSS_GyreCounterClockwise, 0, 600}, {cRMFemurPin, LSS_GyreCounterClockwise, -104, 600}, {cRMTibiaPin, LSS_GyreCounterClockwise, -137, 600}},
{"Right Rear", {cRRCoxaPin, LSS_GyreCounterClockwise, 0, 600}, {cRRFemurPin, LSS_GyreCounterClockwise, -104, 600}, {cRRTibiaPin, LSS_GyreCounterClockwise, -137, 600}}
};Basically if servoID, Gyre, Offset, Speed (degs/sec). Not sure if this is your problem. One way to test is use the up and down arrows and if they are all the same heights/movement then that probably isn’t it.
EDIT: Maybe its something in the Hex_cfg.h file as well?
Hi Kåre (@zenta) - Sounds familiar. In my first porting of code, I had things sort of moving ok, and then at times one leg or two servos did not respond… Other times I am not sure… That is one of the reasons I then went back to the real basics with trying to understand these servos.
Also why I wondered if it would make sense to step back a bit to and try some stuff out on reasonably known hardware like one of your setups. Does not need to be the T4.1… Don’t remember which board you are using? T3.? If you have T3.6 in one, and if it does not already have something soldered into the USB pins.
You can always simply solder in some pins to go out the top for the USB and use something like:
It does not have to be through PJRC, it is simply a PC remote USB connection…
Then the same code should work… Or also can do with T4, but that those pins are harder to use.
In the mean time if you have known changes that help make things work, please post or push to github or…
Kurt
Hi all.
I figured out the problem with 5 of my tibias. The fault wasn’t the code, but the internal offsets on the servos was way to large. Initially I had them mounted them with tibia flat out and then set the new 0-offset to the vertical position. Meaning a offset of about 600. For some lucky reason the LF tibia was configured as I used to. I ended up setting the other 5 servos to default values and then moved the horn to a closer orientation. And did a final offsets.
The code seem to work correct now. The hex translate and rotate and kinda walk. But there are some minor issues with the servos. They jitter a lot and they are not very precise in position.
And in some cases some of the servos (coxas) decide to rotate in wrong direction.
But we are in the correct direction though.
Yeah, I really need to figure out the github stuff. I ended up uploading a zip file since I wasn’t able to pull all the files when I wanted to get your latest update.
Btw, here is a video:
6 Likes