Hi! I’m planning to build a boat capable of sailing around the world. What controller would you recommend for a project like this?
Whatever will do the job hw is mature now and got low failure rate.
What you should focus is your boat global architecture as this will impact what type of board you need.
Keeps in mind that some countries start having regulation on autonomous boats.
Great, but to start testing, I need to make some choices first!
Find me on Discord for future discussion.
Thx
So I ordered Pixhawk PX4 2.4.8 Waiting for delivery
for a first test, probably take on cheap. High probably to sink !
pixhawk 2.4.8 isn’t a great choice as that is some random quality chinese componant …
I am working on something similar,
One thing you have to be aware of is that ardupilot has to be restarted every 4 days.
Have a look at this
And this
Hi @geofrancis,
Do you really think AP needs to be restarted every 4 days?
I created this list of potential wrap issues in the EKF but as far as I can tell none of them would require a reboot.
@rmackay9
the only mention i can find of time issues
https://rsaxvc.net/blog/2024/2/4/ArduPilot_A_Matter_of_Time.html
I could never get my rover to stay responding for more than a week, I never knew why until @khancyr mentioned it.
I believe tridge fixed it on linux but its still an issue on microcontrollers.
Hi @geofrancis,
Ok, here is the PR from Tridge to fix the issue for Linux.
If this is so serious though we should have an issue for it so I’ve created one here.
@rmackay9 This is what I was talking about when i first head about someone talking about there being a 4-day limit. that was when I went looking and found that blog post, I assumed they were related. Sorry for the confusion, that blog post was the only documentation i could find on any kind of long term time issue with ardupilot that had a fix, and when I seen the fix was for Linux I thought that it was only fixed on linux not that it was a linux only problem.
this is the part from the locarb blog, its the only other documentation I can find of the issues im experiencing.
Navigation (Pixhawk 2.4.8)
LOCARB navigation is based on open source Ardupilot software with a Pixhawk 2.4.8 flight controller as its hardware base. The pixhawk controls the GPS, compass, telemetry, IMU, and rudder servo. Being an Ardupilot based navigation system, freely available ground control software (such as Mission Planner) makes for creating way-points “simple,” and allows for easy two-way communication with the autopilot.
If I was to build another boat, I would most definitely not use this platform again. It introduces too many unknowns into the navigation process, has too many frivolous settings required to get it operating correctly, requires another hard to understand Arduino library to control it, and is unreliable.
When powered on for 1 week durations with no reset, the autopilot fails to respond to new waypoint commands without having to be rebooted first. It also loses control of the rudder randomly and requires a power cycle to get the rudder operational again. It seems to lose track of the heading over time, and just introduces too many unknowns in the way the boat navigates because it is generally unstable. I just couldn’t trust it to do what it was told so was left second guessing why the boat was behaving as it did (was it the wind/currents pushing the boat or the autopilot?). With the limited amount of data available during the journey, it was problematic trying to troubleshoot. I say stay away from these solutions.
I would usually find it unresponsive since i didnt keep mission planner connected but would check it every day. most of the time it wouldnt connect or when i did connect there would be just weird telemetry coming from it like it would be doing 400meter circles at high speed despite it being parked in the garden, or the hud was doing backfips every few seconds.
Hi @geofrancis,
OK, so I guess you think maybe we don’t have a 4-day problem then? … or maybe you’ll leave your autopilot up for a few days to be sure it is OK?
It’s too bad that the LOCARB person had such a bad experience. There’s no log to analyse and so it’s just a guess but it seems like his vehicle had estimation issues (e.g. EKF and/or DCM) and he struggled with AP’s complexity.
I’m keen to help anyone who wants to create a boat to cross a sea or travel around the world and I think AP can do it.
I think there is something there,my rover was outside in the garden for months last year and every morning I would connect using mission planner, but eventually after a few days it just wouldn’t connect over either the LTE or UHF system until i went out and hard reset the board, another strange thing I would notice was I was still getting some mavlink packets coming though via my RC system as it converts mavlink to crsf, but there was data missing. I think something is overflowing somewhere or something is getting out of sync and a side effect of that is mission planner won’t connect.
The H743 chips have a habit of corrupting the EEPROM so I spent a long time redesigning the power system to totally isolate the flight controller on to its own power supply with a UPS in case it was a power issue but It would still go offline.
Hi @geofrancis,
Yes, as discussed on the dev call, it’s possible there are issues because very few users leave their vehicles running for more than a few hours. Looking forward to some logs so that we can dig into the problem.
I experienced that long time ago. So it may have been fixed since.
Best thing would be that we test bed this to ensure that we don’t have some overflow or weird issues.
I am still overly busy by work but I still have in my to make some ArduBoat stun and try crossing some sea to another developer autonomously !
This site maybe helpful, It’s the Microtransat challenge, to sail an autonomous 2.4 meter or less boat across the Atlantic ocean. Since 2010 many boats have tried, few have made it. There’s a Google groups you can join, I used to be part of it, lots of good discussions and you can ask question and get experienced answers. Good luck,
I have a pixhawk, a omnibusf4 and a Matek h743 with 32gb SD cards logging at 1hz so hopefully that highlights something after a week.
Apparently the flight controller will reset if it crashes, but I think that would only work if it totally crashes but not if its operating with crazy values. To get around that I added some GPS navigation code to my esp32 companion computer, the idea is that it pulls the current waypoint from ardupilot over mavlink so it can calculate the route independently using its own GPS and compare it to the heading autopilot is trying to do, so if I see the headings diverge then something is wrong. It could be done with 2 flight controllers but the second controller doesnt have to be that complicated it just needs to know where it is and what direction its going. I also use it as the backup system, if there is a low power power emergency where it cant power the autopilot flight controller, the esp32 can go to sleep and consume a few milliwatts, then wake up after a timeout, correct the heading and go back to sleep until it gets enough power to startup the flight controller, communications and its proximity sensors. the time asleep can be extended as the battery gets lower, it should be able to run for months in this state even with total power generation failure.
My original idea was to not use the extra controller and just use a flight controller with everything running in lua. but due to a combination of H743 memory corruption when it has a brownout and it was acting strange after a few days i had to use a companion computer to monitor it.
https://ardupilot.org/copter/docs/common-watchdog.html
from the locarb page, information about configuring ardupilot for heading out to sea.
The problem of not being able to enter auto mode until the EKF is happy, they just spammed change to auto mode until it eventually did as there wasnt a EKF message to monitor.
INITIAL_MODE,10 Despite setting this, if GPS or EKF is not stabilized on boot, it will not start in Auto mode. Since GPS takes a few seconds to get a fix, this always fails.
gyro calibration has to be disabled, as well as all failsafes
Hi @geofrancis,
We could probably change Rover so that it allows the vehicle to go into Auto mode while disarmed even if it doesn’t have a good position estimate. This is how Copter behaves and the only reason we don’t do that in Rover is because of the ability to bypass arming (see ARMING_REQUIRED parameter). I’m not a fan of being able to bypass arming but I don’t want to upset people by removing the feature.
What about adding the potentially dangerous options as options in the custom firmware builder, that way it’s unlikely to be used by mistake since its only going to be for very specialised use cases.