Lynxmotion SES V2 Hexapod Robot

Lynxmotion Legged Robots
, , , , , ,
489

Again assuming you have their LSS Adapter board, the wiring:


Pin 0 of Teensy goes to logical Pin 0 of the Arduino adapter. Ditto for Pin 1
image
image943×982 186 KB

Sorry for the quick and dirty clipboard cut/paste here, you also need a common ground wire.

Also you need someway to power everything. When I am working in a rigged setup like this, I often wallwart it.
So have 12v plugged into the Adapter board.

Note: However it shows the +5 and 3.3v on the Arduino Shield pins, however this board does not connect those pins up to voltages from this shield… So it is not setup to power the Teensy. The V pin does however get the voltage plugged in to the shield.

So my board then has it’s own power conversion DC/DC down to 5v to connect teensy. But in startup mode I don’t worry about that and instead simply plug the Teensy into computer and use that for the logic…

Hope that helps.

490

@kurte would you be able to upload the latest to the BETA hexapod Github (new folder)? We can start fresh from there which would be nice.
https://github.com/lynxmotionbeta/SES-V2-Hexapod-Beta

491

I’ll try to do that… :wink:

492

I just pushed up the library plus made some edits to change from Serial to Serial1 in examples…

Actually I changed them to use LSS_SERIAL which I defined as Serial1.

Later may go back and set default different if AVR…

493

@kurte Nice and clean. Thanks!

494

Hi All,

I was playing with the LSS to see if I could stop the motion using current sensing. I just gathered a few values before I could stop the motion using current sensing.

Current Sensing.
First tried incrementing the servos in smaller (100) and larger steps(400) to see how much current it draws. I was using a modified version of my Query code. I also wanted to check how accurate the position value is feedback.
the blue trace(value) is the commanded position whereas the orange(pos) is the value read back.

Increment by 100

Positional feedback accuracy
image
Current sensing
image
Looks like the current is fairly same except when there is direction of motion change.

Increment by 400
Positional feedback accuracy
image
Current sensing
image

In both instances the position value lags by one step. The error increases as the increment size increases. May be this can be made more accurate but I am reading immediately after commanding the servo. The baud rate is 115200. Should I increase it ?

Then I thought of adding a cardboard arm and checking how can I get the motor to stop based on current sensing. Did some modifications to my sketch and I could see that. Apologies for my makeshift leg and the mess. I have no brackets at the moment.

20210424_114937
20210424_1149372184×4608 1.34 MB

Applied a threshold of 200mA…When the arm presses against the table I hold the servo tightly in place so it does not move. and the servo soon stops its motion
image

I really liked the voltage monitoring on the servo as it is very useful thing to not have an additional hardware/software to monitor battery voltage.

2 Likes
495

Wow, nice values! :slight_smile:

Well, that is probably due to the coils (being inductors) resisting change momentarily.

I think you may be misinterpreting the data here. The error increases as the increment size increases.

If you are sending a “D” command followed by a “QD” command to any LSS, you’ll get the current virtual position.
If instead you want to know the current target virtual position, you need to send QDT!

