@mjs513 - I did as you probably know I sent out an add to you my LSS_ test project…
Feel free to either merge your stuff in and/or PR to me or…
Again at some point could move some of this learning and tool stuff to the Beta project…
Ok just issued the PR with my pseudo RF leg gait: Added ‘g’ for simulate RF gait by mjs513 · Pull Request #1 · KurtE/LSS_Test_sketches (github.com)
I agree some point should move some of this stuff.
Oh just for the record and before I forget I configured the servos in LSS Config like this:
Servo 2:
Gyre - CCW
Servo 4:
Origin Offset: 700
Gyre - CCW
Servo 6:
Gyre - CCW
Origin Offset: 190
Used the spreadsheet to generate ripple 6 step profile for the RF leg .
Coxa Length: 5.08cm
Femur Length: 8.128 cm
Tibia Length: 11.43 cm
Used the spreadsheet to generate ripple 6 step profile for the RF leg.
This is using cbensons sample leg in his post #2 I think. I will post a graphic later today with the orientations
Thanks it is merged in 
And runs on one of the legs
At least it runs on one of them - should be 2, 4 and 6 Servo Ids - which ever one that is for you 
Just did the swap of my problematic HDD after cloning last night - seems to be working.
Wanted to ask but forgot - did you notice anything funky about the leg movement like it was real jerky and not smooth?
Yes it appeared to be really jerky.
Been busy in background answering some questions, but want to play some with it.
Unless you beat me to it 
That is to try it with changing the code from like:
myLSS.setServoID(RF_COXA);
myLSS.move(-48);
myLSS.setServoID(RF_FEMUR);
myLSS.move(11);
myLSS.setServoID(RF_TIBIA);
myLSS.move(110);
Serial.println("Position 1: ");
checkStatus();
GetServoPositions();
To maybe something like
myLSS.setServoID(RF_COXA);
myLSS.moveT(-48, 250);
myLSS.setServoID(RF_FEMUR);
myLSS.moveT(11, 250);
myLSS.setServoID(RF_TIBIA);
myLSS.moveT(110, 250);
Serial.println("Position 1: ");
// checkStatus();
// GetServoPositions();
delay(250);
And see how well it moves. The current ways set something like 5 positions where each of the
servos try to jump to their new position as fast as the servo will allow. But the MoveT, should tell
the servos to setup their move speed such that they all arrive at that new position at a quarter of a second.
Plus I am guessing that the checkstatus of the 3 servos will add something like at least a 2ms gap to each move, maybe longer. That is you just finished the query of first servo who was the last to complete, so you continue to query the other two, and then have to go back and query all three again…
Plus the time to read in all of the positions and print them.
We can help maybe minimize some of this that may help in certain cases by only asking those servos who have not already responded they are done for their status…
Maybe something like:
void checkStatus()
{
int8_t status1 = -1, status2 = -1, status3 = -1;
uint32_t statusTime = 0;
while(status1 != 6 || status2 != 6 || status3 != 6) {
if(status1 !-= 6) status1 = myLSS.getStatus();
myLSS.setServoID(RF_COXA);
if(status2 !-= 6) status2 = myLSS.getStatus();
myLSS.setServoID(RF_COXA);
if(status3 !-= 6) status3 = myLSS.getStatus();
delay(1);
statusTime += 1;
}
Serial.printf("Status: %d: %d, %d, %d\n", statusTime, status1, status2, status3);
}
Funny you posted the timing just now. Was rereading your post and was about to make some mods to sketch along the same lines. Must be reading each other’s mind. Will let you know how it works out.
@kurte
I gave it a try and definitely works a lot smoother. Not its getting to final position fast enough though have to make another table and play some more
@kurte
just pushed another change to the gait sequencer. Simplified all that code and hopefully if I get energetic I will add another gait sequence for testing. Oh - looked at a couple of videos and think the gait is close for at least that leg.
Ok back to other stuff
@cyberpalin - looking good. Now you just need a few more legs
I am pretty sure I mentioned it, but @xan had an early write up about the walking gates in his BlackWidow project: http://www.lynxmotion.com/images/html/proj102.htm
Currently playing with PS4 code again trying to see really where HS2 handling of the Voyee is different than ours… I am doing the same stuff on the: L2CAP Connection Request: ID: 1, PSM: 11, SCID: 40
code, where I output:
Two L2CAP_Connection Responses, followed by a Control Configuration Request…
Although before I can output the configuration Request I receive a message from Controller…
back to the rabbit hole
Yeah right. One is enough - for now.
Been using @zenta PEP 2.02 spreadsheet to generate the gaits - assuming same body setup which I may have to change. This is the link for the spreadsheet that you posted http://www.lynxmotion.com/images/html/proj098.htm
Been so distracted with getting leg and servos configured that I haven’t even looked at the PS4 stuff. But maybe need a new distraction.
We do like our rabbit holes don’t we
Yes for sure 
With the walking gaits there are some interesting things we can and maybe should explore.
@zenta - I know has explored at least some more possibilities with his code posted up here. Like with the new rules like no two legs that are next to each other to be lifted at the same time… Lots of neat things. I have it building on my machine and up there. I did try to convert it from building everything in the INO file to having different .cpp/.h files for each thing like Input controller and Servo Controller. I have it building with his Commander/DIY controller code… Zenta - I should probably check does some of it actually work with the commander? I also have the beginning of a PS3/PS4 version, but I have not fully debugged some of the settings yet. Will get back to that if there are others with something like a PhantomX that they would like to try it out with? Otherwise will continue to debug some of the lower level stuff.
But some of the interesting things with @xan stuff is it shows how some of the gait stuff works in at least some of the code bases. Not sure yet if Zenta changed this.
That is some of the gaits are setup with more or less one up location (full up)
And others maybe simply have an up and an half up:
And there is a table showing in which state each leg is in when you start, like:
LRGaitLegNr = 1
RFGaitLegNr = 3
LMGaitLegNr = 5
RRGaitLegNr = 7
LFGaitLegNr = 9
There is more data up there as well… This is all great stuff, and reasonably easy to compute and the like and the original code using this was written in Basic for the Basic Atom Pro.
But we are now running on a much faster more capable processor that also has floating point math. So one could consider doing something similar to Kevin Ochs did with his ROS hexapod (https://github.com/KevinOchs/hexapod_ros) and have the legs move more or less in a circular motion, If I remember correctly he started off having the legs move in a circle and then modified the bottom part (where it should be on the ground)… There are some youtube videos referenced in his Readme, which show of it.
I am not saying I would want to fully replicate the code, as I wanted to change some of the underlying basics, like what controls the timing of each segment of the walking gait. Note: his code used very little of the smarts of the higher end Dynamixel servos, but instead his code generated all of the new positions of each leg and did the IK to compute new servos positions and output those positions to the servos I believe it was at least 100 times per second. If I remember correctly his code ran on an Intel NUC board he had on board. A few of us made it work on the Trossen Robotics PhantomX, we mostly ran that code on Odroid XU3 or XU4 boards at the time. I think I may have tried it with an UP board as well.
I do think Something like that could be interesting. Not sure if you would have it try to go in full arcs and have it either stop going down when it thinks it has logically hit the ground or detect that it hit the ground, and/or configure servos to stop when they hit the ground…
But first we probably need to do some baby steps
Despite being less active, still here and following. 
1 Like
I have done something similar in my hexapod. I have not looked at what Kevin has done. However, to give an idea you basically use a sin and a cos function to generate the trajectories. The trajectory is broken in smaller chunks and each time the xyz co-ord is give to IK to compute the joint angles.
The coordinates in a tripod gait for instance are calculated by scaling the sin/ cos by the leg height. The sin or the cos are used in the x,y,z calculations based on your axis selection to generate foot tip coordinates.
float subdivisions = 25
float cos_subdivision, sin_subdivision;
cos_subdivision = (float)cos(M_PI*(slot/subdivisions));
sin_subdivision = (float)sin(M_PI*(slot/subdivisions));
slot go from 0 to 25 after which it resets back to 0… Increasing the subdivision makes it go really slow.
I had earlier started off using a triangular trajectory which is by far the most simple. So start x,y,z end xyz and an intermediate xyz… But the motion was not fluid. I was pointed to this https://www.projectsofdan.com/?p=206#comment-141232 and used the state machine and the sin/ cos concept. However, I did change the implementation to be a bit more understandable to me and also such that I could use it autonomously instead of using a remote controller. My code runs on an 8-bit AVR so its all in C … The repo is private… Let me see if I can clean up the code and get it public. There is no Arduino code unfortunately…
Also, there is no dynamic switching like what @zenta has done … or no terrain adaptation.
1 Like
@kurte and @madmax
You all driving me nuts - going to take me awhile to absorb all this stuff on gaits. Theoretically I know what they do but getting the details down going take me a while.
In the meantime decided to use that gait code I added for testing to @kurte’s test sketch and attached a logic analyzer up to it.
A couple of notes before I paste the picture and the data:
- Updated the firmware on all the servos - think they are all at the same level now (used LSS Config).
- Good news is that I am not seeing any framing or other errors from the LA for the single leg test.
NOTE: If someone had a better sequence for the RF leg let me know) - Most of the time is spent waiting for the servos to respond that they are in the holding position.
- Tried to skip the checkStatus function but no good. Already using the 250ms delay that @kurte suggested.
- In the trace most of the time the big gap is followed by the servo move commands, then rest is the time for ensuring it moved.
Session 0.zip (57.2 KB) Data dump from the LA
OH - channel 0 is TX and Channel 1 is RX
1 Like
Sorry 
Will play along soon
Hi @kurte.
I tried to connect the T41 to the PC today. At first I powered the LSS board only. But my PC couldn’t recognize the USB unit (T41). I then removed the LSSboard, placed a jumper on J5v and connected the T41. My PC regonized the T41 as normal and assigned a com-port. Was then able to upload the LSSTestservo.ino program. I tried starting the serial monitor, then the Arduino IDE halted completely and didn’t work again until I disconnected the T41 from the USB. So I’m not sure whats going on. I’ve never had problems with the older Teensys. I just feel there are some issues with the T4 and T41.
Btw I’m using Arduino 1.8.13. Should I update to 15? Looks like the Teensyduino are still in beta for that one. Not sure if the update will solve my issue though.
1 Like
Hi @zenta
Can’t speak for what @kurte would recommend but just a few things to try.
With the Teensy 4.1 off the LSS board plug it into your computer but do not put a jumper from the usb pin to the 5v pin don’t need it. The 5v pin powers the T4.1 if you cut that trace so might be getting feedback to your usb port.
As for the T4.1 I have been using it without a problem in @kurte’s kitchen sink board without a problem with that same test sketch as well as other projects.
I would go ahead and update your Arduino IDE to 1.8.15 and use Teensyduino beta9 - beta9 fixes several issues:. Heres the link to save you the trouble: Teensyduino 1.54 Beta #9 (pjrc.com)
Hope this helps
1 Like
Hi @zenta and @cyberpalin -
In addition to what @cyberpalin already mentioned,
A couple of other things to check
a) The Shield, make sure the selection is set to Arduino (center position)
b) All the normal things I know you already checked, but that things are plugged in the right holes. That is, it is not shifted down one hole
c) You don’t have anything plugged into the QWIIC connections as I specified the wrong ones which reversed the cables… (needed to be the ones that lie more horizontal on the board)
As mentioned, I mainly run these days on Arduino 1.8.15 and latest beta. Teensyduino.
These days I mostly use the TyCommander(https://github.com/Koromix/tytools/releases) tool for handling the Serial monitor stuff. Why? You can monitor multiple Teensy boards at the same time. You can choose which one to program and there is a software reset button, try to reboot the Teensy…
I am running a dev build of this right now as to support a beta build of the Sparkfun Micromod Teensy 4…