Just hooked up the logic analizer with the previous test sketch.
The period between possition commands seems about right at 24.64ms
Also from the begining of the first position sent to the begining of the last, there is about 10.113ms
1 Like
the 25ms seems about right - I was timing it out as 26ms. But that could be attributed to setup. The interesting thing in that second screen shot is that did you notice the “INVALID PACKET!! invalid position”. I think I would look at the response you get back from get position to see if its returning fast enough. At least thats what I was planning on doing when I get back.
Have to run, sorry, should be back in a few hours. Sure @kurte will jump - still early where he is.
Really appreciate you jumping in and trying to sort this out.
Good morning @dialfonzo and @cyberpalin, it is getting sort of late here (5:30Am) 
As I have mentioned a few thousand times, Logic Analyzers come in handy! Are you using the version 1 software
Will take a look later. Wondering about those messages mentioned in top line, but then not sure what it is? Is that a HLA for the servos? Which tries to parse the # messages?
Again will look more, but also more interested in trying some of the things I mentioned yesterday in our test sketch, about trying to get the sort of leg moves to be properly timed and then smooth transistions.
Do you still have a setup with you that you can try out some of this stuff as we go along? So far I am only one with a full setup that I know of that has tried some of this stuff.
Also wondering if you have done any fun projects with the new SES2? Any new fun Drones?
Now more coffee!
This line is a plugin that @cmackenzie created for the LSS bus but it’s not perfect.
Here is a closeup of the data regarding the initial query.
Here is a position sent:
If i’m zooming out it show “!!invalid packet” but that’s for the first part where i had “Sequence Start”
Screenshot of a 250ms movement of 45deg as you tested
1 Like
Useful tool, I’m learning but found it very intuitive and give a lot of infos.
I’m using Saleae Logic 2 software and the extension that @cmackenzie created, it’s available to install in the software and called “LSS Bus Protocol Analyzer” if you want to check it.
Are you talking directly to me about that ?
I will start now the assembly of an Hexapod i “should” have everything here and if not i will have a partial until i can get more parts from the office.
I’ve designed the mechDOG chassis and @dickel helped in getting some feedback and he did nice code for it…!!
No drone project lately, the market is quite saturated and people are looking for off the shelf drones.
1 Like
My HLA is confused with the \n being added to the packets. The LSS communication guidelines say the packet terminator is just \r. I actually wish it was \n because usb-serial hardware and I think some USART implementations will flush buffers/FIFOs when they see a \n. I’ll need to adjust my HLA to ignore \n
1 Like
Good morning (at least in my timezone) all:
The other difficulty with HLAs are they can only process one channel. So you can not easily for example have an HLA with TX and RX data and combine them so you can see when the responses arrive. There have been a few requests up on the Saleae beta forum for this feature… I have not yet tried one. I do have a low level one for Dynamixel Servos…
Yes, I think it would be great if someone at RobotShop could play along, so when come up with questions, often times it is easier to understand if you can see the stuff in action. Also hopefully fun to see things when new things are working.
Will have to look at the mechDOG. was @dickel able to make use of CM=1 or is that also bypassing it?
Sort of wondered about the drones as there sure are a lot of options out there.
Note with the test sketch I was able to run it and will play more as it helps demonstrate some things. What would be interesting extension to it, would be to have the ability to slow it down, so you can more easily monitor how the servo transitions from one setting to the next. Like it would be fun if someone hooked up something like a POT resistor to one of the analog pins, and you read the pot to choose how fast to rotate.
Another interesting experiment would be to somehow hook up a servo horn such that when it rotates it turns a pot or rotary encoder and then have the sketch do some timed captures of the values to see how it tracks.
But right now I am curious about trying a few experiments to see if some of the random thoughts on how maybe I might be able to make something like #1D100T250\r followed by another that should continue the move, without having the servo want to pause between… Not sure if any of these will work:
LIke: can I do a new #1D… at lets say delta time 225 with the new positions and time and bypass the slow down code? If anything like that works, how close can i get to the actual position/time?
Or in EM=0, T modifier does not work and what has been stated neither does S? First I will try S just to confirm. Then assuming it does not, may then try altering the Max speed and if that works at all then see how close we can get.
Now back to playing
The other difficulty with HLAs are they can only process one channel. So you can not easily for example have an HLA with TX and RX data and combine them so you can see when the responses arrive.
Yes, I asked for this on the Saleae forums and posted in their Idea board. Since it’s python there is nothing stopping us from writing our own back-end communication and I see one person used sockets to do this with mixed results. I was considering using ZeroMQ. The HLA seems to process incoming data in like a queue, so one HLA may fall behind in time a bit from it’s friend if it has less data to process. I believe this is the issue with backend comm between two HLAs not being in time sync and one HLA is missing the synced events that it’s friend generates sometime later. So the back-channel can’t just send data it must also be used to pause HLAs that are ahead of it’s friend.
I am not sure if anyone up here has mentioned it or not. But recently there was a sort of a screw up with ROS, where they forgot to renew their security keys, which than lapsed.
So they had to issue new keys. This caused issues like you were no longer able to do things like:
sudo apt-get update
And have the system fetch updates to any of the ROS packages or the like. I first saw this on the ROS Discourse messges I receive and later on the forum:
I found that I had this issue on my Ubuntu machine, but was able to resolve it using the instructions in one of the messages.
I am not sure if everyone has fully recovered from this or not. One of the last messages I saw on RobotSource, it sounded like for example Robotis is now going to have to update all of their prebuilt images (assume RPI) to all have the new updated keys.
Not sure how much this impacts anyone here. But thought I would mention it in case someone hits it.
1 Like
Hi
I have started with the URDF file for the hexapod. That is the trickiest one to get correct. I am now assembling the leg. Once I am done Colin would help me with xacro to get it complete. The individual parts had their origins way out and that was causing issues. I had to get the parts in Blender and get the origin in the centre of mass and rexport those parts.
Here are some screenshots of WIP of the URDF file…
EDIT: I am still catching up with the latest posts …there seems to be some important ones …
Hi,
I’m testing the “move all servos” function in the LSStest program. Commented out the parts that involve reading positions just for testing if it’s possible to get some smooth movement.
I keep getting some glitches on som servos now and then. In the video I run in a 10mS loop with 3 position increments. I’ve also tried a loop of 25mS with the same result. What do you think can cause these random glitches?
1 Like
Playing catch up now since I just got back and reading what I missed. I was looking at those YouTube videos last night with the mech dog - really cool what you all did.
@dialfonzo - is the code for that available - would be interesting to see how he handle servos configs.
Well if I had another setup I would give it a try but not going to invest right now in more servos just to test. I will you guys do that with all the servos 
@zenta - which test code are you using? There are 3 that at least I have been playing with in @kurte responsitory: LSS_TEST_SERVO, LSS_PHEONIX, and Zenta :). Going to make an assumption its the LSS_TEST_SERVO sketch? Can you share what you have. I can give it a try on my 1 leg.
Wondering if the glitch could be caused by a timing issue, or the related to the issue we were discussing with using timed move’s (moveT).
@madmax - @zenta question?
Have you all looked at the CFG files I set up for the LSS_PhoenixUSBJoystick or Zenta_LSS_Phoenix_PhantomX_float code. Not sure its 100%.
Hello all,
Quick update:
I tried the EM=0 and tried to use the SD modifier to see if it would work or not…
Like the T it does nothing…
Pushed up changes to the LSS test sketch we are running ‘c’ followed by ‘i’
Will see if it works with EM=1 any better than T…
Note: had to roll my own as no library function for this, nor even a define for “SD” for modifier.
But there is for SD as a motion setup command? so I am guessing that:
#1SD144\r#1D100\r
Will be interpreted differently than:
#1D100SD144\r
Will be interesting to see…
That’s correct. Running this function: (Keep forgetting how to post code in a proper way…)
void MoveAllServos(void) {
// first move all to center and on
AllServosCenter();static int MIN_SERVO_POS = -200;
static int MAX_SERVO_POS = 200;
int servo_angle = 0;
int servo_increment = 3;int positions[NUM_SERVOS];
int voltages[NUM_SERVOS];
int temps[NUM_SERVOS];
int index_print = 0;
Serial.println(“Move All servos: Enter any key to exit”);
while (Serial.read() != -1);while (!Serial.available()) {
elapsedMicros em = 0;
servo_angle += servo_increment;
if (servo_angle >= MAX_SERVO_POS) servo_increment = -3;
if (servo_angle <= MIN_SERVO_POS) servo_increment = 3;
for (int j = 0; j < NUM_SERVOS; j++) {
myLSS.setServoID(pgm_axdIDs[j]); // So first is which servo
myLSS.moveT(servo_angle, 250);
}Serial.printf("TQS:%u\n", (uint32_t)em); while (em < 10000) ;//wait 10mS}
}
I found using a rather high time value in the moveT command gave a softer movement.
I’ve not looked at the cfg files you mention yet.
1 Like
First - I wish I knew as well how to post code in the forum as well, so we are in the same both.
Thanks for posting the code - not sure its going to work for me with just one leg but will give it a try. PS nice video you posted was nice to see all the legs moving.
Ok not a problem with the cfg file was just curious.
Things are slightly overwhelming at the moment, hard to keep up with all your posts here.
I do have a PS4 remote and got a CSR V4.0 BT USB dongle. If you have a code I’m ready to try and look into. Would you mind pointing my in a direction what files to work on? @kurte I assume some of these are the ones?
You think you all can share the plugin?
But back to the question at hand. I did a couple things. In the sketch I had it print out what angles I was requesting as it was going and what get position is showing and bouncing it against LA:
Data from sketch:
Current pos: (qd: 446), dPos(-896), tStep(-89)
i: 1, move: 357
i: 2, move: 268
i: 3, move: 179
i: 4, move: 90
i: 5, move: 1
i: 6, move: -88
i: 7, move: -177
i: 8, move: -266
i: 9, move: -355
i: 10, move: -444
Final Move: -450
Time(ms)/ Pos(deg)
258 / 446, 436, 407, 370, 322, 266, 204, 136, 59, -18, -108You can clearly see there is a difference in what gets returned from get position. On the first and last moves from the LA confirms that:
In actuality it does move the servo the 90degs to the next position from my recognizing.
Now as a spoof I add in a 500ms delay:
delay(em0_rate);
delay(500);
temp[i] = LSS_1.getPosition();GetPosition works:
goal: -450, time: 250, pos_num: 10
Current pos: (qd: 446), dPos(-896), tStep(-89)
i: 1, move: 357
i: 2, move: 268
i: 3, move: 179
i: 4, move: 90
i: 5, move: 1
i: 6, move: -88
i: 7, move: -177
i: 8, move: -266
i: 9, move: -355
i: 10, move: -444
Final Move: -450
Time(ms)/ Pos(deg)
5258 / 447, 359, 270, 182, 92, 4, -86, -174, -264, -353, -447
There could be a couple of contributing factors to this: (1) Running at 250K baud, (2) comm issue with the servo - servo completes moves but when getting position servo not ready to transmit right away.
Now you might ask why am I doing this. Trying to get an accurate time to see if it works.
Tell me about it.
Yes. The LSS_PhoenixUSBJoystick is one it kind of sort of works. At least the legs will up and down.
Am also working on the zenta one: mjs513/LSS_Phoenix_BT (github.com). To be hones probably can grab both of them from there. I am using that as our experimental before posting to Kurt’s repository.
2 Likes
I’m Back
Was out removing a couple of trees that were sort of blocking some of my trails.
Posting code like: The code that was trying to do moves using the speed modifier:
void cycleStance()
{
while (Serial.read() != -1) ; // clear any remaining serial input.
// BUGBUG:: quick and dirty setup first move
for (uint8_t position = 0; position < RF_STANCE_COUNT; position++) {
for (uint8_t leg = 0; leg < COUNT_LEGS; leg++) {
if (legs[leg].leg_found) {
myLSS.setServoID(legs[leg].coxa.id);
legs[leg].coxa.time_position = myLSS.getPosition();
myLSS.setServoID(legs[leg].femur.id);
legs[leg].femur.time_position = myLSS.getPosition();
myLSS.setServoID(legs[leg].tibia.id);
legs[leg].tibia.time_position = myLSS.getPosition();
}
}
}
for (uint8_t count = 0; count < 1; count++) {
for (uint8_t position = 0; position < RF_STANCE_COUNT; position++) {
for (uint8_t leg = 0; leg < COUNT_LEGS; leg++) {
if (legs[leg].leg_found) {
myLSS.setServoID(legs[leg].coxa.id);
// compute speed...
int delta_pos = abs(legs[leg].coxa.time_position - rf_stance[position][0]);
int move_speed = 3600000l / (delta_pos * servo_move_time);
LSS::genericWrite(myLSS.getServoID(), LSS_ActionMove, rf_stance[position][0], "SD", move_speed);
//myLSS.moveT(rf_stance[position][0], servo_move_time);
//myLSS.move(rf_stance[position][0]);
myLSS.setServoID(legs[leg].femur.id);
delta_pos = abs(legs[leg].femur.time_position - rf_stance[position][1]);
int move_speedf = 3600000l / (delta_pos * servo_move_time);
LSS::genericWrite(myLSS.getServoID(), LSS_ActionMove, rf_stance[position][1], "SD", move_speedf);
//myLSS.moveT(rf_stance[position][1], servo_move_time);
//myLSS.move(rf_stance[position][1]);
myLSS.setServoID(legs[leg].tibia.id);
delta_pos = abs(legs[leg].tibia.time_position - rf_stance[position][2]);
int move_speedt = 3600000l / (delta_pos * servo_move_time);
LSS::genericWrite(myLSS.getServoID(), LSS_ActionMove, rf_stance[position][2], "SD", move_speedt);
//myLSS.moveT(rf_stance[position][2], servo_move_time);
//myLSS.move(rf_stance[position][2]);
legs[leg].coxa.move_status = LSS_StatusUnknown;
legs[leg].femur.move_status = LSS_StatusUnknown;
legs[leg].tibia.move_status = LSS_StatusUnknown;
Serial.printf("<%d, %d %d> ", move_speed, move_speedf, move_speedt);
}
}
//delay(delay1);
checkStatus2(position);
// lets try printing out positions of the legs (goal, timed position, end_position)
Serial.println("\nPrint Servo Positions Joint(Goal, timed, end)");
for (uint8_t leg = 0; leg < COUNT_LEGS; leg++) {
if (legs[leg].leg_found) {
myLSS.setServoID(legs[leg].coxa.id);
Serial.printf("C:%u(%d, %d, %d)", myLSS.getServoID(), rf_stance[position][0], legs[leg].coxa.time_position, myLSS.getPosition());
myLSS.setServoID(legs[leg].femur.id);
Serial.printf("\tF:%u(%d, %d, %d)", myLSS.getServoID(), rf_stance[position][1], legs[leg].femur.time_position, myLSS.getPosition());
myLSS.setServoID(legs[leg].tibia.id);
Serial.printf("\tT:%u(%d, %d, %d)\n", myLSS.getServoID(), rf_stance[position][2], legs[leg].tibia.time_position, myLSS.getPosition());
// remember the last position to use in next one...
legs[leg].coxa.time_position = rf_stance[position][0];
legs[leg].femur.time_position = rf_stance[position][1];
legs[leg].tibia.time_position = rf_stance[position][2];
}
}
//GetServoPositions();
if (Serial.available()) {
Serial.println("*** Paused hit any key to continue ***");
while (Serial.read() != -1);
while (Serial.read() == -1);
while (Serial.read() != -1);
} else delay(3 * delay1);
}
}
}
I believe that this sort of matches or uses markdown format stuff… like:
But a couple of basic ways. If you have something short that you want in blocks you can simply have a blank line followed by one or more indented lines (like 4 spaces)… like:
#1P500\r
For large blocks like above, you can use what I think they call fences? but
if you start a row with three characters (on my keyboard to left of 1 key below ~ That will start a block which ends with another line with three characters… Which is what I did for the block above…
About to try changing that block to commands and see what it does…