This will only make what is happening even truer… :stuck_out_tongue: (i.e.: closer to the virtual position of the LSS before motion gets to start).
You could also send a Q command to read the status. Before a move command (but after a move command already settled/not limp), the status will be 6 (holding). But while in motion (after a “D” command but before reaching the target virtual position, a status query should return 3, 4 or 5 (accel [increasing speed], travel [constant speed], decel [reducing speed]).

You should increase it to the fastest speed your board can take that is at or below 500 kBaud. This allows the LSS to respond faster, too. Of course, don’t forget to first send to your bus something like #254CB500000\r (broadcast ID + config baud + 500 kBaud)!

During the beta when when we were all hunting down electrical issues and other problems with the LSS, we eventually completed all the solutions we could manage. And then we thought: “what is the worse case scenario we want to support?”. That was a full humanoid with many DoF at a high rate. So we setup a test with 36 LSS using many of the longest cables we offer (many Y-cables, too) and LSS Power Hub to connect all of them. While saturating the bus completely (100% capacity) we found 0 packet loss. That was success! :smiley:
image

That is a cool idea! :stuck_out_tongue:

Good! :slight_smile:

Yes, our thought exactly! Especially because the voltage on the LSS bus is usually far higher than what most microcontroller boards can read anyway (without a voltage divider or something similar), so this makes it trivial to read these values quickly.

496

Thanks @scharette

Yes … I agree…

I probably need to understand this part a bit better. What is a virtual position ?

I don’t think the “QDT” command is supported in the current version of the library. Do you want me to add this to the library code as
getPositionTarget ?

yes :stuck_out_tongue:

Thanks for this. I will read up aa bit more and experiment with this

That is awesome… !! Really cool! When was the beta for the servos and when were these servos released ?

1 Like
497

Thanks for the information @kurte. Quick and dirty is still quite good and very informative. I will try the Teensy next. I was having some fun with Arduino and the motors. This is the first time I am using motors which actually talk back to me :crazy_face: I was using the MG996R Tower Pro servos on my hexapod which when they move sounds like there is sand inside. Still good for someone like me on budget constraints I guess.

Here is the video of me stopping the servo travel based on current sensing. Added some LED colour change to show when the servo has stopped.

1 Like
498

The beta was done before the release (of course), maybe a bit more than half a year of total active time?

The release was, hmm, in May 2019 if memory serves? :open_mouth: :thinking: @cbenson totally knows this better than I do I’m sure! :smiley:

The blog says 2019-04-30… https://community.robotshop.com/blog/show/lynxmotion-launches-their-new-smart-servo-motors
The GitHub says 2019-05-09… https://github.com/Lynxmotion/LSS_Library_Arduino/commit/485745ef716c3be88e736341a91c4448f14cf3ba

So I guess May 2019 sounds like a good estimate after all! :smiley:

1 Like
499

Ah! And the launch video is 2019-04-29… hehehe!
Totally posting this here because it is awesome to watch again! :slight_smile:

3 Likes
500

The launch vide is pretty cool. I saw it on the robotshop page recently. Really amazing! Just curios though. How do these compare to the dynamixel servos. AX-12 or whatever. Those are very expensive. I guess Phoenix code uses that but as I said earlier I have never used any of those at all.

1 Like
501

For obvious reasons, capability comparisons probably best answered by RobotShop :wink:
Short answer - I think they are both good servos!

Costs… Depends, AX-12 sell for about $45, or their newer versions with about same And likewise about the same price of about $45 for their newer XL430-W250, they also now have some cheaper XLs as well… But then their prices jump up quickly for higher end servos like the XM ($230-$350+), and higher…

Hookup - Their servos work in half duplex mode - So the data is only flowing one direction or the other… They have two versions. Either normal TTL or they have RS-485 versions which allow longer distances (never tried them)

Firmware capabilities - Again I have only started to play with these for a bit, so hard to say. Some of the things I wish these (LSS) servos supported, was more ability to talk to multiple servos at the same time. But some of this could probably be enhanced by whoever is currently responsible for the servo firmware.

That is for example with Dynamixels I can send out one packet that says: On the following N servos, I wish to set the a few properties like location and speed, and they all act when the final checksum is received and verified by each servo. Likewise with protocol 2 servos they have the ability ask N servos for data, and each servo in that request waits for the previous servos to respond and they add their response…

For the first part we again had that capability with the SSC32 which they LSS servo communications is based on:
That is we could do things like: #1P500#2P400#3P600T250
And in this case the SSC-32 received all of this message and updated those 3 servos to start moving to their new positions to be completed in about a quarter of a second.

Again I have not seen the LSS servos firmware, but I would think it would not be hard to have each servo looking at these messages and see that they were mentioned, save their values in some local memory and only react when they receive the final CR…

Likewise I am not sure how hard it would be to allow you to send out query requests, like what is your current position, and speed… and send out this request in our case to all 18 servos and each servo when it hears this request, will try to try to make sure there is no collisions and recover when there is? My impression is you maybe can send multiple requests for the same servo without waiting, but must wait until all responses have come back from that servo for you might try a second servo?

But maybe not a big issue if we can run the servo baud rate fast enough?
Note: I am currently running my LSS servos at 250000 baud and I run my Dynamixels at 1000000 sometimes higher

Note: I have had servo drivers for the Phoenix code to work with Dynamixel servos for many years now, including some with the newer Dynamixels.

Also the code started off with a driver for the Lyxmotion SSC-32 as the first versions of this code was setup to run with the Lynxmotion board: http://www.lynxmotion.com/p-840-botboarduino.aspx which a couple of us designed and
was more or less an Arduino UNO crossed with a Bot Board 2… And ran on the Lynxmotion Phoenix: http://www.lynxmotion.com/c-117-phoenix.aspx which was designed by @zenta which is where the code base got it’s name.

I also had versions of it running directly to PWM like servos using a modified version of Servo library. Also had version that ran on Orion Servos (Basic Micro for a short time sold some robots…) And I know a few others have adapted as well to some other servo controllers, like ones from Pololu…

Sorry message probably too long again.

2 Likes
502

I think the best LSS to compare here is the LSS-HT1. It is far cheaper than those and offers very similar features to the 200-300 USD range of servos of Dynamixel. Plus I’ve personally tested 3x LSS-HT1 at 25% dynamic torque for 6-10h (with only passive cooling from ambient air!) and none of them burned up, got damaged or did anything else weird at all! Lets just say I would’ve been impressed with 1-2 h of non-stop use, you know? :smiley:

My favourite idea on this would be if the LSS added a second ID, the “group ID”. That way when sending commands, instead of only 1x ID and broadcast ID, you could also specify a “group ID” and all servers that have a matching ID would use that command. Of course, like for broadcast, they shouldn’t reply to queries though! :wink:

To be fair, the main difference with the LSS is that you would do: #1P500\r#2P400\r#3P600T250\r which effectively costs you 1 character per servo in the buffer you send out. I think that at 500 kBaud you would hardly notice the extra 20 µs per servo you want to update :smiley:
And at that baud rate the reaction time between the first servo and the last would be a few hundreds of µs to 1-2 ms at most! :slight_smile:

Something I’d like to see in the future would be support for a binary command block update. Maybe along the lines of (where DBB would be D for move command and BB for “binary block”):

  • form 1: each ID is specified explicitly

    • #254DBB[uint8_t; number of servos (n)][(uint8_t + int16_t) x n; servo ID and desired position pairs]\r; in this case n would be 1-127;

  • form 2: only the first ID is specified explicitly and then all others are assumed to follow from that one incrementally. So, if the first ID is 10 and n = 5, you would send commands to servos with ID=10, 11, 12, 13, 14;

    • #254DBB[uint8_t; number of servos (n)][uint8_t; first servo ID][(int16_t) x n; desired positions]\r; in this case n would be 128-255 where the number of servos is actually n-127; each position in the array applies to its respective servo ID (in incremental sequence starting from the first ID specified).

See my comment above about timing! :slight_smile:
That being said, of course I think that’d be great to have proper group commands again with the LSS protocol!

I think the word you were looking for was lovely! :slight_smile::+1::heart:
Like this:
Sorry message probably too long lovely again.

:smiley:

503

I think the question has multiple answers depending on which series of Dynamixel you compare the LSS to, and if you compare the LSS-ST1/LSS-HS1 or the LSS-HT1 (a massive beast of a servo for the size and price!)

For some of the older or lower end Dynamixels, I think the LSS-ST1/LSS-HS1 are a great value and offer better stuff. Especially if you include all the supporting brakets and other modular parts. When compared to the newer X series or whatever it is called, I think depending on how you look at it they are pretty equal or at the very least in the same range of capabilities but maybe a tad more expensive. That being said they do have all metal gears and metal cases, which is freaking awesome! ( @dialfonzo your work is an inspiration on that! fly like a bird LSS because they are so light! :smiley: )

As for the LSS-HT1, I think it compares favourably in capabilities to much more expensive ones with a similar torque and voltage range… except again it is all metal and this little power horse can run for a long time at 20-25% of it’s maximum torque! Quite the impressive creature!

I’ll admit I’m a bit biased when it comes to servos since I really like the LSS series a lot… but yeah, oh my god that protocol is easy to use without much effort. Like brain dead. And super easy to debug with a logic analyzer too, since it is raw ASCII right there before your eyes. No need to create a decoding plugin or script or whatever. You can just flat our read it right away.

@madmax
Just note this is my view of the situation concerning smart servos (i.e.: personal opinion). But yeah, I think it is grounded in reality enough to be useful! :smiley:

504

Thanks @scharette

Maybe I am wrong, but my impression if before this lets say all of servos are at position 1500 and you output the command:

#1P500\r#2P400\r#3P600T250\r

This command would cause servos 1 and 2 to move at their top speed (or maybe controlled by PID) to their new positions of 500 and 400 and servo 3 would be setup to move to position 600 and get there in a quarter second.

Whereas on SSC-32, the Time modifier would apply to all three of these servos. But again could be wrong.

Actually 10 years ago with the SSC-32 (not u) there was a version of the firmware that supported a binary command setup. http://www.lynxmotion.com/images/html/build177.htm

It is always interesting with things like timing. With some variations of the Phoenix code or other Robots, it was interesting that there were those who said they could feel a difference in smoothness of movement between times with using the group moves where at times I experimented with trimming how many servos to output data to to only those who actually will move. Just the timing of the extra bytes transferred…

With the earlier Phoenix code including I believe all the way to version of the BAP code, where we timed it out to when to output the next movement command, and to get the timing correct, we would output everything earlier on, such that we only needed to output the final CR to execute the command at the right time.

Now back to playing. :smiley:

1 Like
505

You are right, but that is a design choice. This is one of the situation where some group move/ID type of setup would help.
That being said, if instead you did:
#1P500T250\r#2P400T250\r#3P600T250\r
Then you get a similar effect, but still slightly different than what the SSC-32[U] does/did since they all have independent controllers. Even if they did all start perfectly at the same time you’d still get (super small) variances over time. Definitely using 500 kBaud will reduce delta in starting time though.

Yes, I saw that. Some are still in the SSC-32U, too, if I remember correctly.

Good points! :slight_smile:

Yeah, I can see that be the only option with that kind of hardware.

Reminds me of hand coding paths in assembly for AVR to do VGA output :stuck_out_tongue: so all the timings would be perfectly equal! :smiley:

:+1: Yes! :smiley:

506

Morning all,

Note: I was having issues with the Serial signals at 500kbs, so currently running at 250kb. I don’t think it is a Teensy issue as I have run Dynamixels routinely at 1mbs and at times 2mbs and have tested at higher speeds. Maybe should double check that the transistors for level shifting can go that fast. I am pretty sure that they should. BUT

As you said there are always trade offs and design choices… So nor more back to task at hand.

For the fun of it, I will try making a merged version of @zenta sketch with my fixed point sketch that was sort of adapted to this hexapod and these servos and with either PS3/PS4 support and/or XBee support, in my case probably for Arbotix Commander and see if it will stand up :smiley:

Again unclear on best approach to use with the beta github. As a start I will probably put this under something like:
Kurt’s Experiments or the like. Then once others hopefully some others can have some fun and rework all of the math and coordinate systems and desired coding and rewrite and/or refactor things, hopefully then we can come up with a project layout that works for all involved.

But for me pass one, PLAY :smiley:

1 Like
507

I’d say make a folder in the repo for each contributor.
In those contributor folders, they can make new subfolders for each project they work on.
When working on a subfoler, make a new branch to keep things separate (one branch (or more, i.e.: one for each group of updates) <> one project subfolder updates).

This method/process would probably keep things clean without too much overhead.

1 Like
508

@kurte your message are amazing. I mentioned this earlier but I am always waiting for you to reply. I know that I am always going to learn something new from it… :wink: and I am never disappointed.

That seems very handy.

Wow that is nice!!

Interesting information and good to know this!! Actually, I had attempted a serial PWM controller(purely software based) without using any external chip. I don’t know how but I stumbled upon an article for the original article where Michael Dvorsky wrote about the SSC in the circuit
cellar magazine March 2006 issue it was titled Low-Cost Serial Servo Controller

Nice! I did this on my hexapod. Directly talks to the servos with PWM. Software PWM based on the 16 bit timer. LSS are something else though. Really like those!

Thar is really impressive!!!

Well you could take this up a notch and have group subscriber id which can basically be the id of individual servo within a group and then you can get a group to respond to queries. That might have a use somewhere.

I do love them actually. But I am surprised you have not mentioned the LED’s. I think that was genius, whoever thought of that. Its so damn awesome… gives an extra error detection if a servo malfunctioning or behaving weird. I can easily see a code which is continuously monitoring current for each servo and blinking when it jumps high than usual. Such a treat for visual inspection. Other wise you have to hook up a bunch of leds with some and have some coded values for error detection and keep referring the code or hook it to a serial port with messages coming out… RGB LED are great addition i must say to these LSS, gives them a character as well!

That does sound good. I like that !

2 Likes