Inav: Dynamic I/O Allocation

[raul-ortega]

It seems that in betaflight has been implemented a dynamic allocation of resources (pin functions) which could solve some problem for some users in some boards:

https://www.rcgroups.com/forums/showpost.php?p=36069013&postcount=686

An example: In the case of current sensor, I don't use it, and could use that pin for RSSI throuht ADC without the need of commenting/uncommenting define lines and compiling the source code.

Could be possible to implement it in iNav?

[digitalentity]

While Dynamic IO allocation adds flexibility of pin assignment, it also will add hard to track issues.

Betaflight gets away with this because they only use one platform - QUAD, don't use servos and things like that.

With INAV it will create unnecessary complexity and reduce user-friendliness to an average user (geeks excluded, no offence ment :smile:)

I am, however, not entirely against this feature, but its very immature and without proper UI it's going to be useless or even harmless to 90% of users.

[DzikuVx]

Possible? Yes. Easy port from BF? Rather not. BF ignores servos, INAV can not ignore servos and that creates a bunch of problems: not every motor/servo combination is possible. They can not share timers and so on

[hali9]

I think it is a great idea.
Solved by a lot of problems.
For example, I do not use RSSI, current and voltage.
I would like for it to have an extra servo. (https://github.com/iNavFlight/inav/issues/794)

I do not agree with that:
"With INAV it will create unnecessary complexity and reduce user-friendliness to an average user (geeks excluded, no offence ment :smile:)"
There is thing as a default value
It may be set by default as it is in target.h.

"and without proper UI" - just use CLI (like mmix, smix).
https://github.com/betaflight/betaflight/pull/1189

Not only do I wrote about it: https://github.com/iNavFlight/inav/issues/271
I understand the problem with timers, but I think that this functionality could to solve it.
For example: SPRACINGF3 target.c
TIM16, IO_TAG(PA6), TIM_Channel_1 PWM1
TIM17, IO_TAG(PA7), TIM_Channel_1 PWM2
TIM4, IO_TAG(PA11), TIM_Channel_1, PWM3
TIM4, IO_TAG(PA12), TIM_Channel_2, PWM4
TIM4, IO_TAG(PB8), TIM_Channel_3, PWM5
TIM4, IO_TAG(PB9), TIM_Channel_4, PWM6
TIM15, IO_TAG(PA2), TIM_Channel_1 PWM7
TIM15, IO_TAG(PA3), TIM_Channel_2 PWM8
Pwm_Mapping.c

if defined(SPRACINGF3)

        // remap PWM15+16 as servos
        if ((timerIndex == PWM15 || timerIndex == PWM16) && timerHardwarePtr->tim == TIM15)
            type = MAP_TO_SERVO_OUTPUT;

endif

If I have 4 serwo? Why remap PWM1 and PWM2 to serwo, and use TIM4 for motor?
In airplane may be use PWM1 for motor and oter for serwo or PWM1 and PWM2 for motor and other for serwo and ... itd.

You do not need to look in the code, change and compile.
Not doing so would require a procedure pwmiinit and a lot of terms for each target.

[oleost]

Would this also help cleaning up the channel forwarding / servo gimbal mess aswell? As discussed here #600

[digitalentity]

The thing is that different mixers will require different defaults for
mappings - we'll end up having a ton of different mappings (exactly as we
have now) plus an extra system (IO remapping) that will cause bugs (both in
the code and in the configuration). This feature will also consume flash
(which will force us to limit F1 targets even further).

In general motor+servo can work together on a shared timer only on same pwm
update frequency. BTW that's the reason we don't have servo support for
multicopters on some boards.

I'm not against the feature in general, but we need a clear implementation
that will
a) fit into flash on F1 targets
b) will be fool-proof - this implies that code must be able to prevent
hardware resource conflicts
c) will support motor/servo and multi/airplane mixers - apparently current
code in Betaflight doesn't

On Fri, Jan 27, 2017 at 8:02 PM, oleost [e-mail] wrote:

Would this also help cleaning up the channel forwarding / servo gimbal
mess aswell? As discussed here #600
https://github.com/iNavFlight/inav/issues/600

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/1145#issuecomment-275629769,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKi_m9i63WWeVS8ay6arwQuab-d5c8isks5rWcCmgaJpZM4LpPVe
.

[vinicentus]

I believe betaflight has servo support in the resource remapping

[stronnag]

Perhaps you could explain how it works, digital servo and multishot ESC. Countless hours of following obsolete wiki leaks results in reflashing iNav so I can get decent performance out of my tricopter as I can't find workable betaflight solution.

[digitalentity]

Try putting Betaflight on airplane and get servos to work.

There are great many possible scenarios of output assignments and only a handful of them will be
functional when servos are involved. The majority of possible remap configurations will lead to either non-functional setup or burned servos. To limit amount of bug reports like "servos not working" INAV is not implementing resource remapping.

Once again - to get resource remapping into INAV we need the solution that will satiafy all of the following:

• fit into flash on F1 targets
• will be fool-proof - this implies that code must be able to prevent hardware resource conflicts
• will support motor/servo and multi/airplane mixers

[isilcala]

Personally, I think it doesn't have to be specifically 'Dynamic I/O Allocation'. I believe mostly the original goal is enabling software serial on some boards for telemetry, especially Omnibus class. If implementing 'Dynamic I/O Allocation' is challenging in iNav, perhaps some other smart way can archive it as well? Or the worst case, a special build like the 'CC3D PPM1'? I understand a custom build is an option but if this is one of the most common needs and not everyone can do it in the right way, a special build can at least solve some real problems.

[cmanley]

If this will allow one to use boards with only 4 output channels (such as nano omnibus boards) for 4ch planes then this will be a great improvement. The current limitation of reserving the first 2 outputs for motors when only 1 motor output is used means that those boards fall short of 1 output channel.

[digitalentity]

There is a reason why we reserve two pins for motors and don't allow them for servos. Hardware timers on STM CPUs generally can't be shared between ESC and servo outputs (unless they run same PWM frequency). Same is true for softserial, ppm/pwm input, ledstrip etc. Because most boards are designed without airplanes in mind - we have to figure out timer configuration that works for as many setups as possible.

Giving users ability to freely remap timers will cause a flood of "bug" reports with either "burned servo" or "non working ESC" or simply "nothing works".

[wx4cb]

@digitalentity - @cmanley is correct, the issue I have right now is working on the BetaflightF4 board with shellixyz is that this only has 4 "motor" outputs.. Cannot use this board on anything other than a bank and yank, however, my aircraft has 1 motor and 3 servos (Y/E/A) this would mean that this board, although completely suitable for inav, is useless for anything other than bank and yank with respect to fixed wing aircraft because the mixer specifies 2 motors.

Thoughts?

[tootomthumb]

I don't have a clue about the relative difficulty of adding the feature but I would be very happy with it. I'm trying to run a Crius AIO Racer F3 board which is very similar to the SP Racing F3 EVO. I have almost everything working but have determined the Resource Motor mappings are incorrect and would love to remap them.

The obvious advantage to this sort of feature is that it potentially opens up INAV to many more FCs adding to its popularity and user base...

[digitalentity]

Implementing it in a way Betaflight does it is not user friendly - it doesn't prevent resource conflicts which are potentially harmful to hardware (most notably servos).

To get resource remapping into INAV we need the solution that will satiafy all of the following:

• will be fool-proof - this implies that code must be able to prevent hardware resource conflicts
• will support motor/servo and multi/airplane mixers

Also some things to think about - many boards are poorly designed. While this may be ok for a racequad which doesn't live long enough anyway, for a long range plane that stays in the air for hours hardware flaws are critical. Allowing resource remapping will open the door to a flood of junk hardware because many manufacturers will entirely stop thinking about keeping things compatible with existing (and verified) targets.

[wx4cb]

