Controlling Multiple LSS Servos

Lynxmotion Electronics & Software
, , , ,
1

Hello:

Is there any sample code out there for controlling two LSS servos independently with a Mega2560?
All the library functions work fine assuming a servo ID of 0, ie:

LSS myLSS = LSS(0);

but not if I attempt to change a servo’s ID to 1. For example, in the setup() loop I’ll type the following:

myLSS.setServoID(1);

I reset the servo (or cycle power) to save the change. Then I run some new code creating the object myLSS = LSS(1) this time. I think this should mean that any functions I call, such as myLSS.setColorLED(), should target servos with the ID of 1 now. However, the servos ignore the command.

Any help would be greatly appreciated.

1 Like
2

UPDATE: Solved the problem. Turns out that the setServoID function only changes the ID of the servo object in software, but doesn’t actually write to the EEPROM inside the physical servo.

I inserted the following new function into LSS.cpp (and a matching declaration in LSS.h):

void LSS::writeServoID(uint8_t id)
{
LSS::genericWrite(this->servoID, LSS_ConfigID, id);
}

Assuming myLSS currently has a software ID of 0 and I call myLSS.writeServoID(1), this sends a message like “0CID1”, which convinces all servos with ID 0 to change to ID 1.

1 Like
3

You are indeed right, the code found here does not write the new ID to the servo.

The idea was that people would either:

  1. Use the LSS Config to set the IDs of their servos individually before creating an assembly. This is required for the LSS Arm, for example.

  2. If they really need to change the ID programmatically, they’ll do exactly what you did above.

The reason for not having a function like this in the library is twofold:

  1. Even with the wear-levelling for the FLASH in the current code (virtual EEPROM system) that is in the LSS, if someone accidentally decides to do CID in a infinite loop (where the CID# changes and with no delay/stop of any kind), for example, it will quickly wreck the FLASH used to store configurations. It felt like a good idea at the time not to include such a function for this reason.

  2. There is no real reason to programmatically do ID changes with the library. It is a setup things that you should, in theory, do only once. Firmware upgrades conserve ID, too, so that does not erase them either.

Anyway, I’m glad you found out how to do what you wanted.

Sincerely,

4

Thanks, that was a great explanation for why the function wasn’t included.

1 Like
5

No problem! :slight_smile:

And this is why, even though the library and its examples don’t use it this is still in the header & keywords files.