Sunday, April 4, 2021

Programming Alternatives


The alternative to automatically changing from passthru mode to gyro-accelerometer mode during takeoff is to make the pilot do the change. This means to add the following 4 OpenTX mixer configurations, 
  1. Collective pitch suppression in passthru mode This is what prevents a takeoff at passthru mode This is not used in the automatic programming because the automatic swithcing happens at very small collective pitch
  2. Tail power proportional to throttle in passthru mode This is not used with automatic programming with multiple betaflight profiles. But this is used also with single betaflight profile.
  3. Fixed RPM for accelerometer-attitude mode This is not used in automatic programming because the same swith C position is used for both spool-up and acc-att mode, which means that as soon as throttle position is below 1/8 , rotor spools down.
  4. Arming guard This is also used with automatic programming
The problem with non-automatic programming is the point 3 configuration. Point 3 configuration allows accidental RPM jump when the pilot learns that the switch C needs to go up for the craft to takeoff, but he/she can flip the switch C before the spool up, resulting in tip-over. We may argue that the pilot may just as well accidentally pushes the throttle up so quickly that the craft also tips over. But the human brain is customed to analog control, meaning that it hard to form habit of flipping the switch C just before takeoff than to form the habit of pushing the throttle slowly. 

We may wonder if the accidental RPM jump can be prevented by checking if RPM is already full speed before accelerometer-attitude mode can enter, but the OpenTX logical switch has no such condition of changing switch position to middle. Instead, the condition can only be the middle position itself. Now, if middle position means to have accelerometer-attitude stabilization only after spool up, and at the same time collective pitch becomes curve-defined, this entire manual programming becomes tuning in the field because the throttle point at which the stabilization is engaged determines the amount of tail wag and rotor wobbling.  Is it desireable to have field tuning? Or have a optimized build for consistent operations? 

We may argue that we can program point 3 to have a curve from zero throttle to fixed RPM when switch C is flipped on. But then this is becoming an quasi automatic programming. Further more, if this quasi automatic programming does not allow acc-att mode in craft during the rise of throttle to prevent the capsizing problem, this quasi automatic programming becomes fully automatic. But, if this quasi programming allows acc-att mode, the capsizing problem of other helicopters becomes the problem of this craft, meaning that our helicopter has the same ubiquitous problems as others.

Re-examine Statements About Engaging Stabilization