Lynxmotion SES V2 Hexapod Robot

kurte · June 11, 2021, 4:20pm

Yes I don’t leave home with out them!

But for those who who want something cheaper, there is software to make a Teensy act like a logic analyzer.

There are also so cheaper clones you can find up on Ebay or the like, that most can use some Shareware software, which is fine. I personally don’t like those who then try to rip of Saleae by directing their customers to download their firmware…

Linux latency: Awhile ago (maybe 8-10 years), I was playing with running the hexapod code under Linux, starting specifically with RPI as to try to start understanding Linux and later to try ROS. The code was setup to plug some other board in to the servo controller into the RPI and ran into the latency issue you mentioned. But the interesting thing was not with all of the boards.

Turns out that it depends on what controller chip that board was using and you mainly run into that with boards that use FTDI chips as they use a different servo driver. Warning memory might be wrong on names:

But if you plug in a board using FtDI: it will create a /dev/ttyUSB0 or USB1…

However if you plug in a board like a Teensy or most newer Arduino which have a built in USB (either directly or with another ATmega…), then they show up as: /dev/ttyACM0 …

Side note: I hated that sometimes my device was /dev/ttyUSB0 and other times /dev/ttyUSB1 so most of the time i use udev rules to create an alias.

Again why I mention all of this, is I was able to shorten the latency on FTDI devices by having the code call tcdrain as soon as I posted the end of the message. This forced FTDI to write the partial packet then.

However I found that calling tcdrain on /dev/ACM0 like devices was very detrimental. It is like the underlying device driver has not implemented some IOCTL and so the code goes, well if I wait long enough then pretty sure it all transferred by now…

So you might see if you are running into something like this…
Not sure if it would help or not, but this code is in my Raspberry pi github…

github.com

KurtE/Raspberry_Pi/blob/master/BioloidEX/dxl_hal.cpp#L37


unsigned char wpd_readDataToggle = 0;
#endif
int	gSocket_fd	= -1;
long	glStartTime	= 0;
float	gfRcvWaitTime	= 0.0f;
float	gfByteTransTime	= 0.0f;
int 	g_use_tcdrain = 0;	// assume we don't need tcdrain. 
int dxl_hal_open(int deviceIndex, float baudrate)
{
	struct termios newtio;
	struct serial_struct serinfo;
	char dev_name[20] = "/dev/ttyDXL";
	uint32_t int_baud = baudrate;
#ifdef DEBUG_WIRINGPI
	wiringPiSetup () ;
	pinMode (WPD_WRITE_PIN, OUTPUT) ;
	pinMode (WPD_READ_PIN, OUTPUT) ;

kurte · June 11, 2021, 4:31pm

Looks like you are about ready to play along

The only problem I see is your desk looks far to devoid of clutter.

dialfonzo · June 11, 2021, 4:41pm

Yeah… It’s up and down as i’m testing So many things here and there.

I’ve loaded the CODE and i’m getting the menu in Serial. Should i use something like the Teensy interface you discussed before (which i don’t remember).

I only have one leg 2 / 4 / 6 connected at the moment for initial testing.

madmax · June 11, 2021, 4:59pm

I have used the normal arduino serial monitor… and it works fine… I found the command 1 - centre all servos to be useful. That way I can make sure teh robots somewhere hereabout what @xan had posted some posts before…

the i an j are useful ones and the m … move all servos…

dialfonzo · June 11, 2021, 5:24pm

Doh…!
Obviously works better on the right baudrate.

cyberpalin · June 11, 2021, 5:29pm

Wonder how many times I have said that when I forgot to change baud or turn put the power plug in - which is even better.

Glad you are playing along. Its actually nice to see the legs going up and down.

While its still a work in progress and if you have a ST7789 and DS4 controller you can play with the LSS_PhoenixUSBJoystick code ( LSS_Phoenix_BT/LSS_PhoenixUSBJoystick at main · mjs513/LSS_Phoenix_BT (github.com)). Again still a work in progress. Not sure I updated @kurte’s repository - maybe should do that now.

EDIT: Unfortunately I can’t test all the legs so when I make changes @kurte usually tests them with the full up hexapod based on my 1 legged creature

EDIT2: Almost forgot - before you run and of the gaits or stances run gaitconfig first. It will set the session configs correctly for left and right side (CCW or CW, Offsets and maxSpeed. Otherwise you may get some strange postures

dialfonzo · June 11, 2021, 5:33pm

I wonder if we should have some docs setup.

I can easily create some images showing the ID’s of each joints and maybe a posture where you need to do the ZERO and put them in the second post of this thread ?

Also maybe a google doc with some issues to report so we don’t dig into the thread all the time ? (again i can setup a shared folder of gDoc)

kurte · June 11, 2021, 5:39pm

Sounds good.

Sorry been busy with other stuff:
Like just finished making half gallon of green juice, with mostly leafy greens using a slow Omega juicer…

Now need to spend some time doing some fun things like start cleaning up enough for some company…

dialfonzo · June 11, 2021, 5:48pm

To keep things “look alike” I was going to suggest using the same ID as it was in the SSC-32 setup.
Can i generate those images but on the new platform with that and do not disturb all of your codes ?

phoen09
phoen12
phoen10

Edit: I feel like the “ZERO” position should be all legs in close position and brackets bottoming out. That way there are now guessing.

madmax · June 11, 2021, 5:51pm

I was going to ask this next… Thanks… I will play with this sketch…i have DS4 and a CSR v4.0

cyberpalin · June 11, 2021, 6:03pm

That’s pretty much my setup as well

But you will need a ST7789 - haven’t converted to displaying messages to the serial monitor yet. Was going to do that next but in middle of other things.

cyberpalin · June 11, 2021, 6:09pm

You should be able to assign any ServoIDs that you want in the HEX_CFG.h file for your hex without disturbing the code. However to your next point.

Changing the Zero position you would have to edit the LSS_Phoenix_driver_lss.cpp file to setup the 0 position and offsets for your setup since @kurte and I already set that up - its in one of the previous posts. Mostly, rigth angle to zero postion. Heres the code snippet that you would have to change:

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}}
};

