Lynxmotion SES V2 Hexapod Robot

@zenta - @kurte - @madmax and others

I just pushed a change to the LSS_PhoenixUSBJoystick program in @kurte repository. It does 2 things:

  1. On start it defaults to S/W Interpolation and “A” will then toggle without having to do it twice. Besides I get way too much jumping around without it turned on.
  2. I made all the servo config settings (Offsets, Gyre, Speed) set in the Hex_cfg.h file for now. @zenta’s config is used by default but easy enough to change without editing the table. Table is still used for now.

How this helps setting up your operational hexapods.

Thanks @cyberpalin. that is great stuff. Will sync up in the morning. As I mentioned wondered if we can dynamically update how often we update the servos.

Thanks again @cyberpalin , It has been fun these last weeks being able to make progress and bounce things back and forth.
Likewise it has great playing along with @zenta.

I know how much more fun you would have if you could actually see a real hexapod walk, instead of just one leg.

As I suggested in a previous post:

So as I mentioned a few days ago, I might be able to find enough spare parts, that I could send you, to make a sort of Frankenstein PhantomX… As I mentioned I had a quad that I don’t ever use, plus other parts… I think I have found most everything needed, without having to cannibalize any other robot… It might take me a few more days, before I round up a few more pieces and able to get it to the Post Office, but I do think it could be fun!

I have the extra V2 Hex Frame… Mine or currently V3 (metal) all of the main parts for 5th leg, plus almost all of the parts for 6th… Still searching to find the few missing pieces… The picture also shows the ArbotixM board that they used to control the hexapods… I typically don’t use them anymore as I sort of avoid 8 bit AVR boards, although this one at least choose an AVR chip (Atmega644p) with 2 hardware USARTS and more memory than the UNO…

Sound like fun?

3 Likes

Wow Kurt - thank you a lot. Can’t say how much I appreciate it. Will be fun to test out the changes we are making instead of using a single leg and then waiting to see if those changes are good for a whole hexapod.

And yes it a lot of fun going back and forth with you with this project as well as Zenta and everyone else. Never stop learning.

No rush - take your time in getting it ready. Still have plenty to do with the existing code including debugging the PhantomX code which I am doing on and off.

2 Likes

Hi All,

Firstly, apologies for the diversion. I wanted to actually see how the code that I had developed runs on this hex and was getting a bit impatient to see the spider running around… So I did a bit of integrating my code with LSS library and got it running at 4 a.m. last night… Unfortunately, I had to sleep and my phone’s memory was full so that gave me a reason to sleep :slight_smile: I did a video now to see how fast I could get it run just for fun!!
It uses the sin/ cos trajectory generator calculating joint angles using IK for each position update… Teensy is fast…I have become a fan now… I want to do some time profiling … might do it when time permits…

I have not integrated the controller code yet. I was using PS2 on my hexapod(I don’t like it at all) and I don’t want to use it… So it is hardcoded to just walk straight for now. I have a few videos I did with it going side ways and rotating. I will upload that later. Also, I will upload the code in the SES-V2 repo… Will need to clean it up a bit…

Here it is… (I can make it go faster even more… but that causes severe leg banging and I was afraid I would damage the servos and as i cant stop it… I have to run behind it to catch it… )

Again, I really apologise for this diversion / distraction. I am chopping my way through the Phoenix code and would like to do some pull requests which are quite basic… i.e. braking up configs etc. I was getting a bit lost in the gait code. There is still so much to learn from the guys here esp… @kurte, @cyberpalin, @zenta and others… I will post some questions soon…

I see there have been more updates as I was writing this… That is really a very kind gesture @kurte Fantastic!!! :+1: Hopefully @cyberpalin would be able to see the baby walk now… :smiley: ) Awesome have fun… !!!

4 Likes

@madmax I literally laughed out loud! Started the video… waiting… waiting… expecting to see it stand up or something… waiting… and suddenly it jumps up and runs away! This is exactly what a spider would do if you see it relaxing on the floor, then touch it. I’m tempted to edit the video and add you poking it with a stick… :rofl: Well done!

1 Like

hahah… yes…I planned it that way… :wink: I am glad you enjoyed it !

I am not good with video editing… If you are really tempted a lot, I can send the video over google drive or something… That would be a cool edit…!!

