Custom Functions

[ChristosKeleshis]

Hello, I am writing on behalf of the Cyprus Institute (Research Center) I will really appreciate if i get your feedback and support on the following 2 issues:

1. I was wondering if it is possible to control a PWM output on a MATEKSYS F405WING according to a sensor input value (i.e barometer)
2. We are planning to perform high altitude flights with a UAV attached to a meteorological balloon. We already have the circuitry/mechanism to manually or automatically release the UAV from the balloon. We would like to somehow detect that moment and activate the RTH mode. The one way to do it is to use the available sensors on the MATEKSYS and activate the iNAV autolaunch. The other way we thought is to read a signal coming from the external arduino board that we use as the release mechanism control and somehow read the signal at the MATEKSYS side and trigger the RTH through INAV.

Thank you,

Christos

[digitalentity]

Neither (1) or (2) is possible with stock INAV.

There is a possibility to interface your Arduino board with INAV via MSP protocol. Depends on your requirements it might be enough.

Features you need don't seem to be useful for majority of the community so they unlikely will be implemented in stock INAV. However, myself or other developers might be able to implement your requirements for a fair compensation.

[ChristosKeleshis]

Thanks for your response. This is part of a EU research project. It may be possible to provide some compensation but I believe that the most important for you will be that the iNAV team will be acknowledged in all of our publications and presentations regarding this project. I suggest that before proceeding to the development we should discuss the requirements and check if this is realistic to develop with the current setup (iNAV board + digital output from arduino)

[digitalentity]

@ChristosKeleshis this is a community project, where developers devote their time to develop features they (and/or the majority of the community) see usable. If you provide the scope of your project and your requirements you may get some of us interested.

[ChristosKeleshis]

Hello, This is an EU funded project which is dealing with high altitude atmospheric and meteorological UAV measurements with prototype instruments that should be recovered. We do have a good experience with UAV flights up to 4 Km agl but through the new project we would like to reach higher altitudes (lower stratosphere). The idea is the following. A small low cost UAV that has been already developed has been equipped with MATEKSYS F405WING and INAV. We have already performed many flights and we got the iNAV experience. The next step is to attach this UAV on a meteorological balloon and have it climb with the balloon up to a predetermined altitude. We do have a standalone system made of a tiny arduino board which controls a heat wire which releases the UAV from the balloon. The release is happening automatically through a predetermined altitude read by a barometer attached to arduino. At the same time the same release mechanism can be triggered by the RC Rx through the RC Tx. All this has been tested as well. Now, the question is how we make the iNAV UAV being armed but without running the motor while attached on the balloon and upon release to engage an RTH command automatically in order for the motor to start running and have the UAV glide back home. We do have available inputs/outputs at the Arduino if we want to use them. The release mechanism is triggered by a Digital Out from the arduino so i believe that if we manage to read this digital signal by iNAV and trigger the RTH according to that then it should be simple. Please let me know if you have any questions Thanks for your interest

[Tygrys-1]

Now, the question is how we make the iNAV UAV being armed but without running the motor while attached on the balloon and upon release to engage an RTH command automatically in order for the motor to start running and have the UAV glide back home.

AFAIK you can use the "motor stop" parameter to not run the motor when armed.

You may also consider something like the pwm to ppm encoder to insert the external channel to the flight controler. You will have to use the PWM output capable receiver with the encoder to mix the RC signal with the Arduino PWM and to feed this to the FC. Or maybe you can teach the Arduino to simulate the signal with given channel data with RTF state to the FC and after that or when back in RC range to switch the RC output signal directly to the FC instead of the simulated one. Can be done by simple multiplexer driven by Arduino.

[atomiclama]

Have a look at how these did it, not iNav I know but might help. https://blog.hackster.io/this-raspberry-pi-glider-was-dropped-from-a-high-altitude-balloon-and-successfully-reached-a-971e26be14f7

[Tygrys-1]

It is easier on the Pixhawk, as it has PWM inputs and can be easily driven from the external source like the Arduino or Raspberry Pi.

I'm wrong with the above. It seems easy to do without any external device, or with a simple multiplexer only. Use the RC serial receiver to drive the Arduino serial input. Set the correct UART parameters and: 1) Record the "manual mode, surfaces neutral, motor zero" RC signal. 2) Record the "autolevel mode, surfaces neutral, motor zero" RC signal. 3) Record the "RTH mode" RC signal. Play these signals from the Arduino's TX to the FC through the multiplexer.

From the start of the baloon play the (1) signal from Arduino to FC serial input to have the UAV do nothing and don't waste the battery. On start of the release play the (2) signal from Arduino to FC serial input to have the UAV stabilized in the air on release. When detected descending on your baro play the (3) signal from the Arduino to FC to initiate RTH. When detected valid RC signal on Arduino Rx you may (conditionally) redirect it to the FC (Rx to Tx on Arduino) or switch the multiplexer to disconnect the Arduino from the FC and connect the receiver directly to the FC serial input.

[senorblasto]

Instead of using Return to Home, why not have the UAV fly a waypoint mission to where ever you want it to land?

[ChristosKeleshis]

Hello, Our balloon UAV project is not that simple. We are using a custom made controller and a barometer to perform the release. For this thread i will refer to this custom made controller as RMC (Release Mechanism Controller). According to the requirements of the project we have to accommodate the following cases:

