Elec <> Strategy

 Date

Jun 27, 2023

 Participants

  • @Rodrigo Tiscareno

  • @Yanshen Zhou

  • @Mitchell.Ostler (Deactivated)

  • @Former user (Deleted)

  • @Alastair Correya (Unlicensed)

 Goals

  •  

 Discussion topics

Recurring meetings weekly Thursday at 11ET

Solar Power

  • Strategy has model for sun intensity

  • To sync with what inputs/outputs are

  • Input lat/long + time of day

  • Get out solar irradiance

Array Size

  • 256 cells * 153cm2 = 3.9168m2

  • 1000W/m2: 3.62W

Solar Cell configuration

  • @Former user (Deleted) to give cell normal angle for each array

    • Later forest to give angle for each cell

  • @Ryan Lam @Rodrigo Tiscareno Look at legacy code and see what translates over

Optimal speed model @Rodrigo Tiscareno @Ryan Lam

  • Inputs: Cd, A, wind speed, air density, weight, rolling resistance, system (mostly motor) efficiency curve (not constant for all loads)

    • Information that tells you how much energy you will need to move the car

    • @Former user (Deleted) to provide vehicle parameters

  • Priority 1: Make sure we can get to EOD checkpoint in time

  • Priority 2: Drive at speed at which the least energy is spent to move a given distance (Wh/km)

  • General info

    • rolling resistance is mostly constant per given distance

    • air resistance is proportional to velocity squared

    • wind direction and speed will influence air resistance

    • road material/condition will influence rolling resistance (can be a lot)

    • looking for point at which derivative of speed with respect to power = 0

Motor Max Power Model

  • What is the steepest grade in the route

  • On that steepest grade in varying wind conditions what is the motor power required to maintain our most optimal speed

Vehicle Passing Model

  • What is the power and energy consumption we would need to pass another car

    • How do we pass cars efficiently

    • Passing cars means going fater than our optimal speed and also requiring the system to privide a large burst load of power

      • This causes efficiency losses

      • If we succeed in passing how much extra power did that use compared to if that car wasn’t there

      • If we fail or succeed in passing how much do we gain compared to just staying behind that car at a slightly less optimal speed

 

Notes from strategy sync, 6/26
Overall goal: make telemetry as simple as possible

Comms:

  • Wifi

    • Low range, especially with ESP32 (30m? have we tested it? we will be outside where there are no walls etc.)

    • High data rate (multiple MBps)

    • Lost packets are resent, no missing data (unless connection completely drops)

  • RF

    • Very long range (1km?)

    • Can interface directly with Arduino with minimal code

    • Arduino supports CAN, reads bus, stores in json and sends as bytes to the transmitted

    • Another Arduino receives the messages on the chase car, sends it to computer over serial

    • Make sure antenna is omnidirectional

    • Loses packets

  • leaning towards RF due to range advantage, need to implement systems to account for data loss

    • Add checksum to verify integrity, and just interpolate if data is bad?

    • How will the receiver know if a byte was missed completely? @Mitchell Ostler

    • Maybe we can add a rolling counter?

    • Can we implement our own retransmission thing where if checksum doesn't match or counter is not sequential byte gets resent

    • Receiver can send ack to signify successful reception

    • If data transmission can't be guaranteed, coulomb counting has to be done on the car itself

  • To look into exactly what hardware to use @Mitchell Ostler

Project Responsibility:

  • Largely a strategy owned project, with fw/hw support

  • FW

    • Provide background information

    • Define system requirements, including packet format

    • Assist in hw setup

  • Strategy

    • HW purchases

    • System implementation

    • Integration with database and models

    • Testing and validation

Timelining:

  • Likely to start more seriously in the fall

    • Currently lacking onsite members capable of independently taking this on

    • Can be alleviated by providing detailed system requirements and resources

  • FW to assign someone on-site to support

Elec Data Points:

  • Primarily interested in battery metrics

    • State of charge (SOC)

    • Power usage

    • Power generation

  • Overall health of systems (whether they are online or not)

  • Everything that occurs on the CAN bus will be broadcasted over telemetry

Telemetry Power

  • Will be powered off aux batt, need only to supply 5v

  • Aux batt can be recharged/swapped without penalty at least once a day

    • Maybe more often with penalty? Don't know, @Yanshen Zhou can you take a look?

Strategy General Update:

 

Item

Presenter

Notes

Item

Presenter

Notes

Telemetry

Mitch

  • Transmit data from Can-bus, translate into JSON, send as Bytes to Chaser Receiver

  • Packages lack validity - data needs to be frequent as connection is unstable or not reliable.

  • Monitor charge - to be done on the car side.

  • Strategy:

    • Given sample data, work to translate into tabular data.

  • Firmware:

    • RF is the way to go.

    • Depending on frequency to transmit messages clearly and consistently.

  • See Project Overview / Telemetry for more details

Hardware

Forest

  • Assumptions:

    • Panel to cover the panels might affect efficiency

    • Need manufacturing sheets from cells to derive power generation.



 Action items

 Decisions