Agree with @madmax. If you can share would be nice - think we are all curious. Please keep us posted as we are making some progress on getting the hex to walk but comm issues and issues with moveT are causing us to develop work arounds. Think you got that from the posts.
Yep - they can get overwhelming if you don’t keep checking. But think its the only way to describe and show issues. But as you said its all good
Good (Time in your time zone) but early here (5am):
Good news. I am assuming that this fixes what I an assuming was some form of race condition when the servo was generating the response. At least from all of the traces on the Logic Analyzer I have seen it has all of the tell tales of a race condition.
So hopefully in this test run of test program to move legs through a few positions, we see in the RED line where I toggle every time this run hit it:
Note in the mean time I am also hacking the library to hopefully minimize this. Assuming it works, I will issue Pull Request to library which allows the sketch to set the timeout value… 100ms is way to long for majority of cases. I am planning on having library with two user settable timeouts, One for start of message (waiting for *) and second for waiting for follow on characters. I will probably try sketch with 20 and 5. So you won’t end up with really really large gaps of time.
Oops back to communication wish list, that I am hoping that new firmware might have…
Faster baud rates? Right now using 250kb but 1MB might help, depending on if the servos can make use of the additional bandwidth… Which follows to next wish list item:
In the above LA capture you can see just large of gap of time there is between from when the last bits of data were transmitted by the Teensy to when the servo first starts responding (Time marker 0). You can see after the Teensy receives a response from servo until it starts to issue next query, timing 1 and timing 2 shows how long one response the servo from the servo took to transfer the bits, which is actually a lot less time than the first wait!
As a second part to this throughput, it has been suggested that if you have multiple values you wish to query from the same servo, you can speed it up by issuing all of the requests up front and wait for the servo to respond to all of them.
So far I have not seen much if any difference.
Again using same test sketch on my github project:
Query servo 1 for a set of registers, command: 9 1
Again debug output: Total Time: 26959
So this one did show a very slight difference. But it does not show any real differences consistently.
Again feel free to play with the test sketches. This one is:
@madmax - Yes I do like my Logic Analyzers… I am sort of ashamed to say I own three of them! One of these years I should probably sell off one of them… I have the older logic 16, which I still use when I need to debug or document something with more than 8 pins. Like recently up on PJRC with Camera using 8 parallel Input pins plus maybe 4 or 5 other control pins… I also have the same Logic 8 that @cyberpalin has, which is great. But I also have the Pro 8, which I use most of the time, which allows me to do a lot of fast captures… That is the runs in this message where captured at 500M samples per second. Which really helps find things like the race condition, and also I use long fast captures to capture USB traffic, and even this is not fast enough for higher speed USB.
I think I will continue this on another posting… This one probably has enough stuff in it.
Again @cbenson = great news on firmware update. Let us know when you have one to try out!
Plugin is available in the Logic 2 software, just click on Extension and it should be in the list called “LSS Bus Analyzer” and install it.
Could that explain somehow the differences you get at the end ?
I don’t fully follow you on the explanation but that’s because I’m not a programmer. (sorry, i keep saying that)
@kurte I’ll start by apologize, I have probably forgot to answer everything.
Just tested the commands:
Motion: SD / CSD - tenths of deg/s
Modifier: SD - tenths of deg/s
I’ve changed that in the Wiki as well, nice find and thanks for pointing it out.
In EM0, as you found, there are no other way to restrict the speed but to change the position sent.
I don’t have all the details, but it’s a race condition in the serial processing where it can disable the TX buffer.
A separate DMA was used to fix this from happening, but i don’t have the details.
Thanks for posting this. Taking a quick look through and looks like its doing something like @kurte was suggesting earlier that he wants to do for the hex. Still going through it so may have more questions later.
FIRMWARE UPDATE/ EM1
Know this is a long shot. But getting moveT working in EM1 should be on the critical path for a firmware update! Seems like no one is using EM(1) since it is not working correctly so they are using EM(0) with work arounds. Guess this is really a question for @cbenson. If not it won’t be resolved in the next firmware update guess we don’t have much choice but implement a EM0 method/work around as @kurte suggested along the same lines as done in mechDog.
Guess I have said enough now back to work on the gait code.
Thanks @cyberpalin and @kurte for posting the LA Link. I will try and get one let see…
Also, I have now forked @kurte LSS_Test_sketches repo. On starting it says no servos found. Do I have to set the LSS ids in a particular order ? It says servos not found.
Cmd: c
Servos for Leg Left Front **NOT found**
Servos for Leg Left Middle **NOT found**
Servos for Leg Left Rear **NOT found**
Servos for Leg Right Front **NOT found**
Servos for Leg Right Middle **NOT found**
Servos for Leg Right Rear **NOT found**
Yes and No the answer is at the moment the Motion Controller is useful to go from point A to point B without spamming the bus.
It’s useful if you want multiple servos to start and stop at about the same time and have the motion profile.
Yes at the beginning of the sketch there is a set of defines for servoIDs that you can change. You can also do a cmd “5” that will find servo’s for you.
Thanks for the answer, that’s pretty much confirms what we are seeing. Just adds some addition work to implement and change the code accordingly. Too bad, would have been so much easier otherwise.
Thanks @dialfonzo (@cbenson)
You might also want to update the documentation for the modifiers and mention in them if they are supported in EM=0 mode… Like we already know that T and SD do not. What about current Hold
More on EM=0 and EM=1 as I digest the postings since I started this one
I strongly agree with others here where there are some very serious differences in what we might expect the firmware of the servo to do and what it actually does.
Personally I think some one needs to step back and come up with what you expect the usage patterns for your servos for different setups and how the firmware could best be tailored, to meet those expectations.
IMHO the most major usage pattern for your servos would be SSC-32 compatibility. Which is why I have suggested having a test setup where you run code written for an SSC-32 on both SSC-32 and on these servos, and they should run nearly identically with for most part nothing different in the code except which serial port you are reading and writing to.
Isn’t that what everyone one of our programs is trying to do? Yet all of the code bases have had to go to EM=0 as they could not make EM=1 to work.
So again if it was creating a new version of firmware, beyond obviously the highest priority task of making sure you have fast reliable communications. The next priority for me would be to how can I make these commands work for me.
First thing would be to understand I seldom want my servos to go From Point A to Point B and stop… More likely I want to go from Point A to Point B and continue on to Point C with a new timing.
To do this you probably need to tell the servos there next location/timing before they start the ramping down…
Like maybe: #1D150TQ250\r
Where TQ means to queue up the next move… Not sure if Queue is just double buffer or multiple… But then your servos should hopefully look at what the next position/time is and can change their profile to smoothly transition to the next location…
Sorry could say more and maybe clean this up a little, but my dogs are after me to get dressed and take them for their morning walk!
You might be on to something here Kurte. You could use the speed commands with the servo and make a velocity controller in the Arduino. Control the servos via velocity instead of position. It may require less updates, but it would certainly solve the servo wanting to stop at the end of a motion command. You could have smooth motion and whatever motion you want to shape in your controller.
@kurte You’re whole post is basically exactly my wish list. lol. I did report a bump by sending multiple Q commands at once but until now (with Saleae) I had no way to actually see what was going on. Poor @cbenson, we’re all armed to the teeth with logic analyzers. I’m hoping for faster comms too.
Edit: I also face Linux buffer latency…so my bump might have been more substantial if it pushed stuff through linux tty or FIFOs faster.
just to be clear, I didnt have any issues with EM1…EM0 just fit better with how I wanted to control the servos. I was implementing passive and active compliance, gravity compensation, etc and I have lots of dynamics equations working so I wanted the motion planning running on all servos as a whole. I never played with T or S modifiers though…come to think of it, I dont think these modifiers even existed yet when I started. OMG it’s been too long. lol
that is fixed 
