I recently purchased an assembled LSS-4DOF Robotic Arm from Lynxmotion (via RobotShop). According to the product description, the unit was manufacturing tested.
I am working from a Linux (Ubuntu 22.04) system and attempting to communicate directly with the arm via standard serial ASCII commands over /dev/ttyUSB0 (using 115200 baud).
I have verified:
USB detection and device enumeration (ttyUSB0 present).
Correct Linux serial drivers (ch341 loaded).
External servo power is connected and stable.
Serial connection opens successfully using picocom or screen.
When sending standard ASCII queries (e.g., #254Q + Enter), the device responds only with unreadable characters (garbage data).
I have clinically tested different baud rates (9600, 57600, 250000) with no success.
Only at 115200 baud do I receive any characters â but they are not valid responses.
I do not have access to Windows, and therefore cannot use the FlowArm software.
My goals:
Confirm if the unit is stuck in a special mode (e.g., FlowArm protocol, bootloader).
Understand if there is a way to reset the LSS servos or LSS Adapter back to standard LSS ASCII command mode.
Proceed with direct ASCII control from Linux or Raspberry Pi.
Any help or official guidance would be greatly appreciated.
Welcome to our RobotShop / Lynxmotion communityâŠ!!
Looking in your order you got the âAssembledâ version of the 4DoF arm which, indeed, should have been tested.
However sending a â#254â command address all servos as the same time and they will also try to answer all at the same time which gives you unreadable characters.
Try to talk to One servo at a time based on the IDs on the wiki.
Ex: #1Q
Thank you so much for suggesting that, I didnât know the group commands and slots, super helpful, lots for me to learn.
All servos talking to me nicely, (except the ID returns nothing), but as I was trying to figure out the positioning calibration on servo1 (the base that turn the round table), it yanked the cable out or the cable got caught. Sorry, beginners error, despite I was being very careful, not triggered happy. As it was stuck, red light flashing, I powered off and had to gently moved the base (connected to the servo) to untangle the cable and base. That resulted in now that, the servo 1 when I query its QP, gave me -2500 or 2500 after each stop irrespective where it stopped. It does not know where it is. I managed to figure out to start it at 0, then 90, 180, 270, 360, clockwise and anticlockwise. Then it moved completely fine but it still lost its own positioning to report back. My goal is to programme all 5 of them in the future, so I need reliable understanding on the max, min ranges of it etc. Anyway, I had a good search on the Lynxmotion wiki (sorry I am not very good in finding things there), I think the best solution is to install a VM with Windows, then try to configure it using the LSS configure software, and hopefully reset the servo 1 mapping back to how it was (not sure if I can or not). As there are 5 of them, I think I need that configuration software if I am stuck again. Thatâs where I got to now.
A long answer to your question, I would love the diagram showing slot setup vs ID comms, but I am still at baby 0 step. Hopefully remove the -2500 and 2500 positioning that would be a nice start.
You had an issue where the base moved and got caught.
The red flashing is over-torque protection and should just recover by a reset or you cand send a âLIMP / #1Lâ command.
When you query QP on the base 1 servo, it gives you either -2500 or 2500.
The QP was made for some backward compatibility with RC Servo code, you should use QD to get the real position. If the motor move and stop itâs position encoder work so itâs software related. Maybe you found a bug for the QP which is almost never used.
Understanding on the Max and Min range
What do you mean by that ?
Explain what you try to achieve and maybe I can help out.
You might want to change the Origin Offset (essentially the zero) as well as Angular Range.
Thank you so much! Yes, you are right, I did not realise red flashing was the over torque protection, good to know itâs there. I did change the offset to 0, it was not too bad at -8. The QD command makes more sense now, reporting accurately every tme.
The min and max value is because I am still trying to orientate myself the degree, which way it sweeps, just learning about the virtual angular angle now. So, I want to make sure when I hooked up all the servos (full 4DoF), I wonât accidentally send an overshot command to one of the servo and damage it. So, to establish what is the max and min for each servo (I might be wrong, just in my simple head for now), when I code it up later, I will make sure all commands must be within that safe range zone for each servo. For example, I donât need servo 1 to be 4800 sweep anyway, I think the min max range would be around -45degree to + 45 degree, so the cable wonât yank out again. The speed is currently set at 60. I will look to slow it down a bit. So, my immediate goal is just to get the min max range like this for each servo working within a safe range. Nothing fancy just yet.
Btw, I did manage to install VM Window and got the LSS configuration software running on my Linux. Definitely not without a fight though, as it is Windows.
Can I please ask the LIMP / #1L function? Does it disable the servoâs torque? Once itâs disabled, can it be enabled again? Also, for the soft RESET, back to default values. What are the default values?
If you manually move the servos, you can do an M ove in Degrees (relative) command which is going to move From the current position.
That way you can move just a little and understand which way itâs turning.
If the rotation is not intuitive you can change it as well with G yre Direction
The L imp function will indeed disable the servo making it free turning. Any new commands will get it back moving or you can also use a H alt & Hold command.
Reset will not default the servo, just a soft reset / reboot.
You can do a Default Configuration but it requires a Confirm Changes right after and be prepare to assign the ID back as itâs clearing everything.
You might want to explore the * Command List table on the wiki.
Thank you for the super tips again, I will definitely try as you suggested. I have been actually looking at the command list table, some are a bit cryptic for me. More for me to explore. Thank you for your time, making my first post on this community so welcomed.
I am new here, I bound to have more questions later. Can I continue here or do I need to start a new topic? Please advice. It will all be obsessively about this 4DoF arm I am very happy to put a new seperate topic though. Basically, I am exploring LSS commands at the moment. Then I will write a few scripts to automate it for me, so I can save some fingers pressing the cutecom! Once I got further, I would like to get my Raspberry Pi 5 to talk to it, then add a few other bits as it gets more exciting . Thatâs the general direction.
I have tested commands like H, RW, G, MD, T, all the them worked as expected, except this one:
MD+T e.g., your example EX: #1MD900T2000
This does not work, it moves MD (relative to its current position), but it does not slow down. (i.e., the same as #1MD900). However, I tried #1D900T2000 and #1D-900T2000 both work as expected. But, this only moves to the position (not relative) of course. Is there something I need to fix?
I regularly check the #1QD and #1Q, after I have done a few moves, sometimes, it return *1Q6, or *1Q8, but mostly *1Q6. And the position *1QD is always a bit off (e.g., it started off *1QD0, then after a few moves, it becomes *1QD4, this is for the 0 degree position, I use that as a reference). These behaviours are normal, right? Do I need to do CO configure the offset after a few moves? &/or every time I power it on? As I have *1Q6, do I need to do #1CO-6 in order to get this back to 0 offset?
I have not screwed the base down firmly onto something yet, I have it sat on a fairly think silicon mat, it is sitting stable but will move slightly after a few moves/a spin.
Just tested it and your are right, the T modifier do not seems to be effective over MD.
Thatâs a bug but also not something most people use (MD).
The #1Q will return the status of the servo so 6 is pretty normal, holding.
If you have a status 8 itâs stuck probably on over current / over torque. Ă
When sending a #D900 you want the servo to go at 90.0deg and the servo with âtryâ to reach it with itâs internal PID system.
Things will impact the end position like the mechanics and it could sag a bit as well so having a little difference is normal.
If your position was â0â and you get *QD0 or *QD4 you are 0.4deg away from zero which is not bad depending on the mechanics.
Just moving the servo by hand will give you greater differences, I think. No need to adjust the Origin Offset.
The origin offset is required because the sensor in the servo is capable of reading 360° continuously (i.e., multiturn).
This means the servo itself doesnât have a predefined âzeroâ point â it simply reports its current position based on its internal reading. You could technically use the default CO0 (current origin at 0) and accept the current mechanical position as your reference, coding your application accordingly. However, in most cases, itâs much easier and cleaner to set a mechanical zero that makes sense for your setup and apply an origin offset to align the servoâs internal reading with that position.
This simplifies calibration, repeatability, and application logic.
I have done some testings on 5 servos, they all move independently and nicely as I expected. e.g.,
1D450T2500#5D00T2500#3D287T2500#2D-600T2500
I then wanted to focus on just 1 servo, my goal is to stream some command down (could be an array) depending on image processor module that processed video/images. I have done a separate interrupt (#254H or just hard stop) in case things go south, all working fine. But first, I wanted to stream a short command down first like this: #5D00T2500#5D-270T2500
I notice that, the gripper was already in open state (i.e., at -270), this command got ignored. However, with the gripper stays open, I send this command down #5D-270T2500#5D00T2500, this time the gripper did shut as I expected.
I have done similar testing to other servos, they all behaving the same.
This tells me, (please do correct me if I am wrong), the execution to the command is state-dependent. I have even gave it a waiting time, before I sent down the command, still did not work. I then executed multiple commands and change it mid way (i.e., before it even finished its last command), it did respond to the latest command without delay (which is very nice!) but it has to be the opposite of its current physical state. If the command happens to be the same as its current physical state, otherwise it just got completely missed/ignored, and any trailing commands were also ignored.
Also, I notice in this batch command mode, the command at the tail end overrides the command at the front
if the commands are for the same servo.
Is my understanding correct? Sorry, it may sound trivial, but I was never intended to use it to manually send command down one by one . I was hoping to stream commands down depending on the images processed. So, does it mean I need to check its current physical state at any one point in time? or I just keep sending command message one at a time? then any trailing wonât get missed. Or is there a better way to do this? Hope this makes sense. I donât mind coding any workaround, just want to avoid unnecessarily work due to my lack of understanding. Many thanks for your kind help again.
Iâm not 100% certain I understand.
But if you send two commands on the same line, for the same servo, the last one will be the one used.
Thatâs how servos work usually, itâs not a pool of moves thatâs sent and processed internally.
You have to send your moves yourself, but you donât necessary need to look for the position if not needed.
Thank you - sorry I did not ask my question clear. Because the commands I will send down, will be automatically generate and sending/streaming down to the arm live. Your answer helped me to confirm how I should build the commands send module.
Separately, I have found some good info online in terms of the physical dimensions of the arm for each link (servo to servo), torque and other specs. Do you happen to know whether there are any mass/weight of each link? The reason I am asking this, I am intending to build a small physic model of this arm to simulate all possible positions. I have found one servo is around 74g on the RobotShop website. Do you know if each joint (the long rod bit ) what materials they are made of? If not, itâs okay.
Group Commands
Why use Group Commands?
ABR is not compatible with LSS Config software currently.
Setup Example:
Summary: ID vs Slot
I am very happy to put a new seperate topic though. Basically, I am exploring LSS commands at the moment. Then I will write a few scripts to automate it for me, so I can save some fingers pressing the cutecom! Once I got further, I would like to get my Raspberry Pi 5 to talk to it, then add a few other bits as it gets more exciting 
. Thatâs the general direction.
