The LSS specifications state that the no load accuracy of the HT1 is +/-.15 deg at 12V (depending on CAH). I have been seeing a good deal less accuracy than that. I’ve tried CAH values of 4, 0 and -4. I’ve slowed the servo down (SD = 30) and lowered the deceleration (AD = 10). Each time it stops, it seems to jump. It can be seen and heard here: https://www.dropbox.com/s/yfam3visubei7cl/TRIM_20191003_154201.mp4?dl=0. (The PCB on the horn is just for initial positioning.) After finding an initial “0” point, I do an MD-1200, then MD300 repeatedly. After each move I read the motor position (QD). With CAH = 0, I get motor positions of -117.5, -90.7, -60.3, -30.4, -0.6, 29.8, 59.0, and so on. With higher CAH values, it seems to jump more on stopping, but the accuracies are about the same. Lower CAH values make it jump less, with lower accuracy. Anyone have any thoughts? Please?
Appreciate the question and we’re here to help. CAS affects all travel parts of the motion controller (including holding), whereas CAH affects the final holding position. A low CAS value means the servo allows for more angular deviation before making corrections. A high CAH value means the servo will not allow for much deviation before making corrections. The end position accuracy is therefore much more related to the CAH value. A transition between a low CAS to a high CAH causes a jump, which we are actually working on at the moment and will provide in a firmware update. Two additional improvements are being done for travel at low speeds, and travel at low torque. The angular values obtained were from the IMU? Can you query the servo’s position (QD) to know the value it reads from the onboard position sensor (and at which CAS and CAH values)? This will give us a better idea of what the servo thinks it should be doing. CAH4 gives overall good results for end position.
Appreciated and sorry for any inconvenience.
Hi @cbenson, thanks for your reply.
I only use the IMU for my initial position. After that, I use QD to measure position. What I was doing was: Tell the servo to move 30 degrees (MD300). Query the servo status (Q) (every 20mS) until I got back 6: Holding. Then I would query the motor position (QD). This morning I tried adding a 1S delay before querying the position, thinking that maybe I was reading during some transient movement when it first when into hold mode. I think I was correct on that because I get much better results, now typically only +/- 0.3 degrees.
I am also wondering if I am making a mistake repeatedly telling it to move 30 degrees, instead of telling to it go to actual positions, i.e. D1200, D900, D600, etc. When I tell it to move, does it read its current position then move from there, or does it keep track of where it is supposed to be and move from there? For example, if I start at 0, tell it to move 30 degrees, then 30 degrees again, does it know after the first move that it is supposed to be at 30 degrees exactly and move from there, or does it see that is at, say, 30.4 degrees and move from there, accumulating errors?
I am going to experiment some more and report back. Thanks!
Hey @jmadsenee!
Thanks for all the details about your tests.
Indeed, the very first step where the motor reports it is in holding status be many ms before it is done moving to its final position. Said differently: it reports it is going to now hold and then proceeds to do it. Depending on load and speed and CAS/CAH settings this may take one or more “control task” iterations. Of course, this takes a bit of time, too. Most likely less than a full second though!
The MD command actually goes from the target position when used repeatedly, not the actual position therefore resetting the error instead of accumulating it between moves. You can actual request the target position from the LSS using #[id]QDT\r, which will return you the current target in 1/10°.
I hope these details help you understand better what is happening in your tests.
Sincerely,
FYI @jmadsenee,
Just did a quick test with MD commands being sent while the motion is still ongoing from a previous MD command. Ex: send #[id]MD3600\r and before the motion is completed send many more #[id]MD3600\r. From my results, the motor ends at the right position (3600 x # of commands) at the end of the motion.
Hi @scharette,
Thanks for the great info! I didn’t have too much time to work on this today, but I am working on quantifying the error vs. parameters. So far, still seeing errors of 0.0 to 0.3 degrees. Hard to tell how much I am changing things using different parameters, so I will come up with an automated test to average the errors. But that will have to wait for a week; I’m going on vacation! I’ll report back after 10/14.
John
Hey @jmadsenee
We’re working on multiple fixes simultaneously and integrating all of them in a release. This will take a bit more time before it is released (as a recommend firmware). The main reasons is that we do an extensive battery of tests on each model of the LSS before every release.
That being said it is possible to test experimental versions of the firmware. It should be noted that none of those are tested and can wreck a robot assembly pretty quick if you encounter a bug. Therefore they should always be tested on a single LSS first without any load to ensure it works well for your setup (how you control the LSS) first. You can find those in the Firmware update menu by checking the “Experimental” checkbox.
Mandatory second warning: I highly recommend that you wait for a properly tested version to prevent any issues.
Sincerely,
P.-S.: One of the new set of fixes we are currently testing involves making the LSS work better with fast position updates (such as every 20 ms) in smart (serial) mode while having smoother motions.