RPI Interface Rev B
- Daniel Puratich
- Ryan Scomazzon
- Mihir Gupta
Background
Changes discussed here 2024-06-25 Comp 2025 Architecture Sync - Meetings - WARG (atlassian.net)
Who
@Daniel Puratich architecture, ideas, schematic, layout, assembly, validation, integration
@Ryan Scomazzon helping with note taking during meetings
@Mihir Gupta & @Andrew Shum for testing the previous revision
@Meghan Dang for assembling the previous revision
Where
What
New Features
Add a power supply
Then the pi doesn't need an external power supply
Will use one I already designed
XT30 power input because we have board space!
Add a pilot controlled way to disable rpi commands
we are refering to this as the โkillswitchโ but note it does not disable the pixhawk or kill the drone in anyway. It is in fact present to save the drone.
Someone should check if this is possible in software before we do this hassle.
fet or buffer to toggle communications (ps/rx/tx)
Motivation: Switch to manual control if the RPi is commanding something silly
Right now the RPi commands are weighed equally into the pixhawk as pilot control commands
itโs already happenned where pilots couldnt change flight mode because RPi continually was commanding a different mode preventing landing the drone safely. What saved us in this case was having someone repeatedly spam the controller button for the mode faster than the Pi was spamming (we got lucky the Pi was spamming slowly) and the pilot descending as fast as possible.
Search the flight tests during S24 to find this one, link here if you find it
Sure we can just write good software on the RPi or whatever, easier said then done.
Pilot must remain in control of the aircraft.
Sure this circuit adds a failure mode of accidentally disabling the autonomy system, but this is far preferred to surendering pilot of control of the drone to a potentially rogue RPi.
This circuit is required for that to be implemented.
the pilot can toggle with a switch on the controller in case of emergency
Could use a GPIO thatโs on the pixhawk header because itโs easy to map to controller
Could use CTS and RTS pins to keep it on the same harness
confirm with firmware we can make this work in ardupilot configuration here
requires changing the code (not a simple param) but should be doable?
Will leave options to do both keeping in mind I have plenty of board space here.
the circuit has the RPi disabled by default
this is accomplished with a pullup and ardupilot software configuration
this ensures that if the wire is broken for the switch the autonomy system will be disabled
this ensures that if the controller loses link with the drone then the RPi is disabled from sending commands, this allows our normally intended failsafe methods to kick in via ardupilot.
essentially, if the controller isnโt connected to the drone then the RPi should be disconnected as well by this circuit.
Chat GPT Summary of this section for the zoomers (@Sahil Kale ):
The "killswitch" feature being proposed is a pilot-controlled mechanism that disables the Raspberry Pi (RPi) from sending commands to the Pixhawk flight controller. It is not meant to disable the Pixhawk or "kill" the drone, but rather to safeguard it by allowing the pilot to regain full control in case the RPi issues faulty commands.
Purpose: To ensure the pilot can switch to manual control if the RPi commands cause an unsafe situation.
Current issue: The RPiโs commands are treated equally to the pilotโs, which has already caused situations where pilots were unable to safely change flight modes because the RPi was continuously sending conflicting commands.
Solution: The killswitch allows the pilot to disconnect the RPiโs commands via a physical switch on the controller in emergency situations.
Implementation: The killswitch could be wired using GPIO pins or CTS/RTS pins, with code changes required in ArduPilot software. By default, the circuit disables the RPi unless it is actively connected and the controller is linked to the drone.
Fail-safes: The system is designed to fail in a way that prioritizes pilot control if there is a wiring issue or if the controller loses connection to the drone.
In summary, this feature ensures that the pilot maintains control over the drone, particularly in critical situations where the RPi might issue harmful commands.
Add an LED to blink if data is being sent over UART.
The FTDI cable we use has an LED that blinks when its connected and data is being sent over. It is very nice for debugging since we can see data is being sent. Would be sick to have something similar for this board โ request from @Mihir Gupta
Adding CAN circuit
Ardu supports mavlink over CAN so this would be doable with our common CAN circuit described in CAN Integration 2025 .
not sure if we wanna do this bc
itโs a large effort for firmware
lots of added cost and complexity
basically no benefit as we are highly likely to mount the Pixhawk in close proximity with the RPi
because we have plenty of board space i will do it and then we can leave it depopulated until a later date.
Fixes from mistakes on previous revision
Soldermask opening fixed on JST-GH conn
JST connector type
Will do JST do footprints for horizontal and vertical so we can choose which one we wanna use.
Holes slightly wider on Rpi conn
Not included features
Add 1:1 camera input header
For an analog camera that takes 5V
Just in case autonomy wants to use it. Unlikely but maybe โฆ
This isnโt called for by Big Quad 2025 and is kind of just a guess based on Autonomy Compute Integration 2025 . Header can be DNPed if itโs not desired.
Design to match https://www.getfpv.com/caddx-baby-ratel-2-1200tvl-1-8mm-fpv-camera.html which also has a connector in Unified Video System .
This is not done because itโs on a different header than the normal 40pin one so not really worth it for a feature we donโt really need.
Notes
Market Research
https://www.rpanion.com/product/pi-connect-lite-v2/ very similar idea with just the power supply and pixhawk connector!
Related Resources
Explanation of killswitch conversation: here
ย