The SIUE Solar Racing Team
Founded in 2004, the SIUE Solar Car Team has continuously striven to build a better, faster, and more efficient solar car. Engineering and business students comprise this team of like-minded and innovative individuals seeking to win the American Solar Challenge Formula Sun Grand Prix in 2017. In the 2015 Formula Sun Grand Prix, the SIUE solar car drove over 225 miles on the Circuit of the Americas in Austin, Texas.
The Formula Sun Grand Prix (FSGP) is an annual track race that is held on grand prix or road style closed courses. This unique style of solar car racing is open to teams from around the world and truly tests the limits of the vehicles in handling curves, braking, and acceleration. On years when the American Solar Challenge (ASC) is held, FSGP serves as the qualifier race for this competition. Teams must successfully complete FSGP to prove their vehicles before they are allowed to start the cross-country ASC journey. The racing strategy applied during the three day FSGP track event is different than the cross-country ASC event. Driver training, passing strategy, and quick pit stops are crucial for teams racing in FSGP. It’s also essential to have a diligent team member in the timing booth and follow all of the rules of the track to ensure all laps get counted.
The winner of FSGP is determined by the total number of laps completed over the three days of racing. The team that completes the fastest single lap around the track is also recognized in the awards ceremony.
The SIUE 2017 FSGP Team
2016 SIUE Solar Car
This year the SIUE team has incorporated a Raspberry Pi into their solar car, NOVA! The Raspberry Pi is the informational hub of the NEW SIUE Solar Car Driver Information System.
The Driver Information System
The team’s car will contain a Driver Information System to monitor, alarm, log data, and provide dynamic web pages. The goal of the system is to optimize the performance of the car and predict problems with the car’s equipment.
There are three parts to the system. The first part is on the car. It consists of a Raspberry PI computer with a touch screen. It collects data from the car’s instrumentation. It displays information on the screen and shows when it is out of limits. The data is sent via radio to the second part, a stationary trackside computer. The stationary computer logs data to its hard drive. The team will use this computer to view information and make decisions. It uses the Internet to push data to the third part, a Web server computer that is located in a student’s home. This computer does long-term logging of data. It is used to store set-point information. It provides browser access to the data from the car.
The server computer can be accessed by several web browsers at the same time. They can be computers or cell phones. There is no need for a special ‘app’. Spectators can log in without a password. Team members logging in with a password can see more information. Administrators can log in and change system set-points.
The PI on the car talks to a GPS receiver.
The PI also talks to the Battery Management System using CANbus communication.
The PI talks to the motor controller.
The PI senses ambient temperature in the car’s cockpit.
The PI talks to the GPS using the NMEA protocol. This give latitude and longitude position. The stationary computer, the web server computer, and the browsed views all show the location of the car on the track as it makes each lap.
The GPS also gives ground speed. This can be compared to the speed from the motor controller.
The PI approximates a count of how many laps around the track it has made using the GPS. An area will be defined around the finish line. Every time the car enters this area the PI will increment a lap count.
The team is building a New Generation Motors EVC-402 Modbus Translator using an Arduino processor. This module translates the specialized protocol of the New Generation motor controller to the industry standard Modbus protocol.
Logged items include:
Battery Cell Voltages
Battery Cell Temperatures
Motor Controller Voltage
Battery Pack Current
Battery State of Charge
Driver Compartment Temperature
Total Distance Traveled
Backstretch Data Buffering
The team desires to have data logged at 15-second intervals. This means 40 samples out of a 10-minute lap. It is estimated that the car will only be in radio range of the stationary computer for 4 minutes out of each lap. That means that several samples will have to be buffered in the memory of the PI while the radio is not working. These samples will have to be uploaded to the stationary computer when communications are restored. Each sample will have to contain the correct timestamp for when it occurred.
The 15-second logging interval presents a problem when trying to catch short-term transient conditions like peak motor current. The PI will contain special Peak-Hold logic that ‘stretches’ peak values out for a period of time long enough to guarantee that they are caught by the logging.
Lap-Synchronized Data Views
Plotted historical graphs of a parameter like motor current are much more meaningful if they are synchronized with where the car is on the track. The system proves the capability to see several traces of the data overlaid where the traces are approximately synchronized with the lap position.
Each of the three computers runs the CorsairHMI program. The Solar Car team is doing the configuration of the program and programming the NEMT.
Corsair supplies HTML views to web browsers as a web appliance. It does not use Apache or IIS for this function. It can serve HTML directly out of a Raspberry PI if needed.
CorsairHMI features that have been developed for the Solar Car project are available with all versions of the program. Both Linux and Windows versions are available through Zagros Robotics and other CorsairHMI partners. Application notes related to the Solar Car project are on the corsairhmi.com website.