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 2 Current »

Status

IN PROGRESS

Owner

Akshay Gaitonde

Contributors

Akshay Gaitonde

Approver

Diya Rajon

Due date

?

On this page

🌍 Overview

This is the design document for the camera system. As per regulations we must have a back view of the car. Since our canopy design prohibits a rear view mirror, we resort to a camera feed. From previous driver anecdotes, there are large blind spots due to the limited visibility due to the helmet. The intended design for this car will be for the camera to communicate directly to the display since no other system nor board will require the feed.


❓ Problem statement


Controls is tasked with ensuring the driver has a good idea of their surroundings. As per regulation, there must be a rear view feed.

💡 Research insights


Also, Daybreak’s backup camera feed solution of an isolated off the shelf camera system is not optimal as both the camera and display are not the best in bright light or low light. We also have to consider some methods of interfacing with the cameras and integration with the display.

📊 Solution hypothesis


The solution is successful if we are able to always see the rear view camera feed at an appropriate resolution and frame rate while being efficient in power usage and wiring. We also consider the usability of any other additional camera feeds and if they are efficiently rendered.


🪛  Design options - Camera Communication

There are a few main considerations for communicating between the camera and display. Our main options are Ethernet (specifically Power over Ethernet so we can save on wiring power cables), USB, and CAN. Some main considerations include noise resistance, amount of wiring needed, feasibility to use in the context of the rest of the electrical system, and consideration for multiple camera feeds (in case we want to add peripheral views).

Option 1 - Power over Ethernet (PoE)

Option 2 - USB

Option 3 - CAN

Overview

Most home security cameras are connected using PoE and work by simply assigning static IP addresses to the cameras on the network. For our system, we could use the IEEE 802.3af PoE standard since we don’t need a gigabit transmission speed. Ethernet is optimal for long distance communication.

Webcams are typically connected via USB because USB is the easiest to set up (plug and play). USB isn’t protected from degradation over long distances but we can add repeater modules in the middle of the wire to boost the signal.

CAN is a protocol we are very familiar with as we use it for reliable communication between electrical systems. CAN is noise resistant so it is robust in an automotive environment. But it is not optimal for high data throughput with real time constraints such as video streaming.

Pros and cons

Robust over long lengths

Power + data in one wire

Requires 36V-48V

  • It’s impractical to supply this voltage to the cameras because it will add another power line from the battery

  • if we have multiple cameras, the network switch will have to implement PoE as well

Higher power consumption

  • Based on searches, it looks like most PoE cameras that fit our use case consume ~15-20W

Plug and play

Power + data in one wire

Needs a repeater for lengths over 4 m

USB physical connectors are not vibration resistant

  • Favor M12 (A coded connector) instead

Moderate power consumption

  • Based on searches, it looks like most PoE cameras that fit our use case consume ~5-10W

Noise resistant

Established BSP

Need CAN chip on raspberry pi

Unusable for video transmission with standard 8 B packet size (throughput is a major problem)


Decision 1

  • Option 2 - USB

We prioritized feasibility in fitting with our current electrical power design with practicality in actual video transmission.

USB Connections:

USB physical connections are not automotive grade. We will need to design a a board for the microUSB OTG port on the raspberry pi zero to break out into 3-4 USB ports using an M8 or M12 connector if we have multiple cameras. If we only have 1 camera, we will need a simple adapter from micro USB to M8 or M12.


🪛  Design options - Camera Config

We aim to help driver visibility and awareness of space surrounding the car. There are a few main considerations for visibility. Aside from the regulation mandated backup video feed, we know that the driver has limited FOV due to the helmet and canopy. Per regulation, the canopy also must allow for 200° of clear visibility. The helmet then further reduces the FOV. We investigate whether it is feasible to add some peripheral cameras to view side-of-the-car feeds to improve visibility.

Option 1 - No Side Cams

Option 2 - Side Cams (x2)

Overview

Regulations met. However, driver may have very limited knowledge/awareness of blind spots. The rear camera will will have a wide angle lens covering somewhere between 130 and 170 degrees. The driver will technically have a 200 degree FOV for the canopy as mandated by regulation but I estimate that the helmet restricts this to around 180. This leaves sizeable blind spots on either side.

Webcams are typically connected via USB because USB is the easiest to set up (plug and play). USB isn’t protected from degradation over long distances but we can add repeater modules in the middle of the wire to boost the signal.

Diagram

image-20241008-210125.png

image-20241008-211619.png

Pros and cons

Meets regulation

Minimal setup

Minimal power consumption

  • Based on searches, a singular wide angle camera consumes ~0.5-15W depending on the type

Driver has a blind spot

  • Since dimensions of the car are not finalized yet, I estimate that the driver has a blind spot that could potentially hide a prius-size car.

Huge blind spot reduction/elimination based on camera positioning

Meets regulation

Needs a USB breakout board

More complexity in video processing (graphics more complicated)

Moderate power consumption

  • Based on searches, it looks like most USB cameras that fit our use case consume ~0.5-5W

Potential Candidates


Decision 2 [NOT DECIDED YET!!!]

We are still considering whether to have side cams or not as well as the options in both areas.

  • No labels