Very cool that you got it running around with your code, congratulations. Felt good right!

Will definitely have fun - am having fun now - I like challenges always have.

Just to summarize for you the changes we made to the Phoenix code:

  1. @kurte’s S/W interpolation code is now default on start up and you can switch to moveT’s by using the ‘A’ command.
  2. I made all the leg config’s (gyre, offsets, speed) defines in the hex_cfg file.
  3. There is also an option that if you uncomment it, it will use whatever config you set up using LSS_Config app. Its in the Hex_cfg.h file.
  4. @zenta 's leg configs are used by default but you will see what I am using that I have commented out.

I think that’s about it since your last download.

As for the PhantomX-float code, we are still debugging that one - something not right with S/W interpolation yet. But getting closer.

But as @zenta we are concentrating first on the Phoenix code base to work out things out.

If you have any questions just ask.

1 Like

Looking good and fun!
So you’ve written your own gait algorithm? Great work!
Would be interesting to take a look at your code when I get time.

Also, slow walking would be interesting to see how well code and servo perform.

1 Like

@cyberpalin and others, I just pushed up some changes to the sketch in the LSS interpolation code, that I put in conditionally. Still need to fully test.

But the code looks at how long of a time your move is plus how far the servos move and tries to compute some number of cycles to do it and then compute the time per cycle…

Also added option to turn on output servos even if they don’t move.

Also fixed a minor PS4 detection code detection if Bluetooth or not… Added check if the Bluetooth object is active or not. If not can not be BT…

Will test more but have other tasks… Options are up near top of the cpp file

2 Likes

Thanks @zenta Means a lot coming from you!! I wouldn’t take full credit for it. I have referred to a couple of others and then did my own implementation but used the concept of using the sin and cos equations to get the trajectory.

I would like to write my own gait engine…one day. I have started off with something but it is very early stages… I still have tons to learn… I am still finding my way thorough the Phoenix code… I have too many questions…

The slow walking is to robotic in my code… I need to see how to smooth it out…

I will surely upload the code… I need to just get some cleanup as I simply got it from my Atmel studio project and mangled it on a hackish sort of way over into Arduino…

Again thanks for the encouraging words!!

2 Likes

@madmax - I meant to mention I enjoyed the video as well. Always fun to see different approaches.

As I think I mentioned before, I know that Trossen Robotics member KevinO implemented a ROS hexapod : GitHub - KevinOchs/hexapod_ros: ROS Hexapod stack with functioning 2D and 3D mapping.

He also started off with simple Sine wave… But modified it later. It has been awhile so I don’t remember all of the details. I mainly remember some fun conversations about how the timings worked…

@zenta @cyberpalin @dialfonzo and all - I pushed up some more changes to the LSS_PhoenixUSBJoystick sketch up in my LSS Test project.

Some of the changes included: Improvements to my variable interpolation FPS code, which I think is working a lot nicer now, and I turned it on by default. I also left on the code that output all servos all the time…

In addition I just pushed up some changes to the joystick code, in that I now added the the PS2 like where the Left and Right hat buttons will speed up or slow down the walking speed. I believe I also put in by default a slower speed…

Code has been pushed up…

Sorry I did not create a video… More fun to play with it. Let me know what you think.

Also have other things to do today, so got to run.

EDIT: Sorry maybe phrased poorly above :blush: What I meant to say is that enjoy watching others videos, but don’t personally like making them.

2 Likes

Thanks a lot for the kind words @kurte . It really means a lot coming from you as well. I remember you mentioning the ROS one before but I never looked into it. I will have a look and see what is done there.

Also, I have now merged the latest code into my fork. I can see that when I start the hexapod I keep getting these messages inspite of me holding it in my hand and no legs touching the floor

EnableServos: Servo 7 reset due to status: Limp(1)
EnableServos: Servo 13 reset due to status: Limp(1)
EnableServos: Servo 8 reset due to status: Limp(1)

also the servo motion seems smooth until I keep it on the floor and then it becomes a bit choppy/jittery… Let me test a bit more…

2 Likes

@madmax - you are welcome. Sorry I am probably going to take day off… Hands need rest.

