Pixhawk Dev Call: July 2nd, 2019

Pixhawk
1

Agenda:

Dial-in:

Join Zoom Meeting

One tap mobile
+14086380968,567710856# US (San Jose)
+16468769923,567710856# US (New York)

Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 876 9923 US (New York)
+1 669 900 6833 US (San Jose)
Meeting ID: 567 710 856

Find your local number: https://zoom.us/u/aetSYKbiMF

2

AI: Need functional decomposition (the behind design decisions and design patterns)

3

PX4 hardware dev call notes

Tuesday, July 2, 2019
11:03 AM

David Sidrane

  • Hardware block diagram overview

Trying to discuss the standard using FMUv5X as the first implementations.

FMU as core autopilot
Base - kitchen sink approach -try to build a superset of components

Autopilot
- 3 sets of sensors in 3 independent power domains
- Main CPU and debug connector (including full trace output)
○ Could be left off on production units
○ Use “full debug module” when debugging needed
○ Secure element for remote ID and authentication , authentication for pairing.
○ uSDCard
- No IO processor

Baseboard - additional IO processor would live here.

  • not so useful for larger aircraft with CAN or Ethernet
    Battery input
    Power path selector - complex logic here.
    Three telemetry outputs (more)
    External I2C
    External SPI - NFC or other prototyping
    Capture inputs. With PWM
    Two CAN transcivers
    On baseboard barometer - provide one that is barbed to measure static pressure to outside the fuselage to provide better readings on fast aircarft
    Boot enable method to interfact to mission computer connected to baseboard. Ensure the CC and FMU are in sync. So you can flash only when you know it is safe. (no flashing when armed for example)

Ethernet PHY
Two wire , four pair unshielded
Two GPS inputs.
USB C (since it’s new) + 4pin JST-G (panel mount connector)

eMMC on processor - Kingston?? (iain)
8 bit wide vs 4 bit wide? (but currently not enough IO)
- Is communications protocol published?
- eMMC can it run in 4 bit mode?

Gating factor for two wire eth - adapter that we’re working on.
Ø 100 mbps availability is interesting.
Ø Noise immunity and effect for GPS
○ Much closer proximity.

David
Sensor modules
- Three sensors busses to
- Three separate power domains
- Three sensing of voltages
- Heater from timer using PWM
- DRDY connected to processor + timer input so you can figure out interrupt latencey
- Sync line for timestamping
- BMP388 on i2c bus. (keep cable simple can run at high frequency on it’s own bus)
- Calibrated module from factory. Cal info stored on modules. Make is portable from board to board
- This design accommodates the data rates needed for the sensor system
Power domains
- Four sensor busses, with their own sense and control.
- Power domains associated with each
Q: power selection on 5V bus
Can you read both 5v bus and know that one has failed? (power path selector) does the FMU know if one is failed - know the I and V and know which one is active one. You know the battery voltage. But don’t specifically know the output side. (we only know it post selection. There is no intermediate sensing.)
Brick one is highest priority if it exists and is valid. Then brink 2. In-power A,B C (brick 1, Brick2, USB)

We are also measuring sensor power rails to be able to infer if there is a sensor instability related to power.

Why is there a Baro and IMU on the FMU module?

  • concerned about vibration isolated FMU. Could cable break and cause a catastrophic failure? On board hardmounted sensors mitigate this issue for recovery. (mag data coming from GPS.)

Q: IO functionality
Currently all the SBUS functions mppm and spectrum for designs that don’t use the IO processor. Functionality is taken on by
Lose SBUS out “officially” (no one uses it. But we can easily output 1 wire UART design ).
Use case - Large aircraft - needed to run quick tests using off the shelf servos. Ran SBUS to servos. (Switch to CAN later)

Q: using usb C?
Proposing USB C, will it be USB2 + form factor…
A: Want the connector form factor with bridge chip to use data-lines. Could possibly use for additional power input.
Recently used USBC + USB2 . Implemented power delivery on board. Could provide a lot of power to system. But requires additional hardware.
Lorenz - can design elements be shared? YES
Good choice using USBC!
5A step down - (ST power delivery chip.)

Jacob - application question
Problem - capacitive coupling to sensors to wingtips?
When do we do our own?
- Eventually move to auto parts. And auto portfolio
- Next iteration includes more auto power supply, cpu etc
- Baseboard - accommodate larger aircraft with meaningful changes if needed? What are the common needs?
Lorenz - would like to continue to discuss in SLACK.
Look at functional pinouts , and please provide feedback. EVEN if it is - yes this is ok
But please point out any shortcomings in the design
Want to work on connector routings next…
Collaborate now to get to the best solution.

Comment - why were certain design decisions made.
- Write this out in a google doc?
- Powerpath for example - are we happy with this
○ If written - this could be handled asynchronously.
- Scope creep - good - what is broken in pixhawk and lets fix it… but now lets talk about next iteration more specifically. Would like to split out FMUv5requirement document from standard.
○ Pull standards document along with it
- Wire specific application around it, and use that to determine where there are deficiencies.
- Functional decomposition needed?
- Are the design patterns well understood? Are they wrong?
Redundancy

  • Single point failures in the architecture?
    • Looking for drone industry experience? Redundancy on the sensors for example from shorting a power supply.
    • MEMS failed in single axis.
    • Single point of failure on power switch
      ○ Diode them together??
      ○ FMUV4 - really done on shedding parts.
      ○ Would be good to understand thinking on power supplies etc.
      ○
    • Trying to address common cases. This design will fall short of truly fault tolerant designs in Aero grade system. “commercial best effort” reliability
    • Can isolate individual units and vote between them for redundancy (for this interation of design.)
      Q: is it possible to run two of these SOMs?
      • You could run two busses (three)
      • Move to UAVCAN and vote on the receiving end.
      Q: CANbus
      • Why on baseboard and not the module?
      • Some designs don’t need CAN , so they could be removed from baseboard.
      • Allow variety of choices.
      • Fault tolerant version? (please discuss in hardware channel)

Closing:
- FMUv5X design doc with block diagram will become
- Feedback needed by next week.
- Trying not to block
- Pin links to slack channel into document.
-
CLOSE