I am sure that is clear as mud

EDIT: Aligned with zero deg for coxa, right angle for femur and I think it was parallel with the angle? We did a whole discussion on the best way somewhere it all those previous posts when I first started assembling and testing my leg.

dialfonzo · June 11, 2021, 6:36pm

I see two things, the way it was in the past which is 90deg angle, make sense for code and multi platform compatibility.

However maybe we can have a CFG for platform, that make it easier to Zero.
That would essentially be an offset from the above values i guess.

cyberpalin · June 11, 2021, 7:03pm

Ok how to write this. From what I have seen over the years and what I saw with the assembly instructions for the Phoenix from Trossen what you would need to do is to keep the initial assembly to something simple with pictures. 90 degrees is makes an easy reference point to set the brackets. Then in software as @kurte mentioned you could fine tune and set the final configurations.

The basic idea is that the legs should have a 0 position that looks like this:

At least I think so. Then the CFG can be configured correctly. This is how I have it set up since it seemed reasonable at the time. Think I posted but didn’t get many takers.

dialfonzo · June 11, 2021, 7:10pm

That’s what was the standard for RC servos which need to be centered physically.
Since the LSS is multi-turns and has no mechanical centering to do, I think it’s easier and more accurate to move the robot legs until the Bottom Out and call that the zero.

cyberpalin · June 11, 2021, 7:18pm

To be honest that up to you on how how you all want to define it. As long as its consistent and stated clearly. Then CFG could be set up from there.

The hexapod program that we are using is all based on what @zenta and @kurte put together so it does have a lot of flexability since initial positions are based on x,y,z positions of the leg which I know I probably have set up wrong.

They would probably be better at saying what’s the best way to approach it. By the way I did the config through LSS_config just for reference.

kurte · June 11, 2021, 7:22pm

Glad to see several people progressing !

Sorry I have a few other things going on today. So just taking a quick break:

There have been a few different ways suggested for centering… Both here and elsewhere.