@digitalentity but with betaflight you can't assign the same pin to multiple resources. IE, you can't have motor 6 assigned to motor 6 AND assign it to motor 5 (for a crude example). as soon as you assign an already assigned pin to something else, it takes that pin away from what it was assigned before. This satisfies your two bullet points that you made. and believe me, i've goofed up a lot with remapping.I resource map in mine all the time. that's one reason why i'm not running inav right now. the board i have only has 4
"esc" outputs so i can't use the standard airplane mix because that says. "you must have 2 motors" and "you must have 2 elevator servos". therefore right now, I can't have a rudder. betaflight mapping has fixed that for me and it works fine on betaflight controlling my 4 channel plane, although i don't get the nice things like RTH etc, I do get the OSD which is my main thing :D

[tootomthumb]

@digitalentity I thought your point about opening the door to a flood of junk hardware is interesting but not really relevant to INAV. INAV cannot police the quality of the components people choose any more than the quality and skill of their build. What's more, manufacturers will always (if they are interested in INAV) choose to build towards a standard target or they risk reducing the popularity of their board. Expanding INAV's potential user base (it isnt a big target list) increases manufacturers' interest in building to INAV spec in the first place.

INAV should keep its list of targets because that is a great indication of what boards are supported out of the box and anyone who wants to implement INAV but buys a board outside of that list is already taking risks. I'm in this situation because I built my copter with a Betaflight board and then determined it was S**T for any GPS functions. Had I known that beforehand I would have bought one of INAV's target boards.

I realise Betaflight's implementation isn't the most user-friendly but IMHO keeping it to CLI commands means the user will have to be reasonably driven and interested in the system to attempt changes in the first place. So for the first stage of implementation, it's not bad. Obviously, in an effort to build the user base it would be far better to have it implemented in the INAV configurator but all things in good time!

Regardless of where you guys go with this, it's fantastic to see that we still have one distribution which hasn't gone down the hyper-twitchy-racer-route and isn't a Pixhawk/APM, so good luck to you!

[digitalentity]

I have a suggestion for resource remapping.

For a given target we have a set of pins with possible uses (multicopter motor/servo, airplane motor/servo etc). Currently all of those pins are mapped to motors/servos depending on aircraft type.

Suggested approach:

• Keep pin list with possible uses
• Add a motor/servo mapping table to map logical motor/servo to actual pin

The difference from Betaflight is that free mapping to any given pin is not allowed. We still have the timer list with possible pin uses but we will have the power to reorder and remap within this list.

Thoughs?

[matoy]

Hi

+1 for that feature request.

Inav is great but need lots of devices to be fully used: gps, compass, bluetooth module (to plan missions on the field without a computer). If you add to that eventually sbus, smartport telemetry and led strip... That makes a lot of UARTs.

For exemple on an omnibus pro FC:
Uart1 for sbus,
Uart6/3 for gps/compass (scl/sda and uart3 are same pins)
Soft serial ch5/6 for bluetooth module
Led strip port for led strip

That would be great for example to be able to reassign unused motor5 & 6 pins to new soft serial ports to get smartport telemetry and even smartaudio for configuring vtx.

[digitalentity]

Currently we are talking about merely rearranging motor/servo outpus for more flexible wiring. More resource remapping features might be interesting to have, but we'll need to carefully think how to add those without opening a door for new bug reports.

[wx4cb]

@digitalentity yes i totally agree. being able to remap motor outputs to pins is the first thing that we should look at 😀 but in all seriousness however, both those ideas are a great starting point.

i wasn't endorsing "free remapping" remapping any pin to anything for surwe can get you downt he road of hassles. but remapping motor/servo outputs around will also help because then you could theoretically (as boards are mainly designed around quads) have an unusual board rotation to allow for the servo pins on motors 3/4 for example have to be at the back to make the wiring look tidy.

Being able to just swap them over with 1/2 would open up the possibility that now you don't have to rotate the board or have messy wiring traversing the board.

That or the other possibility of just easily making custom mixes through resource assignment (like is the issue for the BF F4) would just make a whole bunch more boards that use existing targets (SPF3 Clones for example) open to being used.

