Randy, after returning from a very disappointing two week project 1000km from home, this latest firmware seems to be the answer, thank you.
See this post … John Easton's boat navigation
Unfortunately the WOBBLE IS BACK.
John,
I had a look at the logs and it looks like it was fine for much of the mission but then freaked out a bit wobbling and then it was OK again later? Somewhere around waypoints 16 it started wobbling a lot.
The steering control is actually performing pretty well during this period in that the actual turn rate (in green) is sticking with the desired turn rate (in red) quite closely.
What’s going very badly during this period is the speed control. The desired speed (3m/s) is shown in red below and it’s a flat line but then the actual speed (green) and output throttle (blue) are oscillating very badly.
From graphing the PIDA message (which shows the contribution of PID), it looks like the P is to blame. So I think lowering the ATC_SPEED_P from 0.2 to 0.1 or even 0.05 will help.
What surprises me about this is how an overactive throttle controller can cause a heading wobble. I’m suspect what’s happening is our navigation controller is reacting to the vehicle slowing down and speeding and then it’s increasing and decreasing the steering request. At a lower speed, the navigation controller requests a harder turn, at higher speed it requests a more gentle turn. So this is how the throttle oscillation bleeds into the navigation control.
A couple of changes that might help:
- lower ATC_SPEED_P from 0.2 to 0.05 (as mentioned above)
- increase NAVL1_PERIOD from 6 to 8. this will make navigation less aggressive
- reduce TURN_MAX_G from “1” (G!) to a more realistic 0.3 or even 0.2.
By the way, I think there is an improvement we can make to the vectored-thrust feature related to throttle. The feature currently scales the steering based on throttle, it’s doesn’t however compensate for the loss of forward thrust as the motor is turned. I realised this issue when writing the feature but I thought it wasn’t not important. If we find we can’t get your throttle tuned well, we may revisit this omission.
-Randy
Randy,
Thank you one again for your time and effort.
First of all, I don’t think I have been very clear on why a steady path is so critical to the collection of SideScan Sonar.
For the creation of contour charts (depth data / bathymetry / topography), a narrow 200kHz cone shaped sonar pulse is used, so a steady heading is not that important as long as longitude, latitude and depth data is collected accurately.
SideScan Sonar, or Mosaics, is a completely different thing because a steady and accurate heading now becomes just as important as long/lat/depth. Just imagine going for a CAT scan and you wiggle and wobble during the scan, even just for a brief moment … the entire scan is rendered useless and has to be done again from scratch, the same applies to collecting SideScan Sonar, and this is why:-
The 120ft sidescan on either side, 240ft total, does not like radical turns, especially when it crosses over itself, this just blends the two and becomes a blurry mess.
Example of SideScan with radical turns (lines / blurry)
Here is the video from yesterday’s test - (NOTE - parts have been sped up to reduce video length)
If it were a setting or a compass calibration, then I believe the entire mission would be wobbly, like it was when we started this venture, remember this?! LOL
We now have a VERY different situation, all is going so well, then all of a sudden the wobble is back, and with a vengeance. I feel the next critical step is to find out what changed at that point it started to drift off track and all of a sudden started to make erratic changes to steering and throttle.
Here is the log from yesterday - https://www.dropbox.com/s/qt9sy6h8ux6dofg/00000189.BIN?dl=0
My Humble Opinion:-
Nothing is changing on the craft from a wind, current, compass or speed perspective at the point where things go wrong. Therefore, the ONLY thing that can fluctuate while on this mission is either hardware failure on the Pixhawk2.1 Cube / HERE+, or GPS ERROR!
What is your take on this?
Here is the original thread for this topic … John Easton's boat navigation
John,
Nice video… just beautiful.
I think the wobble is caused by an over tuned speed controller. It’s possible for a control system to be fine for a while but then become unstable because of a disturbance. So for example, a multicopter could be completely stable indoors but then when taken outdoors and subjected to a strong wind, it becomes unstable.
I could be wrong but I think it would be best to try these three parameter changes as a start.
- lower ATC_SPEED_P from 0.2 to 0.05
- increase NAVL1_PERIOD from 6 to 8. this will make navigation less aggressive
- reduce TURN_MAX_G from “1” (G!) to a more realistic 0.3 or even 0.2.
If this doesn’t work, there are other things we can try. At some point in the near-ish future I think we’re going to need to significantly rework the navigation controller but that’s a bigger job that will take a bit of time.
1 Like
Thank you Randy,
I will try those settings tomorrow. Your help is very much appreciated.
Regards
John
Randy,
I can’t seem to be able to change ATC_SPEED_P to below 0.2, it turns red and when I read the parameters back from the PH it is back to 0.2.
Same for TURN_MAX_G, the lowest I can go is 1, then it too goes red.
John,
OK, this is just a limitation imposed by the ground station on the extended tuning screen. It should be possible to change the parameters from the “Full Parameter List” or “Full parameter tree” screens. If these aren’t visible then you can make them visible from the Config/Tuning >> Planner screen by setting the “Layout” drop-down to “Advanced”.
Of course it should be possible to change these values from the extended tuning screen and the reason it’s not is probably because the mission planner is using out-of-date parameter descriptions. This is really an MP issue that’s out of my control but you can force it to update by going to Flight Data and pressing Ctrl-Q and then push the “Paramgen” button.
Randy,
This is the screen I get to set parameters, and if it goes red, it will not write to the PH.
I can’t seem to find the “Paramgen” button …
Randy,
I think the biggest question here is - What happened the second before this radical steering started to cause it to do this?
John,
It’s hard to be completely sure but my guess is it was some external disturbance that caused the speed controller to become unstable.
Could not try the beta Rover due to MP not letting me update the firmware, but the following changes were made as suggested by Randy:-
ATC_SPEED_P from 0.2 to 0.05
NAVL1_PERIOD from 6 to 8
TURN_MAX_G from “1” (G!) to a more realistic 0.3 or even 0.2.
Unfortunately not much difference to the last test on the 18th July.
But did try a number of speeds - 2m/s, 3m/s and 4m/s, the slowest was very bad (see yellow track)
But here comes the REALLY INTERESTING part -
Why is it in the exact same part of the mission that things go wrong?
Something very fishy going on here!!!
Here is the video from 20180718 (pink trail)
Here are the logs from today -
JohnE,
I’ve had a quick look at this and it appears the same wobble as before is happening. I suspect that reducing the ATC_SPEED_FILT from 10 to 1 may resolve it but I’d like to think about it a bit more.
1 Like
Here is some disscusion of ruder input and drift. It looks like exact things happening on the video.
"How Does A Rudder Help In Turning A Ship?"
Thank you Randy, this was more testing today with the latest MP version and Rover Beta, no change.
I changed the mission slightly to see if it makes a difference
I got quite excited with the first pass, then when I repeated I saw it going all over the place.
JohnE,
That’s no fun.
We may be descending into just taking shots in the dark but if you’re going to do another test run, could you try setting the ATC_SPEED_P to 0? Surely this will stop it from wobbling although it’s speed control might be a bit worse than normal. The good news is that if this doesn’t work then the problem is something different than I expect.
One other thing that comes to mind is that it could actually be the lane control although I don’t think it is because we are not seeing the desired speed drop in the logs, but it might be good to increase the WP_OVERSHOOT to 5.
Will do Randy. I just find it amazing that it has similar ‘weak spots’ on each pass.