Conventional Submarines - ArduRover

U-Boat · July 20, 2020, 7:02pm

Dear All,
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.

Current project:
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.

Flight controller:
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)

RC gear:
Futaba RX30 RT / 12 channels - DSL RX / 40 MHz band

Status:
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:

https://www.magentacloud.de/lnk/lViglwVx
https://www.magentacloud.de/lnk/JqCgFApa
https://www.magentacloud.de/lnk/xIigFbFf
https://www.magentacloud.de/lnk/NCCAFlwU
https://www.magentacloud.de/lnk/IBCAFJmg

Regards,

Theo

dkemxr · July 21, 2020, 1:50am

Wheel encoders can be used on Rovers for vehicle speed w/o GPS.
There are a few sensor types for water speed. Pitot as you state, old school paddle wheel and electromagnetic. The latter would be interesting but they all seem to come with their own displays so not sure what the data protocol is from the sensor.

count74 · July 21, 2020, 6:34am

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.

U-Boat · July 22, 2020, 7:44pm

@ 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?

Best Wishes,

Theo

iampete · July 22, 2020, 8:29pm

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.

count74 · July 23, 2020, 7:07am

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.

U-Boat · August 29, 2020, 6:09pm

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.

Purpose
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

Results:
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:

EKF3
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
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.

Conclusion:
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,

Theo

U-Boat · August 29, 2020, 6:15pm

A short video illustrating drive by in AUTO MODE https://www.magentacloud.de/lnk/l3iAFg5b

count74 · August 29, 2020, 6:46pm

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.

U-Boat · September 22, 2020, 12:00pm

Hi Sebastian,
Dear All,
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.

Regards,

Theo

iter · September 30, 2023, 3:38pm

I’m also working on a submarine. I thought I’d put my findings here instead of starting a separate thread, so that people searching for this topic can find the info in one place.

Basic Boat

I’m starting from an old Thunder Tiger Neptune kit. This boat looks goofy, but is improbably overengineered. She has a proper WTC and a static diving system with a flexible bladder inside the WTC. She comes stock with a microcontoller board that forces ballast flush in four emergencies: radio signal loss, leak detection, low battery and ballast overpressure. My example came with a 75 MHz, 6-channel radio.

The basic boat works very well. My only complaint is that the dive planes are too small. My solution is to print a set with double the area. Now the boat’s pitch response is excellent.

ArduPilot Installation

Like on a real submarine, there is little free space inside the pressure hull. I have a Matek H734-WLITE controller, a GPS and a Blue Robotics Bar30 water pressure sensor. I also have an 8-pin Cobalt waterproof connector from Blue Trails Engineering. This allows me to charge the battery without opening the pressure hull. The same connector also carries the USB connection to FC.

To feed R/C commands to ArduPilot, I identify the interface between the RF section and the digital domain on the stock 75 MHz receiver. This signal is PPM (a.k.a. “CPPM”, “PPM-sum”). This goes into ArduPilot’s RCIN and works without further modifications (as long as signal is strong–see open issues below).

Open Issues

I’m working on a couple of issues that relate to ArduPilot on this vehicle. From simple to conceptual they are:

Noise rejection in analog PPM

ArduPilot has excellent support for PPM input, but my use case is a little less common. I need longer wavelengths to penetrate underwater. Most users get cPPM from receivers that emulates PPM in software from its digital over-the-air protocol. These receivers generate crisp square waveforms. I’m using the output of an analog RF section on a system that uses PPM as its over-the-air signal. When signal quality degrades, I get noise on the RCIN line, which ArduPilot interprets as wild servo swings. It is a relatively simple software task to reject this noise in software. I have a separate thread on this topic: PPM garbage detection.

Water Pressure Sensor

I am so far unable to read the water pressure sensor. I understand that there is support for it in AP_Baro, and this support exists in ArduSub, but hasn’t made it into other vehicle types yet. There is a bigger question about integrating this sensor into the EKF. It is sort of an altimeter, but the EKF makes assumptions about altimeters being in the air. I need a way to tell the EKF that the sensor is in a denser fluid so it scales the altitude calculation appropriately.

