[WIP] Implement MAIN and AUX pwm output on MindPX

[iZhangHui]

This PR is a rough experimental prototype for implement both main and aux pwm output on px4 fmu side for autopilot without IO SOC.

The goal here is to reuse the PX4 airframe and mix files for plane, VOTL and some multicopter,
and make px4fmu v4 family be as powerful as Pixhawk.

TODO:

• Split px4fmu.cpp into pwm, safety_stick, rc etc device class, then it can be easily reuse and maintain pwm function codes.

• Rewrite drv_io_time and drv_pwm_servo to support 2 groups of timers, one is for main pwm and the other for aux pwm. Currently, I have no idea how to do this.

@LorenzMeier @bkueng @davids5 @dagar
Any suggestions and opinions are welcome.

#7140

[rolandash]

This is a different arch than FMU-V2/V3 or FMU-V4, as it implements full AUX + Main support in a single FMU.

Not a perfect implementation yet, but a realistic one in limited time frame that can make it working.
It can be interesting because it can enable existing FMU-V4 based hardware having complete AUX function, and maybe more meaningful for full VTOL support.

Specially, in MindPX hardware, this PR can enable up to 8 AUX outputs. This is even more than original Pixhawk (6 AUX), allowing more comprehensive VTOL config and more fine control. You are welcome to test it out.
Besides, Is there any other pixhawk derived hardware support this number of AUX? Let me know if any.

To distinguish, perhaps can give it a different arch name, like FMU-V4S or FMU-V4EXTREM, something like that?

[mzahana]

I did cold test (no flying), and I am able to set RC channel from QGC to passthrough to AUX1/2, to control gimbal from RC. I have not tested this in flight to confirm everything is working fine., but will do this soon.

[mzahana]

Is there any update on this. Is it working on latest stable version ?

[TSC21]

@iZhangHui what's the status of this?

[iZhangHui]

@mzahana We have merged this PR to latest stable release v1.6.5 in Airmind github repository.
You can check out the source code and prebuild.

@TSC21
In order to achieve the goal of codes reuse and maintenance, it should refactor fmu.cpp,
it's difficult for me to do this work.

[TSC21]

Difficult in what aspects? I suppose this is merged to the stable release already. So what's missing?

[iZhangHui]

@TSC21 We only merged this PR to stable release in AirMind git repository.

The src/drivers/px4pwm/px4pwm.cpp codes are mostly copied from src/drivers/px4fmu/px4fmu.cpp, and we cut off all unnecessary function, only keep pwm relative function. From perspective of codes reuse and maintenance, it's a bad practice.

Maybe this is also the reason why this PR is not accepted.

[TSC21]

The src/drivers/px4pwm/px4pwm.cpp codes are mostly copied from src/drivers/px4fmu/px4fmu.cpp, and we cut off all unnecessary function, only keep pwm relative function. From perspective of codes reuse and maintenance, it's a bad practice.

@iZhangHui so there's no way you can make this compatible with the upstream master? Cause that way for developers like me (which actually have a MindPX), we will never be able to have a proper sync between the devopment branch and the the stable of MindPX, having always to be stuck to it. Would be good if you could take some effort for having this in a clean way merged into upstream.

[dagar]

I need to review what you've done higher level, but I'd like to see the main fmu module become much simpler. It was a catch all for many unrelated pieces.

[rolandash]

Thanks @dagar that will be more than great.

From functional point of view pilots can now fully utilize all MindPX's 8 AUXs by using current Airmind's stable release. However @iZhangHui has his standing ground in terms of future evolution. As this part of code affects and is affected by many other parts of PX4 components, so seems a better way is to take this idea into consideration under the framework of new PX4 common architecture, including V5, needs to be planned and coordinated with the dev activities of other parts.

In my view it is actually a bigger issue than just a MindPX-specific issue, as it can benefit all single FMU flight controllers, including the emerging V5 hardware.

BTW, the new MindRacer hardware revision will have total 12 PWM outputs than previous 6, which is a benefit to many VTOL builders.

[davids5]

I think to mainline this it would require more modularity and not code duplication.

I think there are 2 aspects that need to be improved in the mainline as it is now:

1. Adding channels: This does not require new code. Just the data that defines the new io_timers.
   Where value could be added here is a PR that uses a by references (pointer) interface, to the timer/channel groups. Passing a pointer and apposed to the way it is now.

2. Mapping the new channels to look like an IO. I think we need to look at the complete PWM subsystem and how to abstract it better given the physical limitations imposed by groups (channels on the same timer). Then mapping the air frames to that abstraction.

[dagar]

Splitting the existing fmu module into a seperate task for pwm output (and GPIO) handling and separate work queue module for RC input would be a good start. Then make fmu a little more generic so you can start multiple instances (MAIN & AUX) corresponding to different outputs.

[iZhangHui]

Thanks for your good suggestion. @davids5 @dagar

@davids5
For the 1st aspect, when running multiple instances in differnent tasks,
I think it should add a task lock to protect references (pointer) interface. Is it right?

For the 2nd aspect, will it lead to modify the current existed air frames configs?

@dagar
I agree with you, make fmu generic and abstract will be good start.
But, to be honest, fmu.cpp is large and complex for me, I don't have enough confidence to
complete this task by myself.

[dagar]

@iZhangHui it needs work, but here's a branch where I split the px4fmu into fmu + RC input + safety button (+ i2c + spi). https://github.com/dagar/Firmware/tree/pr-fmu_split

With some testing and review we can get that in master, then strip it down even more. Then making it possible to run multiple instances shouldn't be as daunting.

[mzahana]

@iZhangHui As you may know that PX4 1.7 is released, can AUX work on MindPX using 1.7 version?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[Pedro-Roque]

@iZhangHui is this still ongoing or should we close it for the time being?

[iZhangHui]

Close it as this work is terminated.