LSS motor velocity control

Lynxmotion Servo Erector Set
, , , ,
1

Hi,

I have 4 lynxmotion lss arms that I want to control using velocity inputs. That is, my kinematic controller generates velocities which guides the end effector on a given path. I’ve been sending commands (e.g. “#1D0SD40”) to make the motors move to a given position with a given speed. However, I noted that the arm often shows jittery motion and does not move smoothly. I’ve checked my input velocities and noted that those velocities are gradually changing (i.e. no sudden large changes for the speed).

Could someone please let me know what exactly happens within the servo when a command to go to a position with a given velocity is sent to it?
What happens when I send another command to the motor before it finished moving to the previously given position? Does it stop the current motion and run the new command or simply changes velocity? If its a stop-go motion, then this may explain the jitter I observed.

The documentation for the LSS communication protocol simply says the servo will try its best to reach the given position with the given speed (e.g. with a command such as “#1D0SD40”). What does this actually mean? Is there another PID mechanism that slows down the servo when it gets closer to the target? How is the speed maintained throughout the motion?

Thanks in advance,
Eranda

1 Like
3

Hey @Eranda43,

Here are some answers to your questions/comments:

Indeed, that is quite possible and will most likely be made worse by movements that increase the torque required on the joints (mostly shoulder & elbow). A movement speed of 40°/s on a DC motor that has a typical rated speed of ~60 RPM or 360 °/s is effectively moving at 11% of its maximum speed.

As you may already know, DC motors’ torque, speed and voltage are all tied/coupled together tightly. When trying to run at such a low speed the voltage will need to be higher than that theoretical 11% since that would not be enough to actually energize the coils. The jitter that you notice is most likely due to the joints requiring more torque than can be provided at the voltage which would produce the motion at the speed you want: i.e.: jerky motion as the LSS tries to both provide the proper torque but also move very slowly while doing so (something DC motors are bad at). So you end up with the voltage going higher than desired to produce motion and then dialing back down to reduce speed. Every time this repeats you’ll get a small jerk, most likely.

The LSS uses all the parameters provided to establish a motion of acceleration, travel, deceleration and finally holding.
If a time or velocity parameter is sent with the motion command, then this will also be taken into account (target velocity in travel / duration of total motion).

This really depends on the current state of the control. If a motion is already occurring (and it is in the same direction) then the LSS will skip the accel phase and simply adjust the target velocity to match the new requirements.
If it is in the opposite direction then, of course, this will cause it to drop velocity, hit the 0 mark and switch direction.

This shouldn’t be the case (we had a fix a last year concerning this).

There is an internal controller that determines how to best reach a specific position with time/speed limits and taking into account accel, decel and stiffness settings. If you are using EM=1 all of this will apply to any command that cause motion.

I recommend you try and set the LSS to EM=0 and either use it with the default IPE/FPC values or turn those off too and get a more direct control of the LSS for your purposes.

The best option in your case may be simply to use RDM directly with H to stop motion/hold a set position.
This function allows you to set directly the PWM duty cycle sent to the motor’s h-bridge, giving you direct control of the motions. Use a positive value for clockwise motion and a negative value for counter-clockwise motion.

Sincerely,

1 Like
4

Hey @scharette, Thanks for the reply. And sorry for not replying back … its been a while lol I have been busy writing my thesis which prevented me from doing any further tests on this. Hence, I couldn’t get back to you regarding this issue.

I gave a shot at the duty cycle control method you suggested. Unfortunately the RDM commands doesn’t seem to work. When I entered #1RDM256 (for example), the motor LED simply flashes indicating something is wrong. The QMD command seem to work returning 1QMD0 when I entered it.

After sending #1RDM256 (when the LEDs start flashing) I sent #1Q command to see what it would return. All it did was somehow stop the LED flashing and return 1Q1. What do you think I did wrong here?

Note: I tried setting EM=0 before all this as well but that didn’t do anything. I did not mess with the FPC value though, could that be the problem?

1 Like
5

All good! Life, like robotics, is complex, after all! :slight_smile:

That would indicate you should update the firmware on your LSS. The newest LSS Config version should be able to do that quite easily for you.

The RDM command (once you have a recent enough firmware version on your LSS) basically skips all EM modes.
As for EM=0 not changing anything, that would depend on how you’ve tried using it. By default, in EM=0, IPE=1 and FPC=5 (IRRC). Those were the settings we found were best for most use cases.

Of course, yours may be different and you may want to tweak some of the settings. AS & AH also have an impact on motion (accel/decel) and how stiff the ending of the move is.

Overall, playing around with the various control modes should give you a better idea of how to best use the arms for your case.

One final note: when using RDM (or other advanced control modes), please be careful to leave any LSS in a situation where it is powered, trying to move (RDM > 0) but not physically moving since in those cases the energy provided has nowhere to go but the driving chip, which would heat up quickly (sometimes too quick for the thermistor to pick up).

Sincerely,

6

heyy . Best of luck with your thesis. I’m working on a similar project . Can you share your code or what you worked on . It would be of a huge help. Thank you

1 Like
7

I’ve been meaning to reply and thank for your post for a while but was always out of time. Finally I’ve found a bit of time so thanks for your post! It was very helpful and updating the firmware solved the issue of RDM commands not working.

I have a couple of comments about LSS config though which I thought would be helpful to share. When I updated the firmware few weeks ago, it changed the zero position of some of the motors in the lynxmotion 4+1 arm. This meant I had to set the zero positions manually to match the expected zero positions for the arm. However, the software makes the motor move to the commanded position with the motor’s maximum velocity. This made things a little difficult because I didn’t know what the initial position of the motor was. For example, when I set “0” as the position to move, the particular link of the arm moves really fast which can be quite problematic. In one case, this caused one of the arm links to hit the joint limit which eventually caused the motor to burn out (i.e. it’s not able to generate any torque now). I’m not exactly sure what happened there, maybe it burned out because I somehow gave the wrong joint position 3 times in a row causing to hit the joint limit and over-torque :smile: Anyway, I thought to let you know that an option to move the motor with a selected velocity could really improve LSS config.
Cheers,
Eranda

8

Hey @derbel199 , I asked my supervisor if its okay to share the code but sadly he said no. But I’d be happy to share any info I can give to help you in your project. In my work so far, I wrote a c++ serial communication node in ROS. I think @scharette has a better c++ code available now. Initially, I used a velocity controller that uses inverse kinematics, but unfortunately the robot arm was unable to handle low velocity inputs which gave jittery motion to the arms (hence the post). I tested controlling the motors directly by implementing my own PI controller, but it didn’t perform as good as the built-in PID controllers. So in the end I decided to work around the problem and control the arms using the built-in position and velocity input commands. I dunno if this information helps you in anyway, but let me know if there’s anything else you’d like to know. I may not be able to share the code, but I might able to guide you. But I suggest making a new post in the forum so the replies would be more pertinent to your problem.

1 Like
9

Glad to know that helped!

Updating the firmware can do that, yes. A good option after doing this is to use the LSS FlowArm app to set the zero position again. The software is meant specifically for the LSS-based arm and is easier to use for that purpose. See this section of the wiki.

As a side note, the LSS Config can also be used to save/load configurations of a servo. You may want to save your configurations before updating the firmware in the feature as some of them are lost (ID is conserved, though).

Concerning motion speed in LSS Config, yes they are always at full speed (by default). You can use the console to move at slower speed (such as D[pos]SD[speed in °/s] ) or first sending a SR (or CSR) command to limit velocity of moves.

The team did place many safeguards, but some (dangerous) use conditions can still cause damage if repeated, unfortunately (like any other electro-mechanical device).

This may be possible. You should tell @cbenson! :slight_smile:
That being said, the interface is already quite a bit full of options already… :smiley:

1 Like