2023-09-27 CAN Sensor Board Arch Meeting

Attendees

@Michael Botros

@Aaditya Chaudhary (Deactivated)

@Anthony Luo

@Daniel Puratich

@Jerry Tian

@Neel Patel

@Taim Al-Dabbagh

Structure

Meeting structure being driven by @Daniel Puratich to facilitate architecture development in accordance with https://uwarg-docs.atlassian.net/wiki/spaces/ARCHS22/pages/2065858569 . This project is currently in extremely early architecture phases and is being scoped out as a project.

System Context

Some background on our existing system:

• Current sensors use mainly I2C, SPI and UART

  • These are single ended protocols

• Currently Sept 2024 our drone is pre heavy

• To mount lidars on the drone it would be fairly annoying

Problem Statement / Needs Assessment

What is this project trying to solve?

• We’re limited on data ports on the Pixhawk for current sensor protocols

• Heavy to run many signal cables for each individual sensor

• Single ended protocols used on current sensors are prone to noise over long runs

• Mounting is difficult on some COTs boards due to non-standard mounting patterns

• Some sensor boards are expensive (individual ICs are cheaper)

Requirements

What requirements must this system meet?

• Should support rangefinders, optical flow sensor, lidars, barometers, GPS etc..

• Our solution should be incredibly adaptable to multiple airframes and can be optimized for such

• Our board should follow https://uwarg-docs.atlassian.net/wiki/spaces/EL/pages/2189197330 for easier mounting into our system

Existing COTs Solutions

• COTs CAN breakouts

  • Large to include with the sensor plus these boards

  • Expensive

  • Having a sensor plus a separate translation board is a lot of space on the drone

• I2C repeater

  • bad idea because of limitted addresses

  • hassle of extra wires and boards

  • still a single ended protocol

Implementation Ideas:

• PoC or PoE Custom board

  • Power and Data on one protocol

  • lots of EE complexity

  • would reduce wiring

  • PoE

    • Overkill for our application

    • Lots of implementation details

• Monster Mount/Board

  • One CAN Node

  • multiple connections to lots of onboard sensors

• Integration of an individual sensor and CAN node onto a single PCBA

  • no separate translational board (it’s all integrated in one board)

  • Bus based differential wiring scheme that only requires one set of wires to stack of sensors

  • Start with doing this?

  • Small boards with a single sensor and CAN node

  • Start with LiDars and Optical flow sensors because they’re high priority for Pegasus https://uwarg-docs.atlassian.net/wiki/spaces/ARCHS22/pages/2249981953

Final Implementation:

• Lidar CAN PCBA

  • EFS and EE pick chips and sensors

  • Useful for lots of comp cycles

  • Will save lots of monies in future

  • EFS figure out CAN comms to ardu

Timeline

• How many people are available to allocate towards this?

  • EE has a lot of bootcampers who are slowly working on it

• Lidar CAN PCBA

  • hopefully done by end of april

  • then few months of testing

  • fly in comp 2025