purpose of this new topic is to apply ArduRover to conventional RC submarines. In contrast to AUVs / ROUVs, classical submarines run on regular RC equipment (40 MHz /Europe; 70 MHz US). ArduSub is thus of no use. Building static diving submarines for 15 years I initially implemented ArduCopter to achieve stable cours keeping capability because a submerged sub is barely visible in the pond. The heading-hold function of ArduCopter (traditional helicopter, APM 2.6) worked quite well. But higher order modes were not feasable because its a sub - and not a copter. Thus I switched to ArduRover (4.0) running on a PixRacer flightcontroller.
Sub: Oscar Class (Russian SSBN) / scale 1:100 / length 170 cm / beam 18 cm / weight 15 kg / RC operated ballast tanks / calculated (but luckily not yet tested…) max diving depth 10 m.
PixRacer / ArduRover 4.0 / boat configuration / GPS antenna housed in conning tower) / internal compass / SIC radio 433 MHz (works well up to 2 meters diving depth)
Futaba RX30 RT / 12 channels - DSL RX / 40 MHz band
All modes stable under surfaced conditions; heading-hold function in acro and steering mode proves far better than with the previous APM2.6 / ArduCopter combo. Manual mode works surfaced and submerged. Strictly GPS dependent modes dont work under submerged conditions. This was clear from the beginnig and poses no problem.
Final issue to be resolved:
Acro and Steering mode dont work with the sub submerged. I suspect this is due to the lack of speed information - which is provided by the GPS - that receives no signals once its submerged. But I´m not sure whether thats correct - there might be other reasons I´m not aware of…
Solutions I thaught of:
- add the option for acro mode to accept direct throttle input instead of using speed measured via GPS; this feature was implemented for skid steering vehicles I guess (?)
- add additional airspeed sensor funtionality to measure submerged pressure and calculate speed via Pitot tubing - airspeed sensors are available for sailboats only
Solving this final issue would create an entirely new application for ArduPilot and make ArduRover instantly usable for the entire community of conventional RC subs drivers.
I´ve uploaded current parameter files, dataflash logs, t-logs plus videos and pics here:
You could put an encoder on the prop shaft for testing. This would not report accurate travel distances, but with a speed input, acro and steering mode should be working. You would have to play with the wheel diameter parameter to get reasonable speed meassurements.
@ Dave @ Sebastian - I appreciate your comments very much - adding an encoder to one of the drive motors sounds compelling. Before making the effort:
- encoder on one of the two drive motors sufficient?
- how would the prop-encoder affect surfaced and thus GPS based navigation?
- Sebastian, it appears you already fitted encoders onto BL-outrunners (driving my sub as well). You got recommendations on the hardware? The shaft does not protrude on the “backside”. Using a plug on encoder (Pololu) is no direct option. Where did you place the mags and the encoder? Have you tried optical encoders as well?
I have just done a PR for NMEA water speed sensors in sub and rover.
Report only at this stage tho, would require some more work to use in the loop.
I do not know how the EKF would handle a difference in the position reported by the encoder(s) and the GPS.
Encoders on wheels are also not 100% accurate, because of wheelslip, so I guess, the GPS should become the primary position source once it is available. There should be others around here, who know more about this than me.
An encoder for ardurover only requires two on/off signals, 90° offset.
I have built and used different encoders so far:
Optical encoders reading two black and white tracks I printed on paper and thenglued the paper strip around the motor bell.
The tracks were 90° offset, so the sensors could be mounted side by side without offset.
Magnetic hall sensor encoders.
The simplest form would be a rectangular magnet glued to the back of the motorshaft, so north and south point radial outward, not the way the magnet normally wants to stick to the shaft. Then two hall sensors 90° apart and you have a crude, but working encoder.
If your drive motors bleed enough magnetic flux to the outside of the bell, you could use the motor magnets as input for the hall sensors. This would also be a very compact solution.
The best encoder I used so far are the AMS AM5047D magnetic encoders on eval PCBs. They read a diametral magnetized disc glued to the motor shaft end and provide all kinds off output with great precision. They are not expensive, but only available from the US from Mouser or digikey, even so AMS is an austrian company.
Hi Sebastian - Hi Dave,
I went with your suggestions with some success.
One motor now carries a Pololu wheel encoder (https://www.magentacloud.de/lnk/8eiAF05H)
I followed Randys protocol setting up the wheel encoder https://ardupilot.org/rover/docs/wheel-encoder.html. The encoder is reconized and puts out ground speed values on MPL - wheel diameter and counts/revolution tuned so encoder speed matches GPS speed.
First aim is running the sub surfaced (with GPS contact) in all GPS independent (manual, acro) & dependent modes (steering/auto/rtl/guided)
The second aim is to run the submerged sub (without GPS contact) in acro mode to facilitate course keeping - auto mode is no issue here
Wheel encoder works and puts out ground speed on the MPL
Speed measured via GPS & WENC match closely.
However there are issues running the sub using either EKF3 or EKF2:
ACRO mode NOW makes for good course keeping of the submerged sub (i.E. without GPS) because the WENC provides speed data. BUT AUTO mode fails completely because position estmates with GPS (blue line in screen shot) does not match with POS (red line). I tried to work around the problem by altering the AHRS_GPS_GAIN and EK3_GPS_TYPE parameters without success. I attached the parameter and log files for people familiar with the details[https://www.magentacloud.de/lnk/9BiAlLJE] (https://www.magentacloud.de/lnk/qoigFxjQ) (https://www.magentacloud.de/lnk/ayigFbyD)
EKF2 is not for wheel encoder use. But it works nicely for auto mode as seen here (https://www.magentacloud.de/lnk/GBiglRhX) - parameters are here (https://www.magentacloud.de/lnk/NNCglKyq) but no course keeping in ACRO with the submerged sub because the WENC is not recognized - and thus there is no speed information.
Solution 1 would be to use EKF2 AND to provide speed information when GPS is not available (i.E. under water)
Solution 2 would be to use EKF3 and to improve the integration of GPS and wheel encoder data to optimize position control
Solution 3 is what I havent thaught but YOU did…
Looking and waiting for your ideas,
A short video illustrating drive by in AUTO MODE https://www.magentacloud.de/lnk/l3iAFg5b
First: Subs, full size or models, are just great!
Did you set the EKF origin through Missionplanner? Right click on the map, Set EKF origin here.
If you got a stable GPS fix and set the EKF origin at the location of the GPS position, it might help. Just guessing, though.
setting the EKF origin manually to match with the GPS home position fixed the problem:
I ran the boat surfaced (graph indicates sat #). First in acro mode (green bar). I than switched to auto mode (purple bar). The map illustrates a pretty good correlation of GPS (blue line) and EKF based positioning.
The 2nd figure illustrates yaw keeping of the submerged boat without yaw input (n Sats red, ATT yaw green). Attitude keeping is resonably good. Attitude yaw fluctuates (as exspected) a bit around the desired heading. What still confuses me is the increase in attitude (yaw) deviation that occurs with time when there is no GPS connectivity as seen here between 11:00 and 11:05 hrs. Establishing a GPS link (surfacing) improves course keeping significantly.
Any idea(s) on how to tackle the issue are appreciated…
Overall the comments and suggestions from the forum have been extremely helpfull - BIG THANKS to everyone.