RPI Interface Rev B

Owned by Daniel Puratich
Last updated: 2024-10-03 by Daniel Puratich
1 min read

  • Background

  • 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

    • 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

  • Notes

  • Market Research

  • Related Resources

    • Explanation of killswitch conversation: here