Yes, that was a typo. It should be ATC_TURN_MAX_G multiplied by 9.81. I’ve fixed it above txs.
The way SCurves cause the vehicle to turn is the current leg’s scurve’s output and the next leg’s scurve’s output are added together. So the turn starts when the current leg enters it’s braking stage. The exact code is (I think) here in SCurve::advance_target_along_track().
I’ve updated the binaries at the top of the discussion with just one improvement:
While investigating the delay-during-pivot-turns issue we added this special behaviour to disable “scurve time scaling” as the vehicle slows down to stop at a waypoint. Later on we found out that the biggest cause of the problem was actually the “SCurve Jerk time” setting was too low. So basically I want to remove the special behaviour if it’s not useful.
@Yuri_Rage no pressure of course but if you have a chance to test pivot turns with this parameter set at 0 and 1 that would be great. I don’t think you’ll notice difference but let’s see!
This branch has also been rebased on master.
UPDATE: I tested on my AION robotics rover:
I don’t have an RTK GPS on my vehicle though so the vehicle’s performance is quite variable. Sometimes it seems rock solid as it travels in a straight line between waypoints and other times it wavers on the path. I guess I need a better GPS so I can more easily distinguish between what is an estimation issue and what is a control issue.
I think I’m seeing part of my problem (or at least something I’m missing) - in order to fully diagnose things, I need to look at desired vs achieved turn rate as well as desired N and E velocities, ideally with a square course. There’s a combination of what the system WANTS the vehicle to do, versus what the vehicle can achieve. My problems may be a result of perfect planning but poor execution.
May be time for an improvement request to implement GCS_PID_MASK1 / GCS_PID_MASK2 so you can look at two things at once.
The “perfect planning but poor execution” comment is a good one. Users often complain of the vehicle performing poorly in auto mode and spend time trying to tune the navigation related parameters but the real problem is down in the lower level lower level speed and turn-rate controllers.
Re GCS_PID_MASK, the vehicle code actually can send the PID outputs for all the PID objects without any troubles. The issue is the the ground stations are not able to display them separately.
I have not forgotten about this test - been a bit busy with all sorts of things amongst some uncooperative weather. I will try and get this loaded and tested soon!
The weather has improved, so testing should be easy this week.
Caught the mention in the Dev Call about waypoint disappearance. I have experienced it in 4.2 master (and alpha releases alike) on the mower but not on my other little RC truck Rover. I still suspect a hardware oddity vs a bug and will try and nail it down.
1 Feb update:
@rmackay9, I finally tested your 17 Jan alpha firmware today. You’re right, I noticed no real difference between WP_OPTIONS=0 vs 1.
The mysteries I’d like to solve:
Why even with a WP_RADIUS of nearly 3m does the S-Curve planning not turn sooner? It’s overshooting the non-pivoted waypoints by a large enough margin to cause an oscillation as course is regained.
Why do waypoints disappear between reboots? Yep, it’s still present, and today I switched to a brand new SD card of higher quality (since once before I thought I correlated a full SD card to the disappearance issue, despite its likelihood being low).
Log file will be in the same place as usual - WP_OPTIONS=1 is the first lap of the auto mission, then WP_OPTIONS=0 after the brief pause in hold mode.
Thanks for the feedback.
Re WP_OPTIONS, this is good to hear 'cuz it means (as expected) the SCurve scaling during slowdown is uneccessary. I’ll remove that 'cuz it’s unnecessary complexity.
Re the vehicle not starting the turn sooner, the issue is the SCurve path is built using the lowest of the various accelerations (ATC_ACCEL, ATC_TURN_MAX_G, WP_ACCEL) and also the desired speed (WP_SPEED). So if the accelerations are too high or the speed is too low then it will tend to be a sharp corner. The SCurves also can’t accept a minimum turn radius (yet) so the corners can be sharper than the vehicle is capable of actually turning.
I see ATC_ACCEL is set to 4 (and ATC_TURN_MAX_G is 0.4 which is roughly the same as 4m/s/s) so setting WP_ACCEL to a much lower value like 0.5 or 1 should result in more cutting of the corners during turns. Here’s a screen shot from SITL showing the difference. With WP_SPEED = 1.4 and WP_ACCEL = 4 it overshoots the corner but when WP_ACCEL = 0.5 it slightly cuts the corner.
I’ll follow up with PeterB re the mission erase. If you have a chance to test with Rover-4.1.x to see if the problem happens with the stable version this will give us some clues as to the cause but no pressure. We need to investigate further on our side as well.
Ok, will do on both the parameter/turn issue and 4.1 vs 4.2 mission erase!
Seems as if we are closing in on a beta release of the S-Curve controller. I think it’s very exciting! Not sure the community at large has realized the impact. It seems like my frustrations with it come down to tuning vs actual capability at this point!
PeterB and I discussed the mission erase problem and we suspect this is another variation of the infamous parameter reset bug that plagued us for so long. The issue may be that while we’ve added protection against parameter resets we overlooked other data that is stored in the eeprom including the mission and fences (polygon, inclusion/exclusion).
I wonder if you’ve noticed that the fences are also being erased? … or is it just the missions? If both are disappearing then it is likely this problem.
There are two well known causes of the parameter reset issue:
My fences have also disappeared, but I have not tried repopulating them to see if they persist across boot cycles since OA has been a little odd with the new nav controller.
I suspect it may be the boot loader. This Cube was purchased right after the ADSB carrier board was released, and I don’t think I ever updated the boot loader.
I would be surprised if I have a power issue but will put an oscilloscope on it if a boot loader update is unsuccessful.
In simulator testing setting PSC_VEL_IMAX = 0 (and/or PSC_VEL_I = 0) improves performance in at least some cases. The issue is that the position controller works in earth-frame (North-East) but our lower level controls are in body-frame (forward-back and lateral). This can mean that forward-back I-term buildup (caused by the vehicle not being able to keep up with the WP_SPEED) can be partially or completely transferred to the lateral axis after the next corner causing the vehicle to stay off the path for a while as it works off the I-term buildup.
I’ll discuss with @Leonardthall as well…
Thank you, Randy. I will do a little more experimentation with those parameters.
A brief test after a bootloader update shows that we may have solved the elusive waypoint issue. Time will tell there.
I had a chance to test the S-curves with a Traxxis X-maxx rover today.
Using default parameters, it tracked really well. A little extra P got it turning quite tightly. At higher speeds I did need to up the I and Imax terms to keep the rover on the track.
Using standard Ardupilot with L1:
Using S-curves:
Thanks very much for testing!
The S-Curve path looks quite a lot better to me. I see you got it cutting the corners nicely as well. So I guess overall you found it was an improvement right?
Big improvement! And much easier to tune - the L1_ (and associated WP_) params were always a bit tricky to tune.
How did you go with getting it to maintain speed? Every sim run I did, if the waypoint speed was more than 2 or 3 m/s it would keep trying to slow down.
Well done. Would be interesting to see a dump of your tuning parameters (and a brief overview of how you arrived at them if it’s not too much trouble).
On a different note:
We need more folks involved with this effort. The lack of testers, it seems, will likely stall development until 4.3 unless we can generate some interest. I fear the community at large isn’t quite aware of just how significant this change is, nor how much it can potentially alleviate a lot of nav tuning woes.
I’ll have my Rover available for test very soon when I return home from remote work. Looking forward to doing some driving!
I have one of my rovers ready to test, but the weather is more or less constantly crap. Testing on a parking lot in pouring rain or snow is not my kind of fun…
.
Looking at my logs, it did slow down to 2m/s during turns. Will need to investigate this.