1. Automatic release from the balloon upon reaching the target altitude by the RMC. Just after the release RMC is outputting an electronic pulse to feed to the INAV board for triggering RTH. In the case of losing communication with the system while climbing with the balloon the FS of the INAV is disabled as we do not want the UAV to release at that moment
2. Manual release from the balloon from the Tx before reaching target altitude. The RMC reads that signal from the Rx, releases the UAV and then exactly like case 1 outputs an electronic pulse to feed to the INAV board for triggering RTH.

RMC is developed and tested succesfully. The only thing that is not implemented yet is to use the pulse coming out of the RMC at iNAV side to trigger RTH. We have managed to read that pulse at the ADC which is connected to the RSSI input of iNAV. This pulse is not a real RSSI pulse. It only takes 2 values which correspond to RTH and non-RTH and we have managed to read these values in RSSI. At iNAV modes tab the RTH can only be triggered using one of the available Channels. Instead of using the Channels we would like to use what comes in the RSSI port. Is this possible to do? If not, is it possible to map RSSI to any one of the available Channels? For example Ch18 (range: 1-2ms) = RSSI (range: 0-100)

Any help on this final implementation will be appreciated as it solves all the problems and creates a robust system. Please note that we are willing to share with the community the software and hardware design to make the RMC.

[Tygrys-1]

You fixed yourself on that RSSI idea. Instead of playing with the RSSI just send the simulated "radio like" signal to the inav RC input. You will set whatever mode or function you want, just like from the normal radio transmitter. You haven't said what RC protocol you do use, but if it is the serial one you should have no problem "playing" the previously recorded one to the iNav FC.

[ChristosKeleshis]

We have an SBUS from Rx to iNAV. The simulated "radio like" signal comes from the board that controls the release so it is not possible to feed it to iNAV. We can feed it if we use a PWM to SBUS converted but we prefer to use one less component if iNAV can be programmed to read an analog pulse. Finally, i should mention that we need to use this our Release Mechanism board as it includes code to decide on release according to several scenarios.

[Tygrys-1]

If this RMC board has the serial output it is definitly possible to connect it to the iNAV RC input. As I understand, the RC signal from the receiver is already connected to RMC board for remote release? If so, you may forward the serial signal to the FC from this board - or use a simple multiplexer chip to decide if the RC signal to the FC is taken from the receiver or RMC. That way RMC may emulate modes and switches to the iNAV FC for whatever combination you want, or may forward/redirect there the radio signal from the receiver depending on conditions. You even do not need to decode the SBus signal, it is enough if you record needed "states" from the receiver on the ground (the complete radio frame information) and then play it to the iNav to achive whatever modes/switches/servos you want set. No more arming problems, unwanted motor spinning and so.

That way you will be totally independent on the iNav version, you will not need any code modification to iNav, you will be able to program any advanced function or mode in the future. For now iNav have no steering inputs other than the RC, analog VBAT, CURRENT and RSSI are not used to drive anything other than telemetry and OSD.

As I understand - the release of the plane will be outside the RC range, so no RC signal mixing on PWM will do good there - the iNav will throw the RC data as invalid. Emulating the valid SBUS frame with the RTH enabled on some channel will also solve this problem.

[junwoo091400]

Sounds simillar to a glidersonde project done at ETH Zurich :) Are you guys related to that previous project??? I researched about this topic about a year ago and would love to see it getting commercialized.

[ChristosKeleshis]

No, We are a different group. We are focused into high altitude air quality measurements

[ChristosKeleshis]

If this RMC board has the serial output it is definitly possible to connect it to the iNAV RC input. What do you mean by serial output? UART?

As I understand, the RC signal from the receiver is already connected to RMC board for remote release? Yes, correct If so, you may forward the serial signal to the FC from this board - or use a simple multiplexer chip to decide if the RC signal to the FC is taken from the receiver or RMC. That way RMC may emulate modes and switches to the iNAV FC for whatever combination you want, or may forward/redirect there the radio signal from the receiver depending on conditions. You even do not need to decode the SBus signal, it is enough if you record needed "states" from the receiver on the ground (the complete radio frame information) and then play it to the iNav to achive whatever modes/switches/servos you want set. No more arming problems, unwanted motor spinning and so. I am not sure how to achieve this.

That way you will be totally independent on the iNav version, you will not need any code modification to iNav, you will be able to program any advanced function or mode in the future. For now iNav have no steering inputs other than the RC, analog VBAT, CURRENT and RSSI are not used to drive anything other than telemetry and OSD.

As I understand - the release of the plane will be outside the RC range, so no RC signal mixing on PWM will do good there - the iNav will throw the RC data as invalid. Emulating the valid SBUS frame with the RTH enabled on some channel will also solve this problem.

To help you better understand our system design i am attaching a block diagram. With red you can see the area that we are facing the problem. All the rest is working properly. I am also showing the available outputs we can generate from our Release Mechanism Control.

[digitalentity]

This is how it should look like:

Your RMC should sit in the middle between RX and FC. RMC will process manual commands and control the FC

[digitalentity]

Unless your RMC is an el-cheapo Arduino with only one UART it should be easily doable.

[ChristosKeleshis]

Your suggested solution looks nice. We can attempt doing it on our controller. It has all the proper inputs outputs for this. The advantage is that no changes have to be performed on iNAV side. The disadvantage is that you are dependent on a second controller for the manual flying. We will balance the positives and negatives and decide.

Thank you

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[wx4cb]

silly question, but couldn't you just have the arduino appear to the receiver as a smartport sensor? bypassing the whole FC as a result? (assuming you're running frsky). then you can send whatever telemetry you want to the transmitter. https://www.ordinoscope.net/static/frsky-arduino/FrskySP/doc/html/index.html

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[stale[bot]]

Automatically closing as inactive.