[KnuckleUpFPV]

I wish inav had resource remapping. I have had to use betaflight on two planes from not being able to change pin assignements. They both fly just fine with betaflight. However the gps support and return to home is not the best. It works, but I dont trust it as well as I trust inav. If betaflight had full on gps support like inav, it would be perfect. I hope some day we are able to change our pins to suit our needs.

[ekitru]

I wish INAV supports this feature, in my case I can't use SoftSerial on Matek405 AIO to connect smart port and telemetry on S5 (or S6) as i can do on betaflight.

it is disappointing. Right now SS just turned off from code and nothing is written in release noted about it.

[vinicentus]

I would also like this feature. A temporary solution might be to make it easy for anyone to compile a custom board configuration. Currently don't have any good ideas on how. Some kind of tool would be great

[throttlenerd]

Yes guys resource remapping would be awesome! For example, I would love to forward two S.Bus AUX channels to LED and Motor_6 pins of my Matek F405. And yes I need softserial on Matek F405, but afaik it will be implemented in 1.9, right?

[zector555]

Has there been any movement on this? I tried BF with mapping on my omnibus F4, the servos and motors worked fine, and allowed me to use other pins for s-port telemetry software inversion (downside of F4 boards). If not, can requests be made for popular inav boards for pin changes?

[blackmennewstyle]

I was so exciting for using iNAV thinking that resource remapping was implemented until i tried after flashed my board Omnibus F4 Pro with iNAV 1.9 then all my dreams just collapsed into a super nova explosion after discovering that it just does not work.

I need to remap my channel 5 & 6 to softserial_tx in order to use smartaudio and telemetry but i can't :'(

[ekitru]

I had the same issue, you can fix mapping and build your own firmware snapshot.

[blackmennewstyle]

Hi :)

How can i fix my mapping and build my own firmware snapshot?

[ekitru]

I am not a inav developer, but I think you need to visit inav slack channel and ask there

[blackmennewstyle]

OK thank you!

Enjoy the rest of your week and happy flying!

[DzikuVx]

I allowed myself to use some of my time and explain how outputs on STM32 works, how they connect to timers and why INAV has no resource mapping aka dynamic IO allocation:
https://www.youtube.com/watch?v=v4R-pnO4srU

[jasc76]

wouldnt it be possible to allow just a small amount of remapping without messing with servo / motor outputs by limiting remapping to non servo/motor ports?
I wanted to add a current sensot to my airbot nano v6 and need to remap pad PA1 (RX4) as ADC Input because the nano has no Current input pad by default

[diiity]

Hello,

Just like ekitru, I am interested in this mapping, can you unblock it?
Thank you
diiity

[tysonfromcanada]

+1

would be nice to be able to split tx and rx pins across two different serial/softserial resources as flight controllers can be limited on pins but some are re-assignable in BF.

[umeloman]

Hi all! I think I have an idea how to remap some motors. Developers, please confirm (or not) my version.
I'm building a quadcopter on Matek F405-Wing, and I don't want to use S1 and S2 pads (is is far from others) and want to use pads S3, S4, S5, S6 for m1, m2, m3, m4. Taking Hexa X mix and now we have some mixer for all 6 motors:
m1 m2 m3 m4 m5 m6
Throttle (1) (1) (1) (1) (1) (1)
Pitch (-0.8) (0.8) (-0.8) (0.8) (0) (0)
Roll (0.5) (0.5) (-0.5) (-0.5) (1) (-1) etc. yaw

Now I have edited mixer for quad inside of hexa mixer: m1 m2 m3 n4 m5 m6
Throttle (1) (1) (1) (1) (1) (1)
Pitch (0) (0) (1) (-1) (1) (-1)
Roll (0) (0) (1) (1) (-1) (-1) etc. yaw
So I'm not using m1 m2 in mixer and I gave a functions of Quad's m1 m2 m3 m4 to m3, m4, m5, m6 outputs. How do you think?