Flight controllers as sub levelers

Has anyone here have any experience with setting up a flight controller as a leveler? I am currently looking at INAV on an omnibus f4 pro board as I have used them a lot on boats drones and planes running ardupilot so im very familiar with that hardware.

Using the custom mixer its relatively easy to set it up as a rover with custom outputs but I dont think it will do all the things we want without a lot of messing around as you dont need attitude control on a surface vehicle. we can get it to stabilize each axis but it wont level it.


I have set up boats as custom airplanes on old versions of nav, it works as long as you dont use any alt hold functions.


has anyone else got something like Inav or any other flight controller working on a sub?

I set up a wing flight controller (Matek F411-WTE) for use with a sub.  It was painful getting the throttles (it will be tested on a type II u-boat when that sub is finished) to work as i would expect them, but other than that, it was a small learning curve to understand how INAV works.

I did have to use the CLI to configure some of the settings, they simply weren't able to be set the way i needed using the GUI.

I am not sure if it was this website, or rcgroups.com, but i was in a discussion regarding this exact topic, while setting up that FC with another member, who had already gone through the setup, and he was explaining how to basically set the failsafe to work as expected.

and yes, if you think about it, a submarine is more like a plane than a ground vehicle, with its dive planes acting in the same capacity as an airplane's elevator.

the big advantage is that for basically the cost of a pitch controller, you get a pitch/yaw/roll controller. (after a lot of setup)

most of the subs i build don't need pitch controllers, so i will wait to see if the extra brain damage to set it up was worth it.

yes I had a lot of headache getting an old inav controller on a boat with dual motor. The main problem is an aircraft mixer will never run the motors in opposite directions. so it can do differential thrust but only in one direction at a time.

several of the CLI settings were related to the throttle,

fwd/reverse flag
neutral value
max value

it was not giving me a usable neutral that would allow the ESC to arm, so i had to bump that to 1500, but it was not a simple change of that, i had to alter the max so that the middle would increase accordingly... very weird way of doing it.

I belive you need to enable 3d motors to get forward/reverse to work. otherwise it just assumes the motors are one way so sets 1000 as zero throttle rather than 1500.

All of that was set "correctly" according to what i could find, but the pwm value that it considered to be "zero" was 1470, which was just enough off from 1500 to keep the ESCs from arming.  i still have no idea why it was using 1470 instead of 1500.

the very nature that INAV was basically a black box, and i had no real control over simple things like that kind of soured me on using flight controllers. how INAV works, and how my brain works are not the same way. too many times either the documentation sent me down a road that was completely not where i wanted to go, or you had to drop into the CLI to set something simple kind of left me wondering why anyone would want to go through this pain to set up a FC.

and of course the youtube videos are fantastic if you want to setup a tank or a drone, but not if you want to set up something that is neither of those.

that's why I started this thread as there is very little information on inav with surface vehicles, even less on boats and nothing on subs. The plan is to try and come up with some setup that can be replicated so others dont have to go through it all .

I have used cli to setup inav with a custom airplane mixer to run a tugboat so im well aware of all the problems, funnily enough the auto levelling and pitch control is the easy part. I believe they have fixed the throttle issues on the latest version of Inav since they have now included a rover/boat preset. I was using an old f3 controller, so had to run a really old version of code that could only do planes and multirotors.


The other reason im installing a flight controller is to get telemetry. it has a whole suite of sensors that you can get sent back to the radio including voltage and current even leak sensors. If you use a blheli32 controller you can use esc telemetry and get RPM, voltage and current from the controller directly.


The other controller I would recommend is a KK2, it has a onboard screen and buttons for programming. it has auto level and custom mixing but thats about it so there is not really anywhere you can go wrong.

several of the Matek PWM adapters support both battery voltage and current.

tsenecal wrote:several of the Matek PWM adapters support both battery voltage and current.

There are voltage sensors for frsky r9 including lipo cell monitors.  They use the same sensor protocol as the X series receivers, that along with the matek adapters could be worth mentioning on your rc system posts.

I was wondering if we can use the inav alt hold for subs, theoretically its basically the same thing. but im not sure how the software would react. im sure it supports negative altitudes.

i was thinking something along the lines of setting the front planes for depth control and the rear planes for pitch control. i could also connect the ballast pump to the depth control planes. im not sure how programmable the mixer is so im not 100% sure i can make it do something like this.

I do plan on listing available telemetry "sensors" in all three 900 systems as one of the posts...  and i agree that negative values should not be a problem for "altitude" on any of the systems.