Pitch and Depth Control

There is an open question about the best vehicle type to start from. ArduSub has support for relevant sensors and deals with water density for depth calculations. It is a derivative of ArduCopter, which uses completely different dynamics from a traditional sub. ArduRover has support for boats, including things like station keeping and accounting for currents. It has no support for pitch or depth control. ArduPlane has the closest dynamics model to a submerged traditional sub, including pitch and altitude controllers, but also has many features that are irrelevant. I’m curious how much tuning it would take to get ArduPlane to work in a denser fluid.

geofrancis · October 1, 2023, 10:13am

I have a graupner seawolf v2 with an omnibus f4 pro, I ended up using Inav setup as a custom plane to make it fly underwater. For depth control I had to do a load of sensor hackery where I converted an analog pressure sensor into a fake rangefinder, since inav can do alt hold with just a rangefinder I just mapped a pressure sensor so that 2 meters down would read as 0 meters aka the ground, so at the surface it registers as 2m altitude. I don’t go below periscope depth as I would loose video from my periscope.

Ardupilot is much more sophisticated, so hacks like this won’t work. I have been trying to find a way of emulating a barometer using something like MSP or just emulating a i2c sensor. but i havent made anything yet. if I can get a way of emulating a pressure sensor then it makes adding and testing sensors very easy as it would just be a matter of using the arduino library.

It still leaves the problem of rover having no pitch or roll control, I have this problem on my other boats where I have installed a moment control gyro for roll stabilization and I have had to add a helicopter tail gyro to run it.

The GPS is just installed there temporarily, the plan is to eventually put it in the mast with the camera, so it can navigate at periscope depth. It will lose signal more than a few milometers underwater.

868/915mhz works fine for RC as long as you’re not going more than a meter underwater or in salt water. Then you’re going to need to look at 433mhz or even 75/40mhz

2.4ghz or 5.8ghz video will lose signal as soon as it goes underwater, I might try 1200mhz or 900mhz video at some point to see how it does.

U-Boat · October 3, 2023, 12:09pm

Hi - thaught today I´d summarize some of the hardware I´ve used to run my sub @ 40 MHz

