This sort of leads me back to a question I think I asked yesterday or maybe day before.
Do the CH and CL modifiers work when we have EM=0?
If not are there other ways to tell the servos to stop, before they trigger this? How best should we detect we hit this state? I assume the Q command?
Is there any way to reset the error without having to reboot the servo, which then it takes maybe a second for the servo to reboot?
The reason I am asking this, is, so far all of the code sources for projects mentioned up here, all appear to be using EM=0. So would like to find a solution to this as for example it is one thing to say we should try to avoid dragging the foot normally, but what if the leg hits a minor obstacle, that once detected, maybe it can step over using a high step… Or maybe we decide to try moving over some distance before trying to go forward.
The firmware gurus are working as fast as they can. Looking to do at least some tests internally before releasing to the BETA group, but keep in mind the tests will be far from exhaustive to try to save time. ETA maybe a week or two. When released, we’ll write an overview of the changes here, but for the moment it’s expected to be a significant improvement to the communication in terms of baud rate and error rate.
Thanks for the info - looking forward to testing. Should help significantly even if its a beta release while you all are still testing. Should also help us avoid unnecessary workarounds. Thanks again for the info.
Sounds good, wish it was sooner. But…
Hopefully when you are saying significant improvements in baud rate, that it also includes improvements in throughput speeds especially with Query functions. As I showed up in earlier postings a few days ago (I think posting 911), Currently when you do a query for something, the delay after we send out the last character until the servo actually starts to respond is significantly more time than the actual transfer time for the response:
This is also really true when you are attempting to query multiple things from the servo, there are very noticeable gaps in between each of the thing queried for. Again from that post:
The main reason I mention this, is I remember working on the Intel Edison board and there was issue with the speed of their SPI and they were going to increase the maximum transfer rate… When that release case out, sure enough they were successful in increasing that speed. Unfortunately, it did not help much as their HAL layers and the like had some much overhead that the actual number of SPI transfer calls you get through per second really did not change.
So I am hoping that some of your communications improvements includes significantly reducing the latency between when the servo receives the query to when it responds.
Okay… Today i had some hours to sit with the robot at stretch. I have a long post to do… but the short version… after getting all the updates in the LSS_PHOENIX_USB_Joystick code I tried it again and I think the move command certainly performs well than the moveT less jitter and some smooth motion. My phone memory is full so couldn’t click any videos… I will do in this post later as an edit… I basically changed
#include <avr/pgmspace.h>
@@ -420,7 +420,7 @@ void ServoDriver::CommitServoDriver(word wMoveTime)
// Set the id
int servo_id = pgm_read_byte(&cPinTable[i]);
myLSS.setServoID(servo_id);
- myLSS.moveT(g_goal_servo_pos[i], wMoveTime);
+ myLSS.move(g_goal_servo_pos[i]);
}
}
} else {
(END)
Need to play more… I will edit this post later and post some more updates… Also for soem reason my right rear tibia is bit off than others… I dont know why… need to investigate…
Well yes it may move better with just the move command but you no longer are using timed moves - it will move to that position in what time it moves it in it. You will see in a minute what I am talking about because I think you missed something.
With the latest updates @zenta’s changes were incorporated plus the S/W interpolation that @kurte added. On startup you will see several menu choices:
CMD ‘A’ will toggle between moveT commands and S/W interpolation using the move(xxx) command to get it there within the desired time. ‘F’ changes the FPS for the interpolation.
So when you toggle ‘A’ you will see the following:
First toggle tells the sketch to use moveT, the second toggle of ‘A’ puts it into S/W interpolation mode.
Would suggest that as a test to leave the move as moveT and use the ‘A’ command to toggle between the 2 modes for testing.
Hi. @cyberpalin I don’t think I was able disable your offsets in the code, so I ended up putting in my values from the offsets I set my servos to. So it was just like the old days…
Now every foot had contact with the ground and the IK movement are as it should. In the video I notice we have to reverse the leglift on single leg.
Still have issues with the servos, especially the coxas decide to turn the wrong way. Didn’t find the ideal frequency for interpolation, the movements are still a bit choppy.
until now I’m not sure what to do/improve to get smooth servo movements. Maybe wait for the firmware upgrade?
Anyway, I’ll be away for a while due to family stuff and a party this weekend celebrating my middle son delayed Confirmation.
First enjoy your weekend and congratulations to your son on his Confirmation. Been awhile since mine, never mind
As for disabling the offsets I will take a look but I think for now maybe leave it that way until we decide how wto handle configuring 0 position and calibration - then it can fixed - In the meantime will go back and see what @kurte and I did - maybe make it an ifdef for now.
To be honest think we should wait until the upgrade to firmware and see if you get any improvement. Maybe increasing the comm speed would help - right now the sketch is at 250k to try and avoid any comm issues. To be honest unless moveT is fixed not sure you are going to get rid of all the choppiness but its a lot better with sw interpolation thanks to @kurte. But more than likely will continue to try - but don’t even think about it until after you take care of the family most important thing.
Really like your video, for me its good seeing that the whole Hex does move with all those changes. Thank you for posting that.
Btw. I noticed that I always need to enter A twice to get the servos calm down. The first time I assume it get back to moveT and the second time software interpolation. It’s like it’s missing something at startup? Since the servos jitter some at startup and cycling through A twice make it better…
Thanks will take a look. My preference is to have it set to S/W interpolation by default - how does that sound. Noticed that as well this morning before my dentist visit - please don’t ask
As for jitters, as you said we probably need to play some more. Like maybe adjust how fast the gait is versus the frame rate. Such that maybe the frames need to be in multiples of frames per gait calculation frequency.
Like if the gait is currently 30, not sure if 60 or 90 would work well…
Some of this will depend on just how fast we can reliably drive the servos. And if we decide we need to do any query functions. to the servos.
As @cyberpalin mentioned maybe we should go with your leg settings in the init function. Later we can decide better ways to do this.
As for sometimes the servo going the wrong direction. When I first ported the code over. I thought things were sort of working, but then I would have a leg flying to a random place. Often it was the femur servo sometimes Tibia…
Wondered if maybe I screwed up something… But also wondered if maybe communication error.
Although most of the communication errors I have seen were responses from the servo. So again unclear.
Oops looks like several more messages since I started typing… Slow typest.
May need to look at why we need the double (a)
FPS - Frames Per second:
More or less states it… Note: there may still be a few tweaks needed in this code, where maybe need to either adjust the lengths and/or decide best how to round the number of cycles. That is I might not always get the perfect timing. when gait movements are not in integer multiples of our cycle time.
But the logic is pretty simple: That is if you ask to move from 100 to 120 in a time frame that is 2 times the cycle time. Then on the first cycle we will call it with 110 and on the second 120… (120-100)/2 = 10 as the increment. I actually am using floating point for the increment such that if you are going from 100 to 102 in 4 cycles, it will go 100, 101, 101, 102 …
The other thing I wonder about jitter is something I think @cmackenzie mentioned with his code base, something like that he needed to tell the servo to go to some position like three times before he was sure it would get there… Something about the filter settings? Should we try this?
Also with Jitter. The current interpolation code is only outputting the values to the servos that change positions. Which implies typically the messages that you send at the end of a logical group move will be shorter than the earlier ones as more of the servos arrive at their destination. Which can be good. But with another type of servos, I did that in the past, and some were noticing jitter, due to the slight difference in timing and that was with all of servos should start operating on the instructions at the same time (after they receive a valid CRC or checksum depending on servo).
So at that time I tried to ways to solve this. The easy was to just output everything every time, or to alter the time when we sent the data. That is if 10 servos do not need their time updated, and for those we would send 5 bytes each, how much time would it take to send those 50 bytes at the current baud rate, and delay by that time.
So I might try this (the easier way) to see if this helps both send same destination multiple times).
And try to improve the timing.
But with ASCII commands not sure how easy it is to be exactly same length.
Example if one time, I send #1D10\r and the next I set #1D100 then there is an extra byte. Maybe one can send leading zeros? And send out like D-120 and D0010 ? Not sure if servos will mind… But implies long strings.
Sorry for long response Hopefully I answered some of the questions?
Actually an easy fix for single ‘A’ toggle. I tested it a little while ago. Just change
bool use_servos_timed_moves = false;
to
bool use_servos_timed_moves = true;
in the LSS_Phoenix.h
Now that you mention it - but think that was for EM=0, wondering if the comm links improve some of it may get resolved especially if we are in EM=1 mode? Just thinking out load here.
That might help. Probably need to look more into servo values vs. timestamp. If there are some unnecessary breaks that prevent a smooth/linear motion.
If I recall correctly there are relative few steps in a gait cycle. Meaning relative large steps between each step. Any halt/break in time get very visible. During body rotation and translation the steps are very smal depending on your joystick inputs though.
In my current float code with the new gait algorithm one gait cycle have a much larger amount of steps. Maybe up to 1000 steps depending on speed and leg lift height. So I’m a bit curious how it would perform here.
I don’t have much time right now, but want to experiment with also not necessarily needing a fixed frame rate. If you ask to do it in 30ms calculate a reasonable rate to get there that does not exceed some max…
