I am constructing a VTOL plane powered by an EFI engine for pusher configuration under CAN bus control.
The engine is enabled by 5 volt DC TTL logics on AUX port1, and its start is also done by 5 volt DC TTL logics on AUX port2. The FC is CubeOrange running Arduplane 4.4.4.
The engine works well EXCEPT one serious problem. Parameters for the engine enable and start are:
RC9_OPTION=28 ; 1st replay for ‘engine enable’
RELAY_PIN=50 ; AUX1 port
SERVO9_FUNCTION=-1 ; GPIO output control by RC Ch 9 switch
RC10_OPTION=34 ; 2nd replay for ‘engine start’
RELAY2_PIN=51 ; AUX2 port
SERVO10_FUNCTION=-1 ; GPIO output control by RC Ch 10 switch
A voltage level of GPIO output from CubeOrange is 2.3 to 3.3 volts. My engine requires 5+/-0.25V for its 5 volt TTL circuits. So I use two boost-up boards. The key problem is CubeOrange outputs while its booting and makes unintended enabling and start of the EFI engine. After completion of its booting, the unintended GPIO output is disappeared and its voltage level becomes zero and the engine stops. Status with or without the boost-up board are same. The boost-up board doesn’t affect unintended GPIO output while booting.
This makes a dangerous or critical situtaion. As a solution, I installed a manual switch on its engine start circult and turned it on after completion of CubeOrange booting. However, this is not a true solution.
My questions are:
Are there any ArduPlane functions to disable unintended GPIO output while booting?
What is the exact meaning of a bitmask set of ‘Disable board arming GPIO output change’ of BRD_OPTIONS parameter?
This trouble can not be fixed by typical ICE parameters like ICE_PWM_STRT_ON, ICE_STARTCHN_MIN because the engine enable and start controls are done by TTL logic control, not PWM-based control. Also I found that the TTL logic ignores the safety switch state and accepts the above relay controls only. RC auxiliary switches on RC transmitter and relay buttons of ‘Servo/Relay’ tap of Mission Planner can control the relays.
As you are using a “booster” module to start the engine you also can use instead the “booster” a PWM controlled switch module which support 5V output. Than you can control the engine by an PWM channel which always only will work after the boot sequece of the FC.
I had used typical PWM-based electronic switches like Dr.Mad Trust RC switch on the market. However those switches are not suitable for my flight due to some reasons:
R1. Almost RC switches are designed for temporal operation for switching smoke generator and so on. They are not suitable for long endurance flight. I have done aging and reliability tests. As a result, their reliability is low so it can’t be used for long endurance engine control.
R2. My engine is industrial-class EFI engine valued higher than 30KUSD to 50KUSD. Even though PWM-based engine control is widely used for typical carburetor engine, that type of engine can’t comply with industrial requirements and is suitable for short endurance or hobby flights.
R3. Typical RC switches use conventional engine control instead of CAN bus based full digital engine control and engine data telemetry. CAN based engine requires digital relay logic to enable/disable engine instead of conventional assignment of RC ignition channel and starter channel.
Please refer to the following link for a reference.
This is a known issue with ChibiOS and its bootloader (the underlying layer between ArduPilot and the actual hardware). I use an RC relay to protect against such unexpected outcomes on my mower, but I understand your concerns about implementing the same.
If you need more reliability than such relays/switches provide, recommend a physical cutoff switch that disables power to the critical components you need to protect and/or keep safely inoperable. Boot the autopilot, then close the switch.
As an awkward alternative, power the autopilot with a USB battery bank to get it through the initial boot sequence, then connect main battery power (and remove the USB connection as desired).
Thank you for your solutions. I already done your first idea. However, to operate a physical cutoff switch is accompanied with another risk to avoid unexpected rotation of VTOL rotors even though the rotors will not work before successful arming. So I am considering another dedicated radio controlled switch to enhance safety.
CAN devices should be booted earlier than FC. So main power to the engine (ECU) should be ON while FC booting. However unintended GPIO output while booting invokes ‘engine enable’ and ‘engine start’ together.
I installed a physical cutoff switch on ‘engine start’ TTL circuit to prevent unintended start while FC booting. I hope delay-line bootloading logic to block out pin output before completion of booting.
I see this issue when using a gpio pin for relay function on a flight gontroller.
My understanding is that before the config is loaded and executed on power up the pins default as inputs and they may cause unintended operation of connected devices in the first few seconds till the fc gets running.
The solution is apparently a pull down resistor that is sized not to draw excessive current that the gpio pin cant deliver later on when the pin is driven high as an output, but small enough resistance to prevent the pin rising above the threshold of your ecu input during boot of the FC
You’re welcome
Scott
Same issue for me. I was planning to wire in RELAY1 to the starter motor circuit, but every flight conroller reboot resulted in the relay closing for ~2 seconds before going to its open default position. Mildly amusing when the circuit was connected to the car horn for testing, but uncool if the petrol engine and mower blade started every boot of the flight controller.
The starter circuit is optional for us, but wiring in the ignition kill circuit is a key safety requirement, with this reboot behaviour meaning the ICE motor would be shutdown if we did an “in mission” FC Restart (its a mower…). Thanks for progressing this.
what i would like to see is something like the MCP23017 i2c chip supported for GPIO, This is how I get around this issue with my esp32 home automation controllers since the MCP23017 wont switch its GPIO until it gets specific commands from the controller over i2c. so it stops outputs glitching on startup and stops the outputs going crazy if the controller starts to glitch.
Wow, what kind of drone are you constructing with an engine cost more than 30.000 USD (Midsizecar). Very impressive
But still I don’t get your point wy you dont trust an RC switch but you trust other RC components.
What kind of “boost-up boards” you are using. Normally the FC output is high enough to TTL logic.
%V TTLinput levels are normally Low < 0,8V; High > 2,0V
I don’t know how the FC is acting during boot sequence.
Most controllers pins are set to input as default. So if so a pulldown resistor on your “boost-up board” will help. If the the FC really switches the pin to output and to high level during boot up than ths can’t be controlled by the FC itself and you need such external cut off switch as described by all others.
My drone is not a hobby one and it should be operational aircraft like manned aircraft, that requires airworthiness certificate. Endurance is minimum 8 hours and it carries very expensive 1MUSD payloads. So it must pass typical aircraft development and test procedures including reliability and failure of each components in all envorinment. But the most important one is ‘Safety First’.
Two kinds of TTL logics are used in the industry typically. One is 3V TTL and the other is 5V TTL. And to concreate higher reliability, tighter specs of 5V TTL logic is used, especially for critical components like industrial engines, usually ECU based EFI engine for ALL environment and high altitude. In that case, 5+/-0.25V is the ‘high’ level.
I already know bootloader troubles. Either USB port powered or main system battery powered booting has same trouble to activate GPIO output while the FC is booting. Pulldown resistor is not effective one. Basically I’d like to use the off-the-shelf(OTS) components to save money and time but unfortunately most of OTS components on the market is for hobby or experimental purposes. As a result, my team is developing in-house custom made components. We modify OTS too, like CubeOrange module. I am analyzing what happens in booting stages by using electronic instruments including logic analyzer and so on to gather idea to develop customized carrier (base) board to solve the current issue.
I am still impressed of such a project.
1.000.000 USD payload: some small brillants; one container cigarettes; or a cruise missle
I really understand your ‘Safety First’ policy.
But also i am wondering in this case why you are using a ArduPilot FC which also is more Hobby than real Commercial Aeronautical use.
So if you are able to build this unknown ‘boost-up boards’ than you also should be able to built a more reliable PWM-switch.
I worked until I retiered in the field of military, automotive and aeronautical electronic HW develoment, but I never noticed a real 5V-TTL input level higer than near to 2.0 V. Don’t mismatch the Vcc of the TTL logic which is as you said rpund 5V. But Maybe your input is something special but not TTL. But ok, I like to learn.
What does your system do in case of a failure or reset of the FC during flight?
I was thinking about this, It might be worth checking all the GPIO pins on startup, I know with the esp32 there were some pins that were safe to use on startup, stm32 might be similar.
On the STM32 itself are all controller GPIO Analog inputs. So say are more less floating.
As the STM32 is very flexible to configure the functions and routings of the GPIO.
The most problem in this case might be, that in difference to most ESP32 applications on the FC is a BIOS between the high level application and the controller.used. So during startup first the BIOS is runup maybe switching some GPIOs than the FC low level routines starting up maybe switching some GPIOs and as last the top level routines startup switching the GPIOs to the function wanted. This kind of high flexible HW independent SW development is good and comfortable but sometimes it also has some disadvantages.
To achieve pin control at boot time, you can use the hwdef, both on bootloader and fimware to force the GPIO to default low. That would solve you issues
Khancyr, thanks for the info.
So you are saying that the hwdef is driving the gpio pins high on boot and this can be changed?
Also in firmware (im guessing this is for after the boot sequence?)
If this is the case im wondering why all pins wouldn’t be set to low state during boot by default?
I was had read that all pins gpio assigned pins were inputs (and therefore floating) before the boot sequence is completed when the config is then loaded and the outputs are the set as outputs and controlled by the processor