we could use depth sensor to spoof a rangefinder. inav supports rangefinder altitude so it wouldnt take much to spoof a rangefinder and feed it data from a pressure transducer. basically have a preset "floor" at your maximum depth and set it so your rangefinder is reading your distance from maximum depth. so as far as the flight controller is concerned, it's trying to keep its distance from the "floor". or just invert it so down is up and up is down. but that might take some tweaking of the flight controller IMU orientation to make work.



I have just been reading through all inavs capabilities and i think its going to need to be set up as a plane to get all the features we want. the options for things like levelling just dont exist when you set it to boat, same with altitude hold. luckily inav for planes only require one altitude source so should work with just a rangefinder.


Going through all the protocols and sensors inav supports the 2 best options for interfacing with it is either over serial using the MSP protocal or over i2c by emulating the SRF10 sonar, luckily I have already have code for several rangefinder adapters using the same i2c protocol as its also used by the maxbotics sonars. so combining it with a pressure sensor should be relatively easy.

https://github.com/geofrancis/SR04-maxbotix-i2c-Adapter/blob/main/ApmSonar.ino
https://github.com/geofrancis/hx710B_pressure_sensor/blob/main/examples/HX710B_Basic/HX710B_Basic.ino

Geofrancis, the flight controller conversation was between me and maxx78, in the "868/915 Mhz as a viable frequency for submarines." thread.

https://www.theassociationofmodelsubmariners.com/t1842p25-868-915-mhz-as-a-viable-frequency-for-submarines

basically just search that thread for maxx78 as the user. his answers were interleaved with my questions

I built drones of all shapes and sizes for a living for years, so I have no issues with flight controllers and using them in non standard ways. I have an omnibusf4pro on my desk and have been trying lots of different configurations to see what would work for us. so far a custom plane is the best option, its much closer to a sub than anything else. the main issues are the difference in vertical hold and motor mixer for dual motors otherwise its basically a plane.

I am not 100% sold on vertical hold as a necessity. stabilized elevator/pitch is good enough for me. I understand that "vertical hold" is depth control, but of all the subs i have ever built, i found depth control to be 99% covered by pitch control.

you still need it for holding depth while stationary.  I think he code for aeroplanes will work to keep our subs at a fixed depth, we just need to get the depth data to it in a way it can use.



I think areas inav research should be:

pitch control - mixing servos, auto level flight modes,
level dynamic diving - can we use front planes for depth and rear for level?
RC failsafe - failsafe methods like signal cut or set positions.
custom mixing for multiple motors - possible mixer limitations
Telemetry - what sensors are useful? the glider vario beeper could be useful if you have depth. water ingress sensor?
depth control of some kind - either pressure or use sonar to hold a fixed distance from the bottom, what inputs we can use.


this is a bit further out there if everything goes smoothly:

mixing exotic subs like X tails, im pretty sure it works the same as a Vtail plane
OSD for FPV periscope
GPS and compass for surface/shallow position hold and waypoints, ideal for displays.
forward looking sonar for avoidance

three things i know:

1) vtail mix should work for xtail,
2) GPS does NOT work underwater. compass does.
3) not enough bandwidth for live video while submerged, will either need to be surfaced, or some sort of tether/buoy for video antenna.

the whole reason i moved to 900mhz instead of 2.4ghz is because i do not want to have anything tying me to the surface.

others may not care.

tsenecal wrote:three things i know:

1) vtail mix should work for xtail,
2) GPS does NOT work underwater.  compass does.
3) not enough bandwidth for live video while submerged, will either need to be surfaced, or some sort of tether/buoy for video antenna.

the whole reason i moved to 900mhz instead of 2.4ghz is because i do not want to have anything tying me to the surface.

others may not care.

Im not looking to build anything deep diving, I should be able to waterproof a small enough gps, camera and fpv antenna to fit on the top of the periscope so it can run at periscope depth. I have looked at lower frequencies for video, in the US you can use 900mhz video transmitters that should work to a reasonable depth but im limited to 5.8 and 2.4 for video here so I will need to stay at the surface. i have a scanning sonar but its too big for this sub.


some more research shows that GPS wont work at all under water so it would be for surface use only.

https://www.ardusimple.com/gps-cant-work-underwater-myth-or-reality/

I have used the 900mhz analog video transmitters/receivers that were available 10+ years ago, and even above water, they were not really worth it. they gave basic standard def (640x480) video, and half the time that was static... the antennas were very directional. basically had to keep the receiver antenna in line with (not pointed directly at, but perpendicular to) the boat at all times.

I was looking into 802.11AH halow equipment for video but i havent been able to find any sellers selling them on 868mhz just 915mhz. its just a network extender so would work with any ip camera or telemetry.

https://discuss.ardupilot.org/t/802-11ah-halow-iot-wifi-920mhz/92988

I have been working on getting Inav Sub compatible,  for basic use its appears very straight forward, set it as a plane then set all the outputs to servo so they all run at 50hz. set your outputs for stabilized pitch and stabilized yaw and enable angle mode to enable auto level.

I havent tested this yet, there might be issues running the motor in passthrough.


where im having problems is getting the r900 receiver telemetry to work with it, because its designed for a pixhawk its got smart port coming out uninverterted over a TX and RX pin similar to a frsky receiver with a signal inverter connected.
https://www.aliexpress.com/i/32973462837.html


most of the options to make it work are missing in the new versions, even when i went back to  2.3 and enabled the correct options i got nowhere.


long story short. it works fine with the latest iNAV was telemetry just plug and play, on my FC UART1 and SBUS IN are shared, so i unplugged the sbus connector and its working. basically all the options you used to have to set in older versions are now the default so are missing from the cli thats why i have having so many issues setting them. Of course none of this is documented anywhere all search results were for older version of the firmware.

Just go to the ports page and set the port to Smartport telemetry and connect the tx rx wires.








I am thinking about using the gimbal pitch output for the rear planes to keep the sub level. they should try and level the sub without pitch input.

I have made a test program to convert an analogue pressure sensor into a i2c SRF10 sonar that inav can work with, if it works Im thinking about also connecting a sonar to the arduino and being able to switch  between an sonar depth or pressure depth.

Code:

#include <Wire.h>

#define I2C_SLAVE_ADDR  0x70  //Standard MaxsonarI2CXL address
int sensorPin = A0;
int sensorValue = 0;  

int MAXdepth = 200;//depth in cm

int distances = 0;
int distance = 0;
byte received;

const int numReadings = 10;

int readings[numReadings];      // the readings from the analog input
int readIndex = 0;              // the index of the current reading
int total = 0;                  // the running total
int average = 0;                // the average


void readsensor(){    
  
    sensorValue = analogRead(sensorPin);
    distances = map(sensorValue, 1, 1024, MAXdepth, 0);
        

       // Smoothing
{
       // subtract the last reading:      
        total = total - readings[readIndex];
        
       // read from the sensor:    
         readings[readIndex] = distances ;
        
       // add the reading to the total:
         total = total + readings[readIndex];
        
       // advance to the next position in the array:
        readIndex = readIndex + 1;
        
       // if we're at the end of the array...
    if (readIndex >= numReadings)
    // ...wrap around to the beginning:
    {readIndex = 0;
    }
 
      // calculate the average:
      average = total / numReadings;

}
 
      //ratio for speed of sound in air vs water 4.314 for water, 1.0 for use in air
      
       distance = average * 1.0;
      
       }




/*
 The default I2C-Address of the sensor is 0x70.
 To perform a range measurement you must send the "Take Range Reading” command byte 0x5
 */
void receiveEvent(int howMany) {
  while (Wire.available()) { // loop through all but the last
        {        
      received = Wire.read();
      if (received == 0x51)
      {
      }
    }
  }
}

void requestEvent()
{  
Wire.write (highByte(distance));
Wire.write (lowByte(distance));
}





void setup() {
 Serial.begin(9600);
Serial.print("startup");
 Wire.begin(I2C_SLAVE_ADDR);
 Wire.onReceive(receiveEvent); // register event
 Wire.onRequest(requestEvent);
}
void loop() {
  readsensor();

    
     Serial.print(" ");
     Serial.print(distances);
     Serial.println();
}

Flight controller and a power distribution board installed. the gps is only there temporarily, i plan on moving it to the mast at somepoint.

Inav lua is nice,

channel four for "RC Throttle"? why did you pick that? and how much did you have to change/fix to actually get that to work?

so many of the values INAV spit out as defaults for throttle were just plain wrong, and my ESC wouldn't even arm.

is it even necessary that we have an entity that INAV sees as a throttle?  could we simply have channel 3 (or whatever channel we have connected to the throttle stick on the transmitter) from the receiver passed out to a servo pin on the FC?

what advantages do we get by designating a throttle in INAV?


I am assuming that we are all using "wing" style FCs for the submarines...