I also see a lot of these type messages. It is after I try to verify all servos are on, I ask all of them their status, and often times a few of them return status such as this… If I find I am in this state I reset the servo(s), and then if any I put in a 3 second wait.

But as for why? Don’t know

As for floor being choppy. Will look more in a day or two, unless of course someone else finds the issue.

Kurt

@madmax - glad you are testing it out more. You might try cycling between timed moves and moveT using the ‘A’ command to make sure which mode you are in.

I’m not 100% up to date on the thread (rl keeping me quite busy lately), but depending on what EM mode & settings you are using, I suppose you’ll need to tweak some parameters if your motions have different loads in one situation vs another (i.e.: free motion in the air/very low load vs under normal load on the ground) since that will affect response.

I haven’t cycled between this yet just using the default ones for now… the default is EM0 right ?

However I have now added some time profiling… basic one for the entire loop

looks like when the robot is in power off state the time for loop run is 20ms

***madmax: LoopTime: Start time: 5061 End time: 5081 Difference: 20
***madmax: LoopTime: Start time: 5081 End time: 5101 Difference: 20
***madmax: LoopTime: Start time: 5101 End time: 5122 Difference: 21
***madmax: LoopTime: Start time: 5122 End time: 5142 Difference: 20

then after switching it on and the robot just holding Initial position it takes about 300ms

Which seems a lot considering it is a 600MHz core and all the maths(atan sin, cos etc ) is from look up tables !!! Do we have some wait time somewhere which causes this ?

Then I wanted to check what the servoMoveTime is set to so added some more debug:
While robot is off…

***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 150
***madmax: LoopTime: Start time: 16837 End time: 16857 Difference: 20
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 150
***madmax: LoopTime: Start time: 16857 End time: 16877 Difference: 20
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 150
***madmax: LoopTime: Start time: 16877 End time: 16897 Difference: 20

then after switching on the robot using the PS button

***madmax: LoopTime: Start time: 27537 End time: 27837 Difference: 300
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 27837 End time: 28137 Difference: 300
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 28137 End time: 28437 Difference: 300
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300

Then I went to the rotate mode and got the following timmings

***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 69379 End time: 69600 Difference: 221
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 69600 End time: 70100 Difference: 500
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 70100 End time: 70121 Difference: 21
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 70121 End time: 70620 Difference: 499
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 70620 End time: 70641 Difference: 21
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 70641 End time: 70863 Difference: 222
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 70863 End time: 71083 Difference: 220
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 71083 End time: 71583 Difference: 500
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300
***madmax: LoopTime: Start time: 71583 End time: 71606 Difference: 23
***madmax: Before assigning PrevServoMovetime ServoMoveTime is: 300

and it does jump around quite a bit but the ServoMoveTime does not seem to reflect this. Does it mean we are sending position updates before the servo completes its move ?

So what I am trying to understand here is

  • What is our control loop (loop() function ) processing time ?

  • Why are some calculations taking so much time ? Is it because the code is accessing EEPROM while doing calculations ? It might be good to cache the EEPROM data in some variables as part on an initialization routine so the loop time is reduced?

I am thinking aloud here so please bear with my questions if they are silly… Still digging through…

Hi All,

We have the experimental firmware version (369.00.00) ready for you to test.
It’s already in the LSS Config.

Release Notes:

  • Fixed race condition in communication resulting in occasional corrupt responses. Most prevalent but not limited to the QN command.
  • Support for baud rates higher than 250k. We’ve certified 9600, 19200, 38400, 57600, 230400, 250000, 460800 and 500000 baud but 750000 and 921600 have also passed initial testing. Only these exact baud rates are recognized by the servo.
  • Improvement in query response time of around 15% at 250k baud and much greater now that higher baud rates can be used.

Baudrate increase it will be… <(°.°)>

NB1: The update will bring back some default values (not the ID, this is saved) like the Baudrate (115200).

NB2: Already done many tests through an automated testing and no errors up to 921600. As where I’m doing the same tests with firmware 368, errors start to happen as soon as 230400.

5 Likes

@dialfonzo @cbenson Sounds good, will update soon. Probably tomorrow… Mostly taking today off.

2 Likes

@kurte - Everyone need a bit of time to relax. I wanted to make sure the firmware was ready for you (all) to test it in the weekend if needed.

2 Likes