Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

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 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

Timeline

  • How many people are available to allocate towards this?

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

  • No labels