Camera Hardware Rationale
- Akshay Gaitonde
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
|
|
Decision 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) |
|---|---|---|
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 |
|
|
Pros and cons |
|
|
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:
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
Welcome to the University Wiki Service! Please use your IID (yourEID@eid.utexas.edu) when prompted for your email address during login or click here to enter your EID. If you are experiencing any issues loading content on pages, please try these steps to clear your browser cache.