Open

(Off screen of the car’s dashboard, NERO)

About

The software sub-team is responsible for all code written both on and off the car. We boast over 5 Firmware projects that are responsible for all controls on the car and 3 graphical applications to assist the engineers and driver in optimizing the car’s operations.

The largest project the software team works on is our custom project management dashboard, FinishLine. FinishLine’s goal is to have our club (and others in the future) be able to manage all projects, teams, and finances via the dashboard. To access the app, you can go here and sign in with your husky Google email. The other applications are hosted locally, or require protected logins to access, like our Grafana cloud dashboard that allows the engineers to interface with all the data collected on the car (Argos).

Projects

FinishLine

This project is a full-stack Typescript project management dashboard that uses React on the frontend and Express on the backend. The application includes a fully custom gantt chart, finance dashboard, calendar and design review scheduling system, and a project + change request management system.

The current tech stack list is provided below:

• TypeScript

• Node.js

• Express

• React

• React-Query (State Management)

• Prisma (Database Interface)

• PostgreSQL

• Vite + Vitest

• Docker

• Git

• Yarn workspaces are used to maintain it as a monorepo

The app is deployed on AWS Elastic Beanstalk using the Docker configuration for the backend and Netlify for the frontend. It uses AWS RDS for the database.

Argos

This project is a full stack data acquisition, storage and visualization tool. The backend is written in Rust, while the frontend consists of both an angular + typescript web application and an IOS Application written in SwiftUI. The application interfaces directly with the car and allows the engineers to view data in realtime anywhere the car is as it can be run on an embedded router that connects to the car via a Halow 900MHz Wifi connection. The data is uploaded to the a Timescaledb cloud instance once connected to the internet via a series psql statements run through a bash script. This data is able to be accessed from anyone via a cloud hosted Grafana instance.

The current tech stack list is provided below:

• Typescript

• Rust

• Angular

• Tokio + Axum

• SocketIO

• Mqtt

• TimescaleDB

• Node.js

• SwiftUI

• Docker

• Git

• Grafana

• Bash

• Psql

The app is deployed on an OpenWRT router using a special docker compose configuration that boots up both the server and frontend. The backend and database is also run on the Telemetry Processing Unit directly on the car for more reliable data without relying on continuous Halow connection.

NERO

This is the car’s dashboard. It displays information about the current state of the car to the driver and most importantly, runs a custom implementation of Flappy Bird!

Open

The current tech stack is listed below:

• C++

• Qt

• QML

• Mqtt

The app is deployed via Odysseus on the Telemetry Processing Unit.

Odysseus

This is a custom buildroot-based Linux distribution. It is primarily designed to accomodate all code on the Telemetry Processing Unit of the car. This includes the seperate projects of Calypso, NERO, Argos (soon); and the included Siren (a MQTT server), TPU telemetry (a diagnostics and Odyssey feedback framework), Wireless (the long range wifi project), and more. It is responsible for controlling Telemetry Processing Unit hardware: CAN bus reception, GPS for location and a time source (using NTP), wireless remote flashing and debugging of Cerberus and Shepherd, and further short range and wifi configurations.

The current tech stack is listed below:

• Buildroot

• Busybox

• Linux kernel C

• Mqtt

• CMake

• Python

• HaLow (IEEE 802.11ah)

Cerberus

This is the car’s central processor. It manages the state of the car (Whether you can drive or not and how you can drive), as well as is responsible for interpreting the amount of torque to deliver to the car dependent on the drivers foot position as well as when and how strong to regenerative brake.

The current tech stack is listed below:

• C

• FreeRTOS

• CAN

• CubeMX

This project is deployed on a STM32 IC as part of the Main Processing Unit printed circuit board.

Shepherd BMS

The Shepherd battery management system monitors cell voltage and temperature levels, processes readings, and broadcasts them over CAN.

The current tech stack is listed below:

• C

• CAN

• CubeMX

• STM32F4 MCU

Calypso

This is a custom Controller Area Network (CAN) decoder. It is responsible for listening to all the CAN messages on the car and then sending these messages over MQTT for Argos and NERO to listen for so that the engineers and driver can see what the communication between the different ICs on the car looks like. This project also can emit user specified messages that can set certain parameters of the car manually without having to make any code changes.

The current tech stack is listed below:

