2023-09-27 CAN Sensor Board Arch Meeting

Owned by Michael Botros
Last updated: 2023-09-28 by Daniel Puratich
2 min read

Attendees

@Michael Botros

@Aaditya Chaudhary

@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 Iterative Design Process . 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 Mounting Hole & Pattern Specifications 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 2024 System Architecture

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

 

 

 

 

 

Â