Hi I have an ardu boat and it works very well. But every now and again I have GPS errors and when I lose GPS it goes into a fail safe and I can then only use it in manual mode, but if it is in long autonomous transit and I am not near enough to control in manual it just stops.
The planes have RTL or to rally point if they lose GPS in auto mode, and it appears that rovers have an encoder option with EKF3, is there anything like that for boats? Can you use throttle as an estimate for speed and heading as reference, like a heading hold autopilot to get it out of area where GPS is having problems?
It also makes me ask, does the EKF3 work with only a single speed encoder and the compass? Or does it always need a differential encoder setup? Many boats have a speedo that uses a small water wheel and send pulses, maybe I could modify that to input a single encoder channel as speed?
If GPS is lost it cannot RTL or Rally in Plane. How could it?
This only works with Rover because it depends on no wheel slip/spin. It would not work with a boat.
Plane Failsafe Function â Plane documentation (ardupilot.org):
Section 3: 1. Detect loss of GPS for more than 20 seconds and switch into Dead Reckoning mode until GPS signal is regained. See Dead Reckoning Demo on Plane - YouTube for a demo.
Your Comment: This only works with Rover because it depends on no wheel slip/spin. It would not work with a boat:
I agree but the boat and the plane have more in common than the boat and a rover, in that you can wear the accumulating dead reckoning error in a large body of water without being in a highly structured environment at least until you get out of GPS dead zone. Without checking the specific code I would say the plane uses velocity data from the airspeed sensor (pitot tube) and then uses heading from compass to do the dead reckoning. In a similar way most small fast boats or personal water craft have a speed sensor (water wheel which sends a coded pulse) which could be modified to give a speed value.
So what I am really asking is can I provide some form of speed input and use the same dead reckoning function the plane uses or alternatively does the rover EKF3 work with only a speed input and the compass to do the same? I could then quite easily get the signal from the speedo and convert it into a quadrature (AB) signal and use that to get me out of the dead zone?
Alternatively I could also use the throttle as an indicator. On my Arduboat (Jetski) the thrust is so incredibly large that it is the most dominant factor in speed. I have tables for throttle vs speed and even with different water sea states it is still pretty reasonable as an estimate (probably more accurate that wheel encoders given there is always slip.
I think it might be possible (with some software development) to allow boats to dead-reckon using a water speed sensor in place of the air speed sensor that Planes use. I donât think that throttle could be used though. The first step might be to find a water speed sensor that we could write a driver for. The next step would be wiring that into the EKF and testing.
Copter also supports dead-reckoning is wind speed estimation is setup but in practice it only works for about 30seconds and it is very copter specific.
Hey Guys thanks for the speedy responses. It is surprising how good a correlation the throttle value is on speed for my craft, it does however have about 8KN of thrust :). But that only holds for about a third of throttle and up (once up on plane) and is probably only specific to the jet ski platform. The waterwheel sensor is actually used on almost all jet skis and something similar has been put into most modern outboard motors for the same reason. It is also something that could easily be made for any ultra low cost (boogie board) platform.
Does EKF3 still function with a single position, distance input from an encoder, or does it need the two encoders to calculate turn rates independent of compass and rate of change of heading? I could test some basic functionality by reading the speedo on Jetski and working out how many pulses give what distance then get a small arduino and inject it as an encoder signal equivalent?
Even a single wheel encoder will provide info to the EKF which will help with its estimation. Non-GPS using wheel encoders is a bit different than dead-reckoning with an airspeed sensor though. To do it really well I think we would need to add support for a new type of sensor (e.g. water speed sensor) although you could certainly try a test as you describe.
Again thanks for the very speedy reply and great info. I guess the making something speed related pretend to be position related introduces lots of error with the required integration but I would assume you use the air speed data on planes as the direct rate observation to the EKF? Do any of the EKFs on rover / boat firmware still use speed as an observation feedback variable?
We use the same EKF in all the vehicles so you could even theoretically put an airspeed sensor on a boat and it might work but probably not well because boats move much more slowly than Planes.
The way that the EKF fuses the airspeed sensor output is different from how it fuses GPS velocities (most GPS provide position and velocity) which is again different from how wheel encoders are fused⌠so thatâs why I think we would need to enhance the EKF to fuse a water speed sensor.
Does the existing rover work with a single quadrature encoder for distance travelled? Or does it need a left and right to work out turn rates etc, or can it just do it from rate of change of heading (compass and the rate of change of position by encoder)?
Hey by the way your videos etc are awesome, thanks for all your efforts.
Regards
Ralph
Believe it or not the airspeed sensor would work in autonomous as the boat is going at 35 knots cruise speed 
But yes it would not be very reliable for anything other than that.
So I could theoretically feed in an analog value based on the existing water wheel and set it up as the airspeed sensor? How does that compare to doing the same with a single encoder; I really just want it to switch to using the not so great sensor when GPS fails just to get it out of the black spot, I would hate to dilute the accuracy of the normal filter with GPS active. I saw something about the LUA scripts for automatically switching between the normal EKF and then switching to the EKF3 where the encoders are used, is it possible to do something similar with the mocked up airspeed sensor? Or can I just make it use GPS as the primary and make it disregard airspeed until GPS goes down?
water speed is supported via a NMEA water speed sensor is and is selected as a type 13 airspeed sensor.
Re transitioning between GPS and Non-GPS (airspeed, wheel-encoders, etc) we have some info here.
Re wheel encoders, even a single wheel encoder will be fused so the EKF will use it for calculating velocity and position. It cannot not use two wheel encoders to calculate yaw⌠that needs to come from another source like the compass.
Thanks for the information, what is the specific NMEA message? for the water speed sensor, is it defined anywhere? I could do a very small microprocessor to read the existing pulse rate from speedo and translate that into an NMEA message.
Gent thanks for all the information. I will check out the references you have given me and I am sure it will spawn a lot more questions. Once I get it going I will get you the data or give you some feedback as it may inform the next iteration of development to make this a capability in a future release. Again thanks for your time and effort.
should have said Gents and or Ladies
this is the pr for it
Is there any reason that ded reckoning couldnât be performed with only accelerometer and/or gyro data? Especially if thereâs multiple sensors on board these should be able to be fused into a common noise rejection scheme to improve accuracy and performance, right?
I have checked out all the information, and still have some questions with regards to both the EKF fusing vs Non GPS guidance and with regards to Airspeed/ water speed NMEA sensor input.
- If I input Speed data via the NMEA water sensor input and itâs not great data will it corrupt the EKF or is the GPS input heavily weighted? Is this why you switch between GPS and encoders as a âone or the otherâ and not both as inputs?? Or is it just that the Normal EKF function canât run GPS and encoders simultaneously?
- It seems from the documentation about air sensor, that it fuses fine with GPS data etc?? Does that mean when the GPS goes out it just automatically continues in Auto mode using the airspeed data for velocity and there is no need to manually switch sensor inputs as in the GPS / Encoders switch?? Or do I have to change some settings to stop it going into loss of GPS failsafe and just continuing in a dead reconning mode??
- GeoMuir, thanks for that great info, before i get the sensor I wanted to experiment, is the actual output message for speed extraction from the DST800:
$VWVHW,s.s,N,s.s,K*hh Where the s.s is the speeds (Knots and KM/Hr) and all the course over ground is just blank as the sensor doesnât provide that info (just blank commas)?
Sorry GeoMuir, the VWVHW string I showed should have had several more commas with no spaces to show empty data for the Course over ground part of the VHW message string (the message editor doesnât allow it).