Hardware/Pixhawk Dev Call: July 9, 2019

📞 Coordination Calls Hardware / Pixhawk Coordination
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

Standard Connectors… to connect

3

Agenda

  • Feedback on block diagram (not discussed on this call)
  • Pixhawk Autopilot Bus (PAB) pinout
  • Pixhawk reference standard connector choice

PAB pinout

  • (Ray Stits) Initial feedback on logically ordered connector
    • No ground near the power pins
    • No ground next to high frequency signals to shield from coupling
  • Discussion around PAB pinout in the Pixhawk Reference Standard document and introduction of the current pinout from FMU v5X

Community feedback

PAB pinout requirements

  • ADCs

    • Only used for analog airspeed sensors and custom functionality
    • No participant of the call is using them
    • Remove two analog signals and consider IC on the base as replacement

  • Safety switch LED

    • Possible removal

  • UART

    • Agreement to have as many as possible
    • Most interfaces to peripherals are via MAVLink
    • The more the better. At least two with flow control.

  • I2C

    • Q: Reduce to two instead of three (connect MS5611 to other I2Cs)?
    • The more the better
    • Side-note: MS5611 extremely light sensitive, consider DPS310 as a replacement, good results with it so far

  • ETH_POWER_EN

    • Only intended for development, can be used as a generic GPIO later

  • GPIOs

    • Q: How many GPIOs needed for customizations?

      (Jacob Schloss, via Chat)

      My gpio uses
      In previous designs, I have wanted to control enable and configuration pins on my IO line drivers, and control power to downstream sensor nets (I2C isolator + power switch)

      3 for RS232/RS485 en/config #1
      3 for RS232/RS485 en/config #2
      1 to turn on/off eth switch
      2 to turn on/off sensor nets
      1 to control CAN SILENT #1
      1 to control CAN SILENT #2
      1 to control CAN STDBY #1
      1 to control CAN STDBY #2
      1 to control CAN slew rate #1 (only needed in CAN FD BRS)
      1 to control CAN slew rate #2 (only needed in CAN FD BRS)
      = 15

      This may not work. Perhaps a future higher pin count part or an IO expander on the base board. IO expander might be more flexible, to not bog down the standard with too many pins.

      also more SPI chip selects
      not sure if STM32F7 has more hw spi CS, but MPC5777M had like 4 HW CS per spi port
      my call dropped

  • Hardware version sensing:

    • Avoid probing for connected peripherals
    • Proposed alternative: Request I2C EPROM on the base board that stores the hardware capability
    • EPROM has to be integrated in the bootloader to initialize pins (pull ups and downs) early in NuttX boot process. Two level boot process could avoid contention on boot.
    • Q: What is the full set of customization? Ethernet could be missing, IO yes/no, (Philip Kocmoud) there should not be to much variation if buses are standardized, (Daniel Agar) proposes board manifest which needs to be layered to support base board configurations
    • AI: David, Daniel and Lorenz should discuss this in more detail

  • CAN

    • Currently there are only two to stay compatible when H7 is introduced (H7 only has two, F7 would have three)
    • (Jacob Schloss) Consider alternative MCU types with different capabilities (e.g. more CAN interfaces)

  • Q: Do we need more pins to allow future growth?

    • Two PAB connectors allow more unused pins, multiple connectors are already used in the industry reliably
    • v5X brought out everything that is available on the F7
    • With more pins we can add a third CAN and more grounds.
    • (Ray Stits) Proposes 2x80 DF40 connectors (cheap and reliable > they are great), (Jacob Schloss) 160 pins sound good
    • Q: If more pins are available, what are they used for? Additional CAN and ground
    • Q: Minimum number of spare pins? (Ray Stits) 20-30% spare pins, scattered across the connector for extensibility and marked as NC (important to avoid issues in the future)
    • (Sander Smeets) Q: How many reserved pins have been used in the past? (David Sidrane) There have not been reserved signals in the past, pins have been reused and this created a big mess.
    • (Ray Stits): Consider multi-core processors in the future
    • Anticipate future changes on bus systems, e.g. video input or SRAM bus interfaces (requires 24 or 32 pins, might be a stretch at this point in time)
    • Q: Add second connector later in the development? Will create problems with backwards compatibility, drop in replacement for carrier boards that are designed now not possible, use of existing carrier boards to do initial bring up also to consider

  • Key takeaways

    • Add third CAN (potentially fourth CAN)
    • Scale up interface appropriately

Pixhawk reference standard connector choice

  • (Sander Smeets) JST GH is stated in the standard

    • Connectors are hard to work with and unreliable (pins pop back out, max 26 gauge wire > power limited)
    • Need for customization and flexibility which requires one connector per sensor
    • Alternative: Mini50 connector (probably not for single sensors)
    • Alternative: Dupont used on Dropix
    • (Ray Stits) Q: Why not customizable by vendors themselves? Avoid lock down on specific connector. (Sander Smeets) Peripherals are coming with GH connectors since they are standard on Pixhawks. (David Sidrane) MIL-SPEC, commercial and consumer hardware have different requirements > manufacture different harnesses or ask for change by the vendor. Problem: peripherals use GH connectors (e.g. GPS) > specification of alternative connectors makes them available on the market
    • Manufacturers will only make boards with other connectors if there is an alternative in the standard
    • Provide recommendation for MIL-SPEC, commercial and consumer standards

Closing

  • (Jinger Zeng) Q: How many people will be at Interdrone?

    • 4 raised hands
    • Q: Do we want to make a workshop, face-to-face meeting for the Pixhawk reference standard? Positive feedback from participants, it should be announced early and on the official schedule > Jinger to follow up on next meeting.

  • Next weeks call is cancelled since David and Lorenz are not available, next meeting is on the 23rd

Action Items

  • Community: Share datasheets and part numbers for PAB options
  • Community: How many GPIOs do we need on PAB?
  • David, Daniel and Lorenz: Discuss hardware versioning of the base board in more detail
  • Provide recommendation for MIL-SPEC, commercial and consumer standards
  • Jinger Zeng: Follow up with more information on Hardware Reference workshop or face-to-face meeting at Interdrone