We’ve had a recurring issue with our Blueboat, which we thought was initially due to just really poor conditions with 30+ kt winds. If you can see from the image below (captured on a very calm day!), the Blueboat seems to squeeze two parallel lines of travel together, leaving larger gaps between every other survey line. It always looks like it’s not compensating enough to turn to the left (e.g. it always leaves the transect line to the left of direction of travel, rather than being over it).
Hi @Vincent -
I’m a bit confused - was the image taken in conditions with 30 knot winds, or a very calm day? Generally the unit should track the survey course perfectly, but if there are strong conditions it may not be able to overcome them.
Have you modified any of the default parameters, particularly around steering?
If you can share a .BIN autopilot log from one of the missions that exhibited the behavior, we can take a look!
No, the track above was in very calm seas, which is why I think it’s some sort of setting. No, we haven’t touched anything in the autopilot settings aside from the survey speeds.
The mission BIN files were too large to share (88mb), so here’s one with the Blueboat just on if you can look at autopilot parameters. 00000034.BIN (340 KB)
We ran a mission with more transect separation yesterday (2m) and the problem is still there but doesn’t scale (so still staying to the right of the transect travel, but not proportionally the same as with narrower transects).
This may get more well-informed responses in the general ArduPilot forum, as the developers there have had significantly more involvement with the mission planning and vehicle tuning parts of the ArduRover/ArduPilot codebase.
From personal experience with control systems, consistent offsets are often managed by an integral controller (error integrates over time, so small errors build up until corrected for), so perhaps the tuning is to blame (e.g. through an insufficient ATC_STR_RAT_I or PSC_VEL_I value, in the attitude and position controllers respectively, or saturation/limiting occurring due to the corresponding IMAX parameters).
That said, rather than adjusting those values independently it’s likely preferable to go through the Rover first drive documentation, as your issue may be caused by something else (e.g. steering trim, perhaps due to unbalanced vehicle drag / weight distribution or motor/propeller strength), and the controller tuning parameters are not independent of each other, so should generally be changed together via the recommended tuning processes.
It would be great if you’re able to follow up here with things you’ve tried that haven’t helped, and hopefully with the resulting solution so others can benefit from it too
Interesting, I hadn’t thought the payload would impact this sort of behaviour. Would you recommend doing this sort of rover first drive tuning every time a new payload is attached?
The payload is completely symmetrical, aside from the ping sounder. Since the sounder is on the starboard hull, it makes sense that it has a bit of ‘trouble’ turning to port. I’ll test this when the Blueboat comes back from the field and report back.
Hi @Vincent -
I too doubt that just the asymmetrical ping is causing the affect you’re seeing. Are there very strong water currents? Sharing a mission file, via weshare or similar, would let us investigate further. I didn’t see anything out of the usual in your autopilot parameters, they look to be the stock BlueBoat parameters?
The last mission we ran was in very calm conditions (no currents). I’ll see if I can dig up a mission file that has some more detail once I retrieve the blueboat from freight.
Yes, pretty much all stock settings, just some changes to survey speed.
Is this not a result of the GPS being on one side of the hull? Those lines in the initial image look very closely spaced. You say the issue does not scale either. Maybe the offset of the GPS from center line of the hull is not being accounted for or displayed correctly.
Definitely not! While it is possible to put in parameters to account for the AHRS and GPS offset vs. the center of the vehicle, even without them what is displayed is the GPS position of the Boat, and the position that GPS is being commanded to go. Therefore no offset is expected!
This definitely looks like a speed issue of some kind - I’m still interested in reviewing the logs to see what the cruise speed parameter was changed to, and how the vehicle was generally behaving!
Hey Tony, I’ve finally gotten around to extracting the logs. If you want to have a look at these two missions (files are too big to share directly here): Dropbox
In the end this has turned out to be a little frustrating. The poor mission adherence led to a lot of overlap during transects, which meant there were large gaps in the data and it’s been making the orthomosaics a serious headache! This will be pretty obvious when you look at the logs.
Also @tony-white , possibly unrelated issue but this Blueboat has been a bit finnicky with calibration, requiring us to do a compass calibration almost every time we went to deploy it. This is despite all the compass readings being in the green once calibrated. Once re-calibrated it appeared to run correctly, but there may be an underlying issue there that causes some of these pathing issues.
The other Blueboats I have operated have not had this issue, despite being deployed from steel-hulled vessels that could cause problems for compass readings.
Thanks for the logs, we’ll review those and get back to you.
It’s unusual for a BlueBoat to have calibration issues - I’ve only seen that when additional payloads have been added, and the power wires run too close to the Navigator? Or if the battery cables are not run from the batteries through the keel, below the batteries? How many batteries are you running/calibrating the BlueBoat with?
In this case we have no special payload other than a carbon fiber pole that runs between the keels to attach additional action cameras (I’ve designed a 3D printed part that does this nicely, was planning on sharing it here!) and the ping sounder, so I don’t think there are any particular additional wires that would run near the navigator, though I can have a look.
Hey @tony-white , have you had a chance to look at this? I just ran some missions at Heron Island and although the calibration issues didn’t happen (I made sure to put the power wires under the batteries), it still had the offset issue during missions. I tried a few directions relative to the surf and it seems independent of conditions (e.g. perpendicular or with the swell/wind has the same result).
Hi @Vincent, I am sorry to hear about your issues here.
I have seen your presentation during the stream fest and am really interested in learning more about your added pole between the two keels. Would you be able to share the 3d file for that ?
Thanks in advance !
It’s also interesting that the vehicle seems to drift at a fairly quick rate when completing its pivot turns. You mentioned previously the currents were calm, was there significant wind present?
I also compared your parameters to the default for the BlueBoat, and noticed some things that have been changed that may be affecting your results -
Cruise speed - 1.5 m/s instead of 1 m/s - this should be ok, but trying 1 m/s may be interesting to compare
Compass_Auto_Rot (disabled instead of check and fix) - again not sure why this would cause your issue, or why it was changed
EK3_ABIAS_P_NSE - this has been increased, and should be reverted to default value of 3e-3 [m/s/s/s] - “This noise controls the growth of the vertical accelerometer delta velocity bias state error estimate. Increasing it makes accelerometer bias estimation faster and noisier.”
