Hardware exists to make it possible to drive the car in reverse.

• Must change registers in Unitek

This issue is low priority - Reverse is not required.

End goal

Combine the pedal classes into one model due to @PatHock findings in the hybrid rules manual where the gaspedal only needs one potentiometer

Relavent Info/Links

The 2018 hybrid rules manual

Your Code

PedalController.cpp/hpp
BrakePedal.cpp/hpp
GasPedal.cpp/hpp

Involves working on the PedalController to use the GasPedal Model to grab the analog value and store it in the model

Teensy must read value from a GPIO pin and react, ex toggling an LED on another GPIO pin.

Implement basic SD card logging for the Teensy.

SD logs must be in CSV format, and include time stamps relative to when the GLV system is powered up.
Filenames must be dynamic and include the absolute start time of the GLV system.

Very beneficial for CAN tx/rx and logging

See if one of these work:

• QueueArray
• QueueList
• Arduino-Queue.h

In case we need to implement them manually:

• malloc for queue

With the circuit schematic finally nearing completion, this constants file will need to be updated

We need to transition from Driving to Shutdown after running the car.

This stage needs to get executed whenever really according to the flowchart, but that can be done at a later date.

There's a lot of registers in Unitek.hpp that are missing a get/set for them, one of them being the speed value register

This will be extremely helpful for performing automatic builds of our project against unit tests.

Some links for later reference:

• Platformio travis YML help
• Travis CI getting started
• customizing the build

The Teensy's Kinetis microprocessor has built-in hardware to reset the Teensy during undervoltage conditions. These conditions prevent the Teensy in the Main Brain circuit from powering up reliably - we know that this is an issue.

Also, the Low Voltage Detect functionality can trigger the Teensy to enter the shutdown stage in the event that the Teensy loses power. This will become more useful later when implementing SD card Logging.

The code below shows how it is currently:

//Timer event flags
const uint32_t EF_GLCD             = 0b1;  //Glcd EF mask
const uint32_t EF_PEDAL            = 0b10;  //Pedal EF mask
const uint32_t EF_SDCARD           = 0b100;  //SdCard EF mask

An example implementation of this change is shown below:

//Timer event flags
const uint32_t EF_T_GLCD             = 0b1;  //Glcd EF mask
const uint32_t EF_T_PEDAL            = 0b10;  //Pedal EF mask
const uint32_t EF_T_SDCARD           = 0b100;  //SdCard EF mask

Add code to the OrionController and the OrionModel to read store the values of the battery voltages received from the BMS into the model using the controller. CANController will most likely need to be added to for functionality for communicating with the BMS.

general options for environment variables
unit test env variable options
different env options in travis yml

Create software to control MC logic board inputs and CAN messages to MC.
End goal: eliminate/lessen the need for laptops to be used for MC testing.

will need to having polling function and talk with unitek & orion

Consider moving the hardware initialization such as the analog bit resolution into another hardware initialization file. This will only be necessary if the amount of hardware initialization grows to a point where it is clogging up main.

This can be achieved by reading the RCM's SRS0[LVD] bit, which is changed when the Teensy is reset by the LVD or POR.

This requires a solid design to set a precedent for other CAN classes or devices

This will allow for more events and some basic scheduling techniques

@ShawnPierpont add to this

use the SdioEx library, will handle all the I/O operations and none of the logging (Logging will be a controller class due to the logic needed for formatting and labelling)

We need a method to ask the Unitek to send back register data, this is somewhat implemented in

void CanController::sendUnitekRead(uint8_t regId, uint8_t pollTime = 0) {...}

There needs to be some support for using the CAN model to send the data out on the wire

Using the CANController, OrionController and OrionModel, update the current state of charge of the battery pack based on the message received from the BMS

Hello Smitty

Involves working on the UnitekController class to grab the pedal percentage from the PedalController (using the gasPedal model) and passing that percentage to the canController (along with the register to set in Unitek Model) to be sent off the wire and store the value locally in the Unitek model.

Find the correct structure of unit testing that will work for EVOS in preparation for our sprints

Documentation for it here:

platformio unit testing page

Currently they go {registerName}Reg_0xFF when they should go 0xFF_{registerName}

@JoeMaier add to this

Correlates to #28 where we only have to have CAN TX working for the Unitek.

It would be beneficial to get CAN RX working, and that may be a side effect of CAN RX with Orion #30, but for now Priority for CAN Unitek is TX before RX

With the crazy amount of issues we'll be making, a common template to reference will help us make more standardized issues for ease of reviewing.

Make it titled ISSUE_TEMPLATE.md

Example Issue templates

• Simple one
• Requires code snippet

@PatHock look at #43 first

In order to operate the vehicle in a basic sense, we need to go through all the stages at least once

Bootup ▶️ self_test ▶️ Subsystem_test ▶️ Standby ▶️ Precharge ▶️ Energized ▶️ Drive ▶️ Shutdown

• Bootup done
• Self_test done
• Subsystem_test implemented
• Standby implemented
• Precharge implemented
• Energized implemented
• Driving implemented
• Shutdown implemented

From 2018 FSAE Formula Hybrid Rules:

EV 9.2.1: The car must make a characteristic sound, for a minimum of 1 second and a maximum of 3
seconds, when it is ready to drive.

This will require some sort of implementation involving either Multiple Stages in one super loop or multiple super loops with the switch statement staging currently sketched out

in order to transition from Energized stage to Driving Stage we need to have confirmation that the Unitek is done precharging, and the user has pressed the precharge button on the Dash.

Very good progress happening, need to connect rpi with travis CI with the right configurations in .travis.yml

useful download link here

Maybe something like:

• Sent message: xxxxxx
• Rec'd message: xxxxxx

So yeah this needs to be finished but I don't know if it'll be done in time for the benchtop.

Implement very basic traction/launch control.
A "launch" is a limit on rear wheel RPMs to minimize slipping. This could be a crude hard-limit at first, but it would be better to have sensors on the front wheels to limit the rear wheel RPMs.
This will be useful for the autonomous car project. Not required for our end-of-semester goals.

as discussed move the function analogReadResolution(13); further up in the main function

Add some basic document titled PULL_REQUEST_TEMPLATE.md

Specific PR requirements for our application

• must test on hardware
• unit testing

Example PR templates

• Atom editor
• In-depth template
• Simple one

Model classes need local data storage for the hardware associated with them

Some ideas to consider:

• Common data storage field in a BaseModel class
  • Is a common data field even possible with different types of data?
• Size (in memory) of the variable used for each model
  • bool vs uint16_t vs float
• Appropriate get/set/update methods for the manipulation of data storage in the model

Due to the lack of SMD pads on the current Teensy, the port file needs to be modified for the time being when we have to get buttons working for the basic operation of the car until new SMD headers come in.

Suggestion:

• Mark the temporary port changes with a FIXME: comment on the same line so they show up when viewing the file
• make an issue titled fix port file

In order to transition from standby to precharge stages, there has to be a press of the precharge button on the Dash.

Been getting various errors with it

• Low Memory
• Identifies Cortex chip correctly but is configured wrong (M0 vs M4)
• York Wifi

We need to request and receive the battery level from Orion in order to store the 90% level in unitek as described in #29

This transition will occur once the precharge done signal is received from Unitek

• Not priority for MS2
• BMS, IMD error LEDs on the dashboard should respond to appropriate error inputs from shutdown circuit (required for FSAE rule compliance)
• Putting the car into the shutdown stage could present some problems since the LEDs need to be updated

In the most basic sense, the CanController needs to have sendUnitekWrite(...) working.

CAN RX is still important but we need to have TX working in order to run the motor at all.