TX Futaba FX30 40 MHz
RX ACT DSL DSQ (RX diversity system) - PPM 12 CH - RX provides no PPM sum signal for the flight controller - thus individual (12) servo signal lines connect to a
signal converter (https://www.flyingtech.co.uk/electronics/rmilec-v3-18-channel-pwm-ppm-sbus-signal-converter) that generates the SBUS input for the
PixRacer R15 flight controller
only rudder servo and ESCs connect to the PixRacer servo rail
everything else connects to RX servo rail
diving system (dual piston tank - 500 ml each) and diving tank controller ( Modellbau Alexander Engel KG | U-Bootmodelle | online kaufen) connects directly to RX servo out
pitch and depth controller unit ( http://www.modelluboot.de) - connects directly to RX servo out
GPS mounted high up in the conning tower
compass RM31000 (Drotec)
telemetry radios 433 MHz (50 mW, 3DR) - GCS side via USB to Win10 laptop or via USB OTG to android phone

notes:

pitch and depth controller is really a must for a proper diving submarine - should fit in the Neptune
antenna running straight out worked best for me - allways had problems with kind of loop antennas
I never achieved to eliminate interference between 40MHz RC and 433 MHz telemetry signal
telemetry is essential in many ways monitor pressure inside the WTC for watertightness etc
I got stable RC connection @ 40MHz for up to 5 m (pool)
never went that deep at the pond because you loose visiual contact below 1 m plus

More to come later on diving @ 868MHz

geofrancis · October 3, 2023, 12:30pm

868/900 is well tested, you will loose sight of the sub long before you loose RC. the telemetry is very useful for monitoring the sub.

iter · October 3, 2023, 6:54pm

Thank you both @U-Boat and @geofrancis for sharing your experiences! The results on 915 MHz are more encouraging than I thought. Thank you for sharing the AMS link, although “loose sight of the model” is a less useful measure than the straight depth measurement in @U-Boat’s post.

I agree that pitch control and depth hold are essential for functioning subs. I would prefer to incorporate these into ArduPilot directly. More than eliminating unnecessary hardware, it would make it possible to integrate depth control into mission planning. R/C sub controllers are designed to work with manual control. I haven’t seen one which accepts a depth request in meters.

U-Boat · October 3, 2023, 8:08pm

thats right - setting diving depth in absolute terms would be kind of nice - but whats more important to me is keeping the boat submerged at a stable depth and in neutral trim - no “dolphining” - it would safe space and cost letting the FC do the job - someone (but not me - I’m a non-coder) needs to write some code…

note

@ 900 MHz you have only a tiny depth window of 1.5 m
GPS contact is lost immediately once submerged - you are limited to manual and acro mode - the latter requires a wheel encoder - no auto missions unless you’re @ periscope depth and stick out the GPS antenna
stabilization in the roll axis has’nt been implemented in real and model subs afaik - turning creates considerable hydrodynamic forces on the hull causing movements in pitch and yaw axes - mostly list inside curve and pitch up

geofrancis · October 3, 2023, 9:46pm

im not sure if it will be any use but ardupilot supports water speed. “NMEA water speed” sensor is supported as a type 13 airspeed sensor

iter · October 3, 2023, 10:59pm

There is insufficient space on Neptune to fit a full-size water speed sensor. I’m sure it would be helpful on larger boats.

I saw the discussion earlier in this thread about counting RPM to estimate distance. I imagine that dead reckoning would work about equally well. I’m sure you can can compile a table of speeds as a function of battery voltage and throttle percentage and use that to estimate distance without a shaft encoder.

I wonder how far you can get with dead reckoning. Compass still works underwater, so you can track a course, and you can estimate distance. I’m curious how far this can work.

From what I can see, few submarines have direct roll control. I remember–when first learning about submarines–thinking that dive planes would have separate controls, like elevons, but apparently most have them moving together like elevators.

geofrancis · October 3, 2023, 11:41pm

I have plenty of analogue pitot sensors sitting around, it might be worth testing one underwater.

this script could be useful, as it can switch the vehicle between wheel encoders and gps on the fly.

Another thing i was looking at was optical flow, as long as you can see the bottom then it should be able use flow for guidance.

iter · October 4, 2023, 1:47am

Here is the radio setup I use now. My boat came with the state-of-the-art 6-channel, badge-engineered, 75 MHz ACE RC TX/RX pair. I think the silver sticker on the bottom is an artist’s conception of the Neptune boat. There are a couple of challenges with this TX. Improbably, the worst is the analog trim. It keeps getting bumped and moves, e. g., the throttle off neutral, so as soon as you power on the boat, the motor starts spinning.

Graciously, ACE engineers designed it as a modular system, with a separate encoder and RF section on different PCBs. I understand that the system was available in several combination of bands, 27, 35, 40, 72 and 75 and AM or FM modulation. Mercifully, there are only three lines between the boards, clearly marked GND, VCC and MOD in the silkscreen. No weird 6V lines or such. So I took the RF section out and printed a module housing for it.
20231003_185334

I was able to reuse all the little bits including the antenna, mounting screws and antenna feed bracket. Regrettably, the PCB is just too wide to fit in the module bay, so the module is fat, sticking about 3/4" back from the TX.

Just for fun, I made the crystal accessible, although it’s extremely unlikely that I would ever need to change crystals. Now I get to use my normal TX programming features, and the trims stay in one place.

I’m curious if I’m getting less range with my TX16S than I would with the stock TX. Stock TX runs on 8 NiCd cells (maybe even 8 alkalines originally, 12 V). TX16S runs on a 2S LiPo, 8.4 V on a fresh charge. I wonder about using a 3S LiFe in my TX. Every piece of literature I’ve seen gives TX16S max voltage as 8.4, although I can’t immediately think of what I would damage if I run it higher.