Sure if you want to run the PX4 stack and loose 90% of the features of ArduPilot. But a lot of the work we are doing in ArduPilot is taking advantage of the dramatic increase in processing power that ChibiOS gives us (because NuttX is so processor hungry and inefficient compared to ChibiOS). There is a lot of work that Tridge has been doing that simply would not be practical for us to attempt using NuttX.
It is also silly to say that because the PX4 stack is still using NuttX that you can just use the future versions of ArduPilot and expect them to work bug free, even a cut down versions. The people making these decisions have a far deeper understanding of these issues than you do (or me for that matter).
It is grossly irresponsible to be advising people that they should be using NuttX moving forward. You are literally endangering peopleās lives.
Tridge,
I have V3 and a developer version of V5. So I have seen the servo movement in power up with my V5 in the past. I think you can only load chibios versions on that board. I have not flown my V3 much but I will make a point to check this over the weekend.
@tridge and @ChrisOlson. I performed several boot ups with both the NuttX version of 3.6.12 and the chibios version on 4.0.0 on a CUAV Pixhack V3. I donāt have a V3X. In all cases, I found the tail rotor servo would move very slightly at initial power up and then after the board booted, it would return to the original position.
For chibios, I never had any of the swashplate servos move. In two out of maybe 8 power ups on NuttX, I had the left forward servo move nearly max throw.
I logged data disarmed but not sure what it will show. I will look at it later tonight.
I got the exact opposite of that. On NuttX the servos just go to center on boot.
The only thing I can think of to do is put one of those so-called āsafety buttonsā on it so the IOMCU doesnāt start before the FMU starts. But I hate to use those on helicopters, as they are a point of failure, and they are not true safety-rated switches.
On that, Iām not sure. I donāt think it makes any difference if itās on there if itās disabled. But not sure on that. I donāt even have one installed on any of our heliās.
In the above test I have everything related to BRD_OPTIONS, BRD_SAFETYOPTION, etc, set to zero. That remains a quite confusing system that I personally wish wouldāve never even been put on the hardware.
My proposed solution was to put one of those on there, set it to be enabled at start, but set BRD_SAFETYOPTION to 1 so itās only available for enabling the IOMCU, but not disabling it. The logic to all that is so convoluted that I donāt trust it on $10,000 helicopters.
Here is a NuttX boot demo, reverted back to ArduHeli 3.6.7. I donāt have logging turned on in this helicopter, but I donāt think logging is going to capture whatās going on anyway because the FMU hasnāt even started yet when the problem happens on ChibiOS.
Editing this post because I think the best solution is below - do not power up helicopters all at once, both flight control and servos. The system needs time to start up before the servos are powered up.
I saw your previous comments on this too and meant to ask: Why would you not want this mixing in the IOMCU so that radio setup isnāt required and the pilot can simply react? I feel like creating a mixer in the radio means it would have to be switched on in the emergency, and, in an emergency the average pilot may not have the free cycles to remember to switch this switch? Having the mix in the IOMCU is how flying wings can be flown in Plane, I donāt see why one wouldnāt want to follow this model in TradHeliā¦
There is too many different swashplate types for helicopters to make it practical to write a IOMCU mixer for them.
And also keep in mind that even flying in Auto, if the engine quits the pilot has to have the training to realize it canāt be autorotated unless it is in acro (preferred) or stabilize. So it still requires pilot intervention.
Josh, another thing about a power out, is that the pilot is usually aware if it instantly. Especially if FPV with audio feed being used at long range. For me, the audio feed from the FPV is a better early warning than real-time headspeed warning. In Auto the altitude controller actually buys you a couple seconds. It might use up some headspeed, but if you are running 450 fps or above in the first place you can usually afford to lose 10% up front if you have suffficient (>20kts) airspeed at entry. You can easily recover from that 10% loss.
If the helicopter is in hover and that happens, itās all over in a straight down auto with a heavily loaded UAV. You need airspeed. The more the better up to about 40kts. Airspeed improves the glide ratio dramatically and airspeed can always be converted to headspeed. Vertical speed canāt be converted to anything but a crash with a heavy UAV. The whole idea is to convert airspeed to headspeed to reduce vertical speed to zero at touchdown.
And there is plenty of time to do that even from 75 feet altitude. As long as the pilot doesnāt just stand there and gawk in disbelief that it quit.
Josh, as an example, hereās a possible solution. Your Taranis supports logic switches.
When you are flying in Auto, for instance, you never lower the collective all the way. It stays in center position (at least mine does). What is your first reaction to a power out in flight? Lower the collective to bottom. Right?
So set up a logic switch in the Taranis where the logic switch evaluates:
Arming switch is on
Flight mode switch is in Auto
Collective at bottom stop
All true, have the logic switch automatically flip to acro flight mode and flip in your emergency mixer. You are now in automatically in controlled autorotation with one simple pilot reaction. You have plenty of time to flip your emergency mode switch to ālockā it in that configuration for the flare prior to landing. If it quit due to some other reason than the FMU going belly up and the control inputs arenāt right, simply disarm it (assuming you use an arming switch, which all helicopter pilots should be using in the first place) to disable the logic switch.
And then go out and practice until youāre proficient with this particular emergency procedure. So in an actual emergency you know what to do.
@bnsgeyer@tridge I found it is more than just the basic 1-4 servos. It also moves the throttle signal at boot. It causes the FADEC to initialize on my T9 at boot.
I get tick, tick, tick, tick, tick from the igniter and then it aborts the start sequence because the throttle signal goes to zero after that. Even if the throttle went to ground idle and it spooled up the gas generator it still couldnāt start because the FCU (Fuel Control Unit) does not go thru the controller and is hooked direct to the RC receiver. That has to be enabled before the engine will start. But itās still not right, NuttX does not do that.
You canāt actually āseeā the result of the throttle signal on a turbine with a FADEC. I will try it with a piston machine where I can watch the throttle servo to see what it does on boot.
On power up the IOMCU always is in āsafety onā state. The effect of the BRD_SAFETYENABLE=0 parameter is identical to the user pressing the safety button to disable safety as soon as the FMU boots. The IOMCU has no parameter storage, so has to assume āsafety onā when it powers on.
Note that debugging these types of issues requires the use of a logic analyser. I would recommend the Saleae pro which is available at a discount to ArduPilot dev team members (PM me for details).
I figured that. I may have come up with a solution. Two safety-rated master switches. One for the flight control to boot it and let it warm up. The second to turn on servo power after the flight control system is running.
I tested that and it works. If the system is running when the servo power is turned on, no servos exceed their limits.
Edit: It was probably a bad design to turn on power to everything at once in the first place. With separate servo power switch it will allow us to do pre-flight and warm up the IMUās in the control without the power-hungry servos drawing on the battery before the engine is started and the generator comes online.