Either the way described for previous RC servo setups like the Phoenix. Luckily you don’t have to remove the spline…

Or lay it totally flat with legs pointing straight out… Again can work. But can still be off slightly especially if you have rubber bumpers or not rubber bumpers… Or maybe a wire on the bottom.

Either way to get the gross offsets is fine with me. But do think you need some form of fine tuning.

There a partially implemented (more like partaially debugged) code to do servo offsets. Will get back to. This one is aiming you for horizontal and or right angles. from the the servo horns… As to again have clue if totally correct. What I have not done yet is to figure out how/where to store the fine tunings.

Then could be a automatic fine tuning function, that sees the pressures on the different servos and if necessary to adjust one or more legs up or down… Also could be enhanced if you had a tilt sensors…

Again sorry got to run!

But at this point probably KISS…

cbenson · June 11, 2021, 7:25pm

Poor @cbenson, we’re all armed to the teeth with logic analyzers. I’m hoping for faster comms too.

No worries, we’re all trying to make the servos better. RobotShop / Lynxmotion has sold quite a few servos since they launched and although only a small percentage of customers give any feedback, it has not included anything related to baud rate, errors etc., so having people here who are prepared to give feedback (and help contribute to the solution) openly are appreciated.

dialfonzo · June 11, 2021, 8:03pm

Here are two different IDs setup, let me know what you like the most.

Legacy Phoenix
Each leg with a starting digit

0 voters

Legacy Phoenix:

Each leg with a starting digit:

kurte · June 11, 2021, 8:41pm

Sorry I personally don’t like either… Actually what the code bases that both Kåre and myself have used is actually closer to the PhantomX, which is arbitrary: In the current scheme all of the Coxas are in consecutive order (maybe a minor but) then all of the Femurs and then all of the tibias.

The one possible exception was in my schemes I have avoided using Servo ID 1 as with older AX12 servos there were times when a servo might somehow reset it self and set up as ID 1. So I logically moved the servo id to another number. Then at startup we look for all of the servos, and if we find one missing and we have a servo #1, we renumber that one to the missing one…

But again Arbitrary. The current IDs are in the Hex_CFG.h file:

#define cRRCoxaPin      8   //Rear Right leg Hip Horizontal
#define cRRFemurPin     10   //Rear Right leg Hip Vertical
#define cRRTibiaPin     12   //Rear Right leg Knee

#define cRMCoxaPin      14  //Middle Right leg Hip Horizontal
#define cRMFemurPin     16  //Middle Right leg Hip Vertical
#define cRMTibiaPin     18  //Middle Right leg Knee

#define cRFCoxaPin      2  //Front Right leg Hip Horizontal
#define cRFFemurPin     4  //Front Right leg Hip Vertical
#define cRFTibiaPin     6   //Front Right leg Knee

#define cLRCoxaPin      7   //Rear Left leg Hip Horizontal
#define cLRFemurPin     9   //Rear Left leg Hip Vertical
#define cLRTibiaPin     11   //Rear Left leg Knee

#define cLMCoxaPin      13   //Middle Left leg Hip Horizontal
#define cLMFemurPin     15   //Middle Left leg Hip Vertical
#define cLMTibiaPin     17  //Middle Left leg Knee

#define cLFCoxaPin      1   //Front Left leg Hip Horizontal
#define cLFFemurPin     3   //Front Left leg Hip Vertical
#define cLFTibiaPin     5   //Front Left leg Knee

I am not using the hack here I mentioned… They are also hard coded into my test program. But again just a set of defines. And if any one wants a different scheme, not a big problem. Simply change all of the defines. You can use my test servo programs and use command 7 and change them to match which ever standard that is desired.

Again it really does not mater to me any which way. Except, I wonder is this something to spend time on now or better on other things.

But again to me no big deal one way or another.

Edit: but if I were to choose one of the two above I would choose the Phoenix numbering? It goes along the line, that if you can take a Phoenix, and then build it with LSS servos and still use SSC-32 and it works the same and if the Servo firmware could fully emulate the SSC-32, than the same program might work the same when switching to serial mode… Not sure if that makes sense?