• Rust

• MQTT

• CAN

The app is deployed via Odysseus on the Telemetry Processing Unit.

Mechanical Sensor Boards

This is a network of small peripheral custom PCBs which collect mechanical measures of car performance over time. Currently 4 central processors recieve from 5+ sensors each, and emit the filtered sensor data over the CAN bus. The firmware manages the state and drivers for each sensor, emits CAN messages at the specified frequency, and has bootup customizations to allow for non-conflicting states for each of the central processors.

The current tech stack is listed below:

• C

• FreeRTOS

• CAN

• CubeMX

This project is deployed on each of 4 STM32 ICs as part of the Central Mechanical Sensor Board printed circuit board.

History

The software team was originally conceived by James Chang Davidson, one of the club’s project managers at the time. Seeing how much both the engineers and project managers hated doing project management in the club’s current state, and being a CS major, he felt that he could create an application that would be able to remove the need for project managers as a role entirely. Thus the NER PM Dashboard v1 was created in July of 2020 as a Google Apps Script web application attached to the database Google Sheet file. Major development took place during July and August prior to the start of the Fall 2020 semester. During Fall 2020, two developers make incremental improvements, and then in Spring 2021 a team of developers was formed.

The NER PM Dashboard v2 was hypothesized during the Fall 2020 semester as the v1 developers ran into platform and framework limitations. Research, planning, and project initiation for v2 began in Spring 2021. The end of Summer 2021 was selected as the initial launch deadline for v2, but was not met. In Fall 2021, the team of developers was formalized into NER's Software Solutions team and grew to 20+ members. January 18, 2022 was selected as the adjusted launch deadline for v2, but was yet again not met. In Spring 2022, the Software Solutions team grew to 70+ members. The application finally launched in May of 2022.

However, there were more technical limitations with v2. This led to the creation of NER PM Dashboard v3 led by Anthony Bernardi in Summer 2022. The biggest change was using Express on the backend instead of Netlify Lambdas. It also generally cleaned up the repo and used Yarn workspaces as a better way to keep the monorepo instead of the workarounds used in v2. It was also rebranded to FinishLine by NER.

With such a large number of new members, the software team developed a series of “Learning Sessions” intended to run concurrently with onboarding to teach new members the technologies that FinishLine used. These began in Fall of 2022 under the leadership of Bernardi and laid the foundation for “Launchpad”, an idea for a dedicated period of onboarding where new members would spend a fixed amount of time in a very structured environment learning the technologies of the project they would end up working on before they actually started developing for that project. Learning sessions however would run from Fall 2022 - Spring 2024 before Launchpad was created.

With an established onboarding process and a strong foundational project for new members, the software team decided to add a new project, NERO in the spring of 2023. This was software’s first step into integrating more in the engineering world of NER, and it forced the developers to work closely with the engineers to figure out what was the most relevant data for each mode of the car. The end of the spring also marked the the creation of the Chief Software Engineer role, previously known as the Head of Software, who would be recognized on the E-Board of the club.

After the success of NERO, software decided to add another project in fall of 2023, Argos, with the focus of creating a data pipeline to be able to wirelessly store all the data recorded on the car. Argos and NERO, being so distinct from the main project of FinishLine, forced the software team to create an organizational change. These two new embedded projects would be known as Application Software, and FinishLine would move into its own Web Development team. Both of these teams would have their own head and would report to the Chief Software Engineer.

FinishLine over the summer/fall of 2023 and spring of 2024 with the leadership of Reid Chandler as CSE and Sean Walker as Head of FinishLine, would create a complete finance dashboard, a custom editable gantt chart, and a brand new Design Review Calendar that would become the applications three main features for the upcoming 2024 design cycle. Such major feature additions resulted in a version bump to PM dashboard v4.

While the software team continued to run smoothly with record number of applications semester over semester, it seemed to result in less and less applications for the Data and Controls system as it was hard to express the difference in work that was being done for the firmware of the car, and the FinishLine + GUI applications that the software team was creating. So throughout the spring and formalizing in fall of 2024, the Application Software team and Data and Controls electrical team, who already collaborated closely together, formally merged into the Embedded Development team, co-run by both software and electrical. This was done in the hope of people joining the software team would be correctly directed to the Firmware projects within the club for people who were interested in that.