Flight controllers as sub levelers

after some more testing I found that to get all the motor control functioning I eventually had to set it up as a motor output. I think this is just due to the way the mixing is done, stabilised throttle output gave me strange readings when I disabled the motor output, it was like it disabled the concept of a motor its strange. I think to get it working with a single motor and not have it assign a set of pins to a second motor that is not used I will need to do a custom mix in the CLI, the sub is packed away at the moment and im working on my other boats I am going to revisit this very soon once some more parts arrive. I was more interested in getting the levelling working that I didn't really do any testing with the motor output. I think most of this is probably due to the stock plane mixing template.

you are right that just passing through the RC input for the throttle might be a better idea since we dont need to worry about any kind of throttle control by the flight controller as most people wont be using any kind of auto navigation.

im going to look into doing a custom mix that will add a dive channel, basically mix an extra input like a slider that will rotate the front and rear planes in the same direction so it can dive as well as use all 4 for levelling.

I can dig out my built FC and try updating it to 6.10 (currently its 5.10) and see if i can get it happy without a "throttle"

tsenecal wrote:

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

The main difference is the wing controllers have an extra regulator for the servos but you can use any inav compatible flight controller, you just need a bec for the servos.

hmm... i am using the wing controllers because they have actual servo pwm outputs (pins for standard servos). for 6 or more servos. the BEC i was using for the servos is from the ESC.

tsenecal wrote:hmm...  i am using the wing controllers because they have actual servo pwm outputs (pins for standard servos).  for 6 or more servos.  the BEC i was using for the servos is from the ESC.

its generally the older controllers that will still have servo pins. when you said wing fc, there are specific controllers for wings like the f405-wing from matek with the extra regulators, I thought thats what you were talking about.
https://www.speedybee.com/speedybee-f405-wing-app-fixed-wing-flight-controller/

I use a board without pins on one of my tugs, i just mount it on some breadboard and solder some jumper wires to rows of pins to make a servo breakout.

quote rather than edit lol

tsenecal wrote:hmm...  i am using the wing controllers because they have actual servo pwm outputs (pins for standard servos).  for 6 or more servos.  the BEC i was using for the servos is from the ESC.

another option if your flight controller has limited output or no servo pins is to use a PCA9685 i2c servo driver, it gives you 16 outputs from i2c, I am not sure if all 16 are currently supported it might only be the first 8 channels.

https://quadmeup.com/using-pca9685-with-inav/


done some more checking, they removed it in v5.0 and recommend sbus out with a sbus pwm decoder. im not a fan of that as it uses up a uart port.

I finally figured out the mixing for inav, this video shows the best way of doing it. you dont use the motor mixer as we arent using any special protocols we can just set it all as servo then use the servo mixer for everything. im currently rebuilding one of my tugs with a f7 INAV board to replace the ancient f3 controller it has so have been trying to get to the bottom of the inav mixing. now that i have a better idea of it im going to try again with the sub once I have finished this boat.

EDIT: had a go with the sub and its all moving like its supposed to.

https://www.youtube.com/watch?v=9194OzsHOFc


there has been some talk over at the ardupilot forums about using it for conventional RC submarines including autonomous navigation using dead reckoning and water speed encoders. I am fitting an aircraft pitot sensor to the bottom of my tug to test how effective it is as a water speed sensor.  There are lua scripts for automatically switching ekf lanes to encoders or optical flow when GPS accuracy is lost. the idea isthat the sub will get a fix whenever it at periscope depth then the encoders will take over when it submerges.
https://discuss.ardupilot.org/t/conventional-submarines-ardurover/59312

hi, be aware of accuracy issues though. A few thoughts based on industry experience with some guidance systems, if you had not already though of them):
the main issue is accuracy of measuring low values (ie. water speed vs. air speed). in general it is easier to get good accuracy when the signal you are measuring is medium/high. If speed measurment is not accurate then any dead reckoning will suffer, think of it in terms of how long the dead reckoning period is vs speed vs accuracy and see how far out you will be at the end of that period (before getting a good GPS fix again).
The other source of inaccuracy is the rate of turn, in an aircraft the rate of turn is quite low, so there will be a number of positiion estimates during the turn, but in a water craft the trun rate can be much higher, and with a greater potential for drifting round the corner (side slip) so the simple integration of speed & direction no longer give the accurate change in position.
Going back to sensors, 'good' industrial flow rate (speed) senors use ultrasonic dopler, but not sure if you could get a cheap/small sensor, so a pitot/pressure is probably the best, though calibration could be 'interesting'!
Another alternative is a small vane/paddle sticking out of the hull into the (smooth) water flow with a strain guage measuring the force on the paddle/vane. Probably not linear force vs speed.

SimonH wrote:hi, be aware of accuracy issues though. A few thoughts based on industry experience with some guidance systems, if you had not already though of them):
the main issue is accuracy of measuring low values (ie. water speed vs. air speed). in general it is easier to get good accuracy when the signal you are measuring is medium/high. If speed measurment is not accurate then any dead reckoning will suffer, think of it in terms of how long the dead reckoning period is vs speed vs accuracy and see how far out you will be at the end of that period (before getting a good GPS fix again).
The other source of inaccuracy is the rate of turn, in an aircraft the rate of turn is quite low, so there will be a number of positiion estimates during the turn, but in a water craft the trun rate can be much higher, and with a greater potential for drifting round the corner (side slip) so the simple integration of speed & direction no longer give the accurate change in position.
Going back to sensors, 'good' industrial flow rate (speed) senors use ultrasonic dopler, but not sure if you could get a cheap/small sensor, so a pitot/pressure is probably the best, though calibration could be 'interesting'!
Another alternative is a small vane/paddle sticking out of the hull into the (smooth) water flow with a strain guage measuring the force on the paddle/vane. Probably not linear force vs speed.

I agree its going to be interesting trying to get accuracy. my expectations are for it to just be able to go short distances between waypoints 30m at most, then surface to get gps fix and reset its position. I have been looking at the ultrasonic sensors for water speed, they are similar to the ultrasonic anemometers but i havent found one small enough to be usable on something RC.

Another option was to try and map the vehicle speed to shaft RPM, since a sub is underwater and its drag is relatively stable it should be quite accurate if you can map the RPM/speed curve accurately.

I have a PX4Flow optical flow camera ordered for testing under my tugboat, the plan is to mount it under the boat and as long as it can see the bottom it can accurately measure its speed as long as you use a sonar to tell it how far away the bottom is. if it goes well I will test it on a sub.

I am also curious how much "current" (water flow) will impact dead reckoning. not a big deal in a swimming pool, but in a pond?

also... who runs their sub for only 30m underwater? the challenge is to dive at the start, and keep it there for the entire run...

tsenecal wrote:I am also curious how much "current" (water flow) will impact dead reckoning.  not a big deal in a swimming pool, but in a pond?

also... who runs their sub for only 30m underwater?  the challenge is to dive at the start, and keep it there for the entire run...

30m is just what im looking for, I was only ever planning on running my sub at periscope depth anyway, I just need it to keep a rough idea of where it is until it can pop the gps mast back above the surface.

This is my current Inav setup. im using stabilised yaw for rudder, stabilised pitch for the front and rear dive planes to keep the sub level, then channel 7 is my dynamic diving channel, so when i pitch forward it will push the nose down and lift the stern up, but with the diving channel it will try and push bow and stern down at the same time while keeping the sub level.



Basically we dont need the motor mixer at all, the only reason there are 2 mixers are for timers, so you use the motor mixer for things like Dshot protocal and the servo mixer for servos, but since we arent running any high speed motor protocals we just set everything to servo.


one thing i noticed was that the flight controller barometer still registers pressure changes in the hull so by enabling the vario on the handset you can have it beep out if it changing.

I have managed to get an arduino sonar emulator working with inav so i can now interface the depth sounder with the flight control system to keep a distance from the bottom or connect a pressure sensor to hold depth.

I want to try and emulate a barometer next, then I can interface any arduino compatible pressure sensor for depth hold using pressure. another probably simpler option would be to interface a compatible barometer and seal it so it can detect external pressure. the problem is it wont be accurate as its in water instead of air. so it should hold depth ok but the numbers it shows wont be correct due to the different density.

I have ordered an external BMP280 barometric sensor, from what I have found it should work up to 15psi, that should be more than enough. The challenge is to now find a way of sealing it to a tube so it can measure the external water pressure.

I was wondering why i couldnt get it to auto level, i forgot that its set to boat and it needs to be a plane for auto levelling or altitude functions to work.

I have been looking into inav and its programming, there is a part of inav that has a logical switch system similar to opentx that lets you do a lot of custom behaviour.
I have been testing it with my one of my little tugboats to make an anti-collision system but I think it can be adapted to control the auto levelling and depth control systems. The idea is that I can connect my trim ballast tank to the pitch control to level the sub but using the logical switches I can select when the pump runs so its not moving water around whenever I use the planes to change the boat pitch.

The other application is for depth control, when running Inav as a plane, "altitude" is controlled by the pitch of the aircraft so the plan is to selectively connect the ballast tank to the front dive planes, so the flight controller can do depth control using pitch control.

got the pressure sensor working with the RP-2040 instead of the 328 but its still having issues, I think its using the i2c timer to drive the sensor. so its causing problems with the i2c interface. the rp2040 has dual i2c buses so my plan is to try and get i2c connected via bus 2 so hopefully they don't conflict.

I have been approaching the problem from another angle, I'm trying to seal up a barometric pressure sensor to a tube that I can use to measure external water pressure, that way inav can use it for depth. But unfortunately I cant seem to get an external barometer working with the flight controller even after removing the onboard one, the VL53l1x lidar I'm using for testing works fine so it's not wiring, I suspect it's the little bmp280 modules im using are probably fake or something. so I have ordered:

BMP280 module
bmp180 module
ms5611 module
bmp388l module


I should be able to get at least one of them working, I think I can make a custom sensor on opentx that will display the correct depth by applying a ratio to the raw depth to compensate for the fluid density difference between air and water.





As a bonus this will work with the Variometer output on opentx, so you can control your depth using the sound from the radio, beeping is ascending solid tone is descending and also the voice alerts so it can read out the depth to you.

I have made some progress on the HX710B digital pressure sensor, by changing the rp-2040 over to the second i2c bus and removing the serial print commands i have got it to reliably read as a sonar in Inav. I have set it up so that it maps the pressure to the fake rangefinder readings.

More research and I have found out that the flight controllers dont actually have drivers for all the barometers you can select, turns out i have been trying to use unsupported barometers....but i have some supported ones on the way so hopefully have something working next week.

Code:

#if defined(OMNIBUSF4PRO) || defined(OMNIBUSF4V3)
#define USE_BARO_BMP280
#define BMP280_SPI_BUS BUS_SPI3
#define BMP280_CS_PIN PB3 // v1
// Support external barometers
#define BARO_I2C_BUS I2C_EXT_BUS
#define USE_BARO_BMP085
#define USE_BARO_MS5611
#else
#define BARO_I2C_BUS I2C_EXT_BUS
#define USE_BARO_BMP085
#define USE_BARO_BMP280
#define USE_BARO_MS5611

this is a very good design

https://swharden.com/blog/2017-04-29-precision-pressure-meter-project/

GOOD NEWS!


I have the MS5611 barometer working off the external i2c bus, next step is to encapsulate it so I can seal it to the outside of the sub.

Some marine JB weld and a glue syringe. its probably going to done again once im sure it works to fill as much of the space around the sensor with filling to minimise how much water gets pushed in.

Arent you afraid of a wet Atmosphere which leads to corrosion or shorts your circuits?

17b wrote:Arent you afraid of a wet Atmosphere which leads to corrosion or shorts your circuits?

Not really, but now you mention it il conformal coat the board just to be sure. This isnt a long term solution for something that would be left in the water but realistically out subs are in the water for an hour at most before they are left to dry out. As long as water doesnt push it's way in and have direct contact with the sensor then it should be ok.

I dont think that water needs to get inside. With that closed housing humidity brought in via the hose cant escape. Sealing the whole board with an appropriate coating except the two holes should do the trick