I pulled Randy’s latest changes and built a MatekH743 binary from the rover-scurve5 branch, linked below.
2 Likes
Hello all,
I am willing to try this feature with my two rovers: two rc cars in 1/16 and 1/5 scale, but I would need the binaries for a black cube.
I fact, I am very interested in trying s-curves, as I having a stupid problem: I want my rovers NOT to stop at every WP, now, it stops even for waypoints in a straight line with no need to do reduce speed. I have tried to set WP_SPEED_MIN to 1 m/s but, still, I can see in the logs that the desired speed goes to zero at every WP. is there something obvious i am missing? or it is not possible to maintain speed in “easy” waypoints with the current algorithm?
I understand that with s-curves there will be no speed reduction if not needed, am I right?
thankyou and regards!
Adolfo.
I’ve added links for the CubeBlack and MatekH743 at the top of the discussion. The MatekH743 one should be the same as what Yuri’s provided so using either is fine. Going forward, I’ll prepare all these binaries.
1 Like
I’ve just tested both master and SCurves in SITL and the vehicle didn’t slow down for waypoints in a straight line at least when using default parameters.
Below is a graph of the GPS_RAW_INT.vel and it dips in the middle but this is when the vehicle does a U-turn as part of the RTL command.
If you’ve got an onboard log I can look at I’ll have a peek but if that log is from master can you post it in a new thread?
Thankyou!!
Here it is the dataflash log: Sign in to your account
The mission is something like that:
and the desired speed goes to zero is every single wp, I have always seen this behaviour.
I set WP_SPPED_MIN to 1 m/s but nothing changed. I am using rover 4.1.5.
Thank you so much for your help as always.
Adolfo.
Let’s discuss over on this new thread so that we don’t muddy the water with the SCurve testing.
EDIT: the delay at the waypoints is because bendy ruler has been enabled and it takes 1 second for bendy ruler to determine if there is a safe path to the next destination. Yuri Rage reported this higher up in this discussion actually as well so it’s a known issue.
Thanks, I will be testing 2 robots with this on Friday. One with all wheel steering and one large skid steer with dGPS setup.
3 Likes
I could do with it for the Orange cube 
2 Likes
Great, thanks for helping with testing. There’s a link to a cubeorange binary at the top of this discussion (a the bottom of the very first post).
First of all it is great! noticeable improvements with S-curves in plans with close scans. However did have a strange error see attached image and log. It was the second scan when suddenly the orientation went out of alignment. Any ideas what it might be?
log:
https://drive.google.com/file/d/15px4DKyC0_wVKfh0DMfarwRBvkhp3BGd/view?usp=sharing
Testing with 4 wheel steer over the weekend.
1 Like
Finally a bit of sunny weather. Still cold, but at least no rain, snow or storm. I pulled the latest scurves5 branch and build it for my rover controlled by a Matek F765-Wing.
Anything specific I should test?
Hi @count74,
I think the main things to test are:
- that it drives in a straight line
- behaviour at corners of various angles with and without a delay
I’ve reproduced the slowdown issues you mentioned and discussed with Leonard and he thinks we can come up with a way to resolve this.
One of the big differences between the old L1 and new SCurves is SCurves blend two legs together to make the curve at the corner. Currently the next leg doesn’t start until the current leg’s slow-down phase begins and this is probably too late to allow the vehicle to maintain speed… so the key thing is we need to make the next leg start earlier.
3 Likes
That’s great news @rmackay9. I (at least felt like) I fully understood L1 thanks to a great page that had a bunch of diagrams. This one seems much more like black magic. Is there a paper that this was based on, or a high-level / pseudocode description of the algorithm?
I think where this one gets complicated is that there’s no single way to define the path because there are three main variables - cornering speed, cornering lateral acceleration, and cross-track error - and the path will change depending on how you prioritise those.
Speed will always be defined as a target, and lateral acceleration
Is there a place for user parameters to make one of them fixed / priority 1, another as priority 2, and the third as either a final threshold or a completely dependent variable.
Case 1: Speed then lateral acceleration (maintain speed, corner as tight as possible)
- Corner at fixed speed and at limit target lateral acceleration, cross-track error will vary depending on speed - higher speed will give greater cross track error
- At limit cross track error, speed will be limited to maintain maximum lateral acceleration. If no cross track limit set, then just keep getting wider.
Case 2: Speed then cross track error (maintain speed, maintain path)
- Corner at fixed speed and cross track error - lateral acceleration will vary up to threshold. Should follow same path regardless of speed
- Once lateral acceleration limit is reached, reduce speed
What drives the “slow down” phase - is the algorithm able to predict the complete path, and if so, doens’t that mean it should be able to work out whether it can satisfy the relevant conditions without slowing?
I flashed another rover with the scurves firmware, since the first one gives me a constant “bad compass health”.
This rover has a Matek H743-Wing V1 and two Emlid Edge UAVCAN GNSS/Baro/IMU devices. The rover was working fine with 4.1, but with 4.2-dev (scurve5 branch), it shows “unhealthy GPS signal” all the time. Both GNSS modules indicate a fix with their green LEDs, but Missionplanner shows “no fix”. Is their something I missed, some changes in UAVCAN settings?
Txs for testing. Re the unhealthy GPS, I’m pretty sure this is not related to SCurves so could you post a log and we can have a look? I think we should move this discussion to a new topic in the 4.2 category.
Leonard has reworked SCurves slightly so that the vehicle better maintains the target speed by cutting the corner more aggressively. Below is a picture showing a rover cutting the corner by about 10m and note the speed stays at 5m/s.
I’ve updated the binaries at the top of this discussion and I’m wondering if people here could give it a try? In particular I think @mroberts @stephendade noticed the slowdowns in corners. Note that you may need to increase WP_RADIUS because the vehicle will never cut the corner by more than this distance.
Thanks again for the feedback so far.
1 Like
I’d like to circle back to that issue you were seeing with unnecessary pausing at the waypoints (e.g. non-pivot turns) to make sure that is resolved or if not, I’d like to peek at it some more with Leonard. Do you think you could re-test with this latest version? … no pressure of course though …
1 Like
Is the 05MAR firmware for Pixracer posted at the top the latest for test?
1 Like
Yes the pixracer binary at the top is the best version to test with. Thanks for considering giving it a try!