Camera Hardware Rationale

Owned by Akshay Gaitonde
Last updated: Oct 17, 2024
1 min read

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

 

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

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

  • Favor M12 (A coded connector) instead

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

Decision 1

  1. Option 2 - USB

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

 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)

 

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

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

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

     

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

 

Akshay Preference:

Rear view: https://www.amazon.com/SVPRO-Fisheye-Infrared-Surceillance-Security/dp/B09FXTDNQ5

Peripheral: https://www.amazon.com/SVPRO-Fisheye-Infrared-Surceillance-Security/dp/B07C1JHB6K

 

Justification:

  • I like peripheral cam idea

  • I like how these cams have IR for night vision (in case we driver in a darker environment like a tunnel or during the evening)

  • for rear cam: voltage DC 5V, current 150mA (so consumes 0.75W which is not bad)

  • for periph cam: voltage DC 5V, current 120mA~220mA (so consumes 0.6-1.1W which is not bad either)

  • both are ~30g in weight

  • video codec works with r pi

Confluence Documentation | Web Privacy Policy | Web Accessibility