1

Solar Car User Guide 1. Preface

1.1. README 1.1.1. Authors: Nile Mittow, Sebastian Bloem, Francois Demoullin, Chris Ellis 1.1.2. Summary

1.1.2.1. This user guide is meant to explain how to utilize the Solarri anti­lock brake and regenerative braking system.

1.2. Audience 1.2.1. Members of the UC Davis Solar Car team, Solarri.

1.3. Vocabularies 1.3.1. System

1.3.1.1. Anti­Lock Braking System (ABS) ­ a system that aims to prevent rolling wheels from locking up as the brakes are applied.

1.3.1.2. Regenerative Braking ­ a technique in electric vehicles that attempts to provide some braking force while generating electricity.

1.3.1.3. User ­ For this system, the user will be the driver of the electric vehicle upon which the system has been installed.

1.3.2. Hardware 1.3.2.1. MSP430 ­ A low power microcontroller produced by Texas Instruments

(TI). 1.3.2.2. Microchip MCP2515 CAN Controller with SPI ­ An integrated circuit

that implements the CAN specification and utilizes Serial Peripheral Interface (SPI) to interface with other microcontrollers.

1.3.2.3. MCP2562 CAN Transceiver ­ An integrated circuit that interfaces between a CAN protocol controller and a physical CAN wired bus.

1.3.2.4. Hall Effect Sensor ­ A type of transducer that varies its voltage output based on nearby magnetic fields.

1.3.2.5. Pressure Sensor ­ A sensor that varies its output voltage based on the amount of pressure being input into the sensor.

1.3.2.6. Shift Register ­ An integrated circuit designed to store multiple bits by serial input and read them via parallel output.

1.3.2.7. 7­Segment Display ­ A small digit display used to visualize output ­ similar to what generic alarm clock radios use.

1.3.2.8. Wheel Hub Motor ­ The motor which drives the Solar Car, is encased within the hub of the wheel. Tentatively a Mitsuba M2096­3. Please see manufacturer's specification sheet for more detail.

1.3.3. Software 1.3.3.1. Code Composer Studio (CCS) ­ A version of the Eclipse integrated

development environment (IDE), created by TI. Allows easy programming and debugging of MSP430 code.

2

1.3.3.1.1. MSPWARE ­ A special library of MSP functions provided by TI to simplify the coding process of their MSP line of microcontrollers.

2. Overview of the system 2.1. Background

2.1.1. Regenerative Braking 2.1.1.1. For solar vehicles, efficient usage of electricity is paramount in

determining the total operational time of the vehicle between charges. Therefore, in the case of solar vehicles, it is important to take advantage of any opportunities that would increase the overall electrical efficiency of the vehicle. Techniques such as regenerative braking were developed for this purpose. With regular mechanical braking, the energy being spent to apply the brakes is lost as heat through friction. Regenerative braking is a secondary braking system that provides some braking force while recapturing some of the braking energy as electricity. It is important to note that regenerative braking is not a replacement for mechanical braking because it does not provide anywhere near the same level of braking force as mechanical brakes do.

2.1.2. Anti­lock Brake System 2.1.2.1. In automotives, having the wheels lock up during motion is a dangerous

situation. It cause the vehicle to begin sliding and severely reduces the driver’s ability to maintain control of the vehicle. In the case of most solar vehicles, ABS is usually not included in the design of the vehicle because it is often very difficult to implement. The ABS system developed by in project attempts to provide a basic system that can provide this feature to the Solarri Solar Car.

2.2. Description 2.2.1. These systems have been made to increase the overall performance and safety of

the Solarri solar vehicle. The regenerative braking system provides a mechanism to increase the operational distance of the vehicle and the ABS system increases the safety of the vehicle.

2.3. Technical Specifications 2.3.1. Code Composer Studio

2.3.1.1. This project was developed using the most recent version of CCS available at the time, version 6.12. This IDE supports code in both C and C++. For this system, the code was primarily developed in C.

2.3.2. MSPWARE 2.3.2.1. A special library of functions created by TI to simplify programming

their MSP line of microcontrollers. The library can be installed within CCS by searching for MSPWARE in the app center. This project used the most recently released version, 3_30_00_18.

2.3.3. MPLAB X 3.3 (Microchip Processor IDE)

3

2.3.3.1. Ported J1939 Can library created in 2003 for use with a dsPIC33EP32GP502 Microchip processor. The library will work minor modifications for any microprocessor system.

2.3.4. MSP­EXP430F5529LP 2.3.4.1. A “launchpad” version of the MSP430, which provides an easy platform

for MSP430 development. This device was used to provide analog to digital conversions for analog voltage values.

2.4. Features 2.4.1. Regenerative Braking

2.4.1.1. The regenerative braking system utilizes an analog input from the pedal via a potentiometer and outputs a second potentiometer signal to the regenerative braking control line on the wheel hub motor.

2.4.2. Anti­Lock Brake System 2.4.2.1. The ABS system functions by controlling the amount of pressure in the

hydraulic brake lines, bleeding off and re­applying pressure when deemed necessary. Because we currently do not have the hardware required to physically implement the system, we focused on creating the logic required to take input values from wheel speed and requested brake force to determine when wheel slippage occurs and thus when ABS needs to be triggered. We will continue to communicate with the Solari team past the official completion of the senior design project to modify the code as required and provide support.

2.4.3. CAN Bus System 2.4.3.1. A vehicle can have many different embedded microprocessors handling

everything from braking to engine diagnostics. The solar car will have many embedded systems handling the processing of regenerative braking, ABS, battery charging system, solar panel performance, cruise control, etc… All of this adds up to a lot of data that needs to move around from system to system for analysis. Using wires from each system to every other system would create a cobweb of confusion as well as suffer from poor performance. A CAN bus can provide a means to have a twisted pair of wires that runs from one end to the other. Any system (node) can simply plug into the CAN bus and immediately pass and take in data. Every node will receive an address that it can use to send and receive data with. The CAN bus can also be used to perform live debugging and reprogramming of any sub­circuit in the system. It also provides a means to see what system is having trouble. As noted above, only polling has been implemented so far. We will continue to develop this CAN architecture in the following months to create a robust and complete solution to data acquisition and processing in the solar car.

3. Installation 3.1. Software

3.1.1. Code Composer Studio

4

3.1.1.1. Installation (Windows) 3.1.1.1.1. Go to TI website to obtain installation executable:

http://www.ti.com/tool/ccstudio 3.1.1.1.2. Run install executable 3.1.1.1.3. Open CCS. If prompted to specify workspace, select a folder to

be location that projects are stored in. 3.1.2. MSPWARE

3.1.2.1. Installation 3.1.2.1.1. Open CCS. 3.1.2.1.2. On the top of the main window, press “view” and then select

“CCS App Center”.

3.1.2.1.3. On the App center page, seach for “MSPWARE”. Select it and press “install software”.

5

3.1.3. Importing MSP430 project archive into CCS 3.1.3.1. Open CCS. Select “Project” and then “Import CCS project”.

6

3.1.3.2. Select to import and archive file and browse to location of archive on system. Press “Finish” and CCS will extract and import the archived project into your current workspace.

3.1.3.3. The archived project will now be listed in the Project Explorer.

7

3.1.4. MSP430 Wiring Guide for ABS/Regen system Demonstration 3.1.4.1. Materials needed:

3.1.4.1.1. MSP430F5529 3.1.4.1.2. Solderless breadboard 3.1.4.1.3. 3 potentiometers 3.1.4.1.4. Several male to male and male to female wires

8

3.1.4.2. Step one: Place potentiometers onto breadboard, so that each pin on the potentiometer is connected to a separate numbered column (i.e A10, A13, A16).

3.1.4.3. Step two: Connect one male to female wire to the high voltage rail

(marked with a red +) and another to the ground rail (marked with a blue ­). Next connect a female to female wire between ground and pin 1 of the potentiometer and another between high voltage and pin 3 of the potentiometer. Finally, connect a male to female wire to pin 2 of the potentiometer.

9

3.1.4.4. Step three: Repeat steps one and two. There is no need to repeat placing

the high voltage and ground wires.

3.1.4.5. Step four: Connect pin 2 from each potentiometer to the pins labeled

“6.0” (brake signal), “6.1” (current vehicle speed), and “6.2” (current wheel RPM) on the MSP430. Connect the high voltage wire to “3.3V” and the ground wire to “GND” on the MSP430. Plug the usb cable into the MSP430 and a computer.

10

3.1.4.6. Open the Jeep Integration project in the CCS 3.1.4.7. Press the green “Debug” button to load the program onto the MSP430. 3.1.4.8. Press play to begin running the program. As the potentiometer for the

brake pedal is rotated to increase its outgoing voltage, this will simulate pressing the brake pedal in further and further. Press the yellow “pause” button to pause the program. In the Expressions tab, the current percentage of regen being requested can be determined by the “regen” variable.

3.1.4.9. The remaining two potentiometers simulate the readings for the jeep’s

current speed and the RPM value for a single tire. Adjusting the potentiometers to different values will represent the different values. When the current vehicle speed greatly exceeds the threshold RPM for a wheel, the system will detect that a wheel has locked up and needs to activate the ABS to free the wheel. When this occurs, the red LED on the bottom of the MSP430 will light up. Pressing pause and viewing the expressions window will allow you to see the current values the for these variables. For convenience, the RPM value has also been converted to a speed value to allow the vehicle speed and wheel RPM to easily be compared.

11

3.1.5. CAN Controller Library Guide

3.1.5.1. The J1939 Library can be found at http://www.microchip.com/wwwproducts/en/en010406 in the Documents > User section.

3.1.5.2. The library was built in 2003 and not much has been done since to update it to meet the needs of the latest compilers and microprocessors.

3.1.5.3. The library has been updated to work with any microprocessor chosen by the end user. It will require modifying the necessary lines in a newly created file: J1939_customizer.h and J1939_customizer.c.

3.1.5.3.1. New implementations of ReadSPI1() and WriteSPI1() have been added for use with Microchip processors. Modifying these files for another manufacturer, or just including the necessary SPI header file to J1939_customizer.h should be fairly trouble free.

3.1.5.4. The library is presently in a GitLab.com repository. If you would like access, email Sebastian Bloem. The contact information is at the end of this guide. Once the library has interrupts implemented, the repository will be made open source for anyone to access.

3.1.6. ABS/REGEN Library Guide 3.1.6.1. Regen Motor Signal: The amount of regenerative braking that the Wheel

Hub Motor uses at any given time is controlled by a potentiometer signal into the input of the Wheel Hub motor interface. Please see diagram in requirements sections for a detailed look at the motor interface.

3.1.6.1.1. The library entitled DigitalPotCounter.h contains functions that allow the MSP430 to interface with an AD5220 digital potentiometer. The file should be added to an existing Code Composer Studio project.

3.1.6.1.2. Initially, the library is set up to use P1_2 and the Clock line into the AD5220 and P1_4 as the up/down signal line, however these values can be changed by editing the library macros UD and CLK respectively.

3.1.6.1.3. The library contains 3 important functions: 3.1.6.1.3.1. initPot: sets up the GPIO pins that will be required to

interface with the AD5220 IC: the clock line and the up/down counter line.

3.1.6.1.3.2. incrementPot: Increments the potentiometer by 1 value. The potentiometer has 128 positions and the amount of resistance added by a single increment can be determined by taking the potentiometer’s value and dividing it by 128. The potentiometer used in the demo is a 10k potentiometer so each increment/decrement changes the potentiometer’s resistance by approximately 78 ohms.

12

3.1.6.1.3.3. decrementPot: Performs the opposite action of incrementPot, reducing the potentiometer’s resistance by 1 value (78 ohms in the example).

3.1.6.1.3.4. Please note: if the GPIO pins used are no longer on GPIO bank 1, then much more of the code needs to be changed, particularly all of the register bank references. Writing code such that this would not happen would have ended up using more of the MSP430’s limited resources, so hard coding was preferable. The final code will need to carefully map out all microcontroller pins to avoid conflicts.

3.1.6.2. ABS signal 3.1.6.2.1. As of the current standing, the ABS initiation signal is only a

logic high. The ABS system will require many different physical components that have not been finalized yet. Ultimately, we will need to send signals to the Accumulators, Master Cylinders and Bleed­Off valves to finely tune the ABS. These features cannot be fully fleshed out until the physical components are present.

3.1.6.3. Hall Effect Sensor: 3.1.6.3.1. The Hall Effect sensor converts changes in a magnetic field into

voltage. Here, it is used a means for reading the actual wheel speed of a given wheel. A tone ring is affixed to the axle of the wheel to be measured and as it spins, the teeth create changes in the magnetic field strength between it and the Hall Effect sensor. The sensor converts this into a voltage, and it is most easily seen as a frequency corresponding to the number of tone ring teeth that have passed the sensor in some discreet amount of time.

3.1.6.3.1.1. The library HallEffect.h is an interrupt­based interface for reading the raw output frequency of the Hall Effect sensor and converting the reading into revolutions­per­second, revolutions­per­minute, or miles­per­hour.

3.1.6.3.1.2. Usage: 3.1.6.3.1.2.1. Include the file HallEffect.h into an existing

Code Composer Studio project 3.1.6.3.1.2.2. Call the function initHallEffect 3.1.6.3.1.2.3. As the program runs, HallEffect.h will keep a

running tally of how many teeth have passed the sensor. Once every 1 second a timer interrupt will fire and convert the number of teeth that have passed in the last second to a revolutions­per­second value. This value will be stored as the global variable currentRPS and can

13

be accessed asynchronously by other parts of the code.

3.1.6.3.1.3. Demo: 3.1.6.3.1.3.1. To demo the usage of the Hall Effect library, we

have rigged the hall effect sensor up to a modified power wheels jeep (a children’s toy). The Hall Effect sensor tracks the current RPS of the rear axle, converts the value to miles per hour, and displays the result on a small 7­segment display. It essentially functions as an odometer, however the RPS value can be used for any purpose.

3.2. Hardware 3.2.1. Regenerative Braking System: The system itself is contained within the Wheel

Hub Motor. The interface between the MSP430 controller and the Wheel Hub Motor is via a linear potentiometer signal. See 3.1.7.1.1 for information on the library that interfaces with the Motor Hub. Please see section 4.1 for an explanation of the logic that decides whether regenerative braking should be enabled or disabled at any given point in time.

3.2.2. ABS System: The ABS system physically relies on components that are not yet

held by the Solari or ECS193 teams. A map of the system as it is currently planned can be seen in the initial requirements document at the end of this report. In our work, we attempted to integrate as many components as we could find or fabricate to simulate the logic of the final system. The ABS system primarily takes 3 inputs: wheelspeed for each wheel monitored, actual speed taken here by comparing all wheelspeeds, and requested brake force.

3.2.2.1. ABS Sensors: 3.2.2.1.1. Wheel speed via Hall Effect Sensor: A generic Hall Effect

sensor was procured by the mechanical engineering team and installed onto our test platform (the powerwheels jeep). The usage of the sensor is detailed in section 3.1.7.3.

3.2.2.1.2. Requested Brake Force: Ultimately, this will be provided via a potentiometer hooked up to the brake pedal of the Solari car. For our demo, we used a potentiometer on a breadboard.

3.2.2.2. ABS Actuators: 3.2.2.2.1. Fundamentally, ABS will be implemented by bleeding off

pressure from the hydraulic lines controlling the braking callipers in a controlled fashion, however the specifics of this need to wait until the actual car is constructed and the braking system can be modeled accurately.

14

3.2.2.2.2. Pressure Sensors: Our team was able to acquire a pressure sensor via the Mechanical Engineering team, however we had no test pressure lines and thus no way to map the values read from it to actual pressure values. As of now, our ADC read code works to capture a value from the pressure sensor, however the value is currently meaningless until more of the system is present.

3.2.3. CAN Controller Network: 3.2.3.1. The Microchip MCP2515 CAN Controller with a MCP2562 CAN

Transceiver has been used to communicate over the existing CAN bus. 3.2.3.2. Implementation for this system was done with a Microchip

dsPIC33EP32GP502 microprocessor. This processor is very powerful and should be capable of handling any task it is given. The learning curve is high, but rewarding. Look to the included CAN bus circuit diagram for a clear implementation of this processor. Following this guide will allow the end user to quickly implement full live debugging with a PICkit3 programmer.

15

4. Functionality 4.1. Regenerative Braking Enable/Disable

One of the regulations of many solar car competitions is that the regenerative braking functionality may be switched off completely at any point. For this purpose, the final solar car should have a mechanical switch deactivating the regenerative braking logic. It is to be noted that when the regenerative braking functionality is disabled the first few inches when pressing the brake pedal will have no effect on the car and no brake force will be requested. Only once the driver presses past the threshold and the mechanical brakes are activated the car starts to slow down. This will significantly affect the driving experience while driving the vehicle is still possible it will take some getting used to and the drivers should be trained accordingly. 4.2. Regenerative Braking Active/Inactive

The activation of the regenerative brakes is determined by the software which controls the regenerative brake signal, the same software controls the mechanical brake force.

4.2.1. Input

16

The input to the software comes solely from the brake pedal. A sensor at the brake pedal delivers the amount of requested brake force by the driver. Based on the given input a percentage of regenerative brake force is computed. The setup is done in such a way that the brake pedal first activates the regenerative brake force. When the driver first presses the brake pedal, no mechanical brakes are activated, solely regenerative brakes are active. A potentiometer at the brake pedal reads the linear input of the first few inches of the pedal. Once the driver presses the brake pedal past a physical threshold, the mechanical brakes are activated on top of the requested regenerative brake force.

4.2.2. Output and Computation The computation of the requested regenerative brake percentage is a linear

interpolation between a maximum brake pedal value, a minimum brake pedal value and a current value measured by the potentiometer at the pedal. Based on the input from the potentiometer a percentage is computed representing how much of the motor's regenerative brake force is required. An output of 0% means that no regenerative brake force is requested, the motor controller is thus not supposed to request any regenerative brake force. An output of 100% means that all the possible regenerative brake force is needed. The motor controller will request all the available regenerative brake force available.

We chose this abstraction in terms of percentage rather than Voltage or an analog output because it is easily transferable across different motors and different motor controllers. While analog signals such as voltage are easier to process by the motor controller, they are also hardware dependent and will change from model to model. Percentage, on the other hand, will need conversion to a signal that can be processed by the motor but it is representative of the amount of requested brake force on any hardware.

4.2.3. Variables to be set before usage The regenerative brake force being a linear interpolation, it requires some

calibration which is done by inputting a set of variables that the code relies on. The variables that are necessary for the correct computation of the regenerative brake force are documented below along with an explanation of each variable. The following variables can be found in main.c and they need to be manually set for each car depending on the hardware and on measurements. uint16_t noPedalPressValue = 0; This value represents the input from the brake pedal sensor when the brake pedal is not pressed at all by the driver. In our situation the input was voltage and the potentiometer gave a voltage of 0 when the driver was not pressing the brake pedal.

17

uint16_t allPedalPressValue = 4095; This value represents the input from the brake pedal sensor when the brake pedal is fully pressed by the driver. For our proof of concept, the maximal brake pedal value measured was 4095 volt, thus, we set the above variable to 4095. uint16_t regenCutoffValue = 800; This value is a cutoff value. It is important to note that: noPedalPressValue <= regenCutoffValue <= allPedalPressValue The purpose of this value is to create a threshold for the regenerative brakes to be the sole method of braking and the mechanical brakes being active. All measurements below the above variable will result in the mechanical brakes not being active while the regenerative brakes are activated. All values above the regenCutoffValue will result in both the regenerative brakes and the mechanical brakes being activated. uint16_t regenPercentageAtCutoff = 80; This value indicates what percentage of regen is requested at the cutoff value. The constraints on the above variable are: 0 <= regenPercentageAtCutoff <= 100 It may be desirable to the driver to not abruptly add mechanical brake force to 100% regenerative brake force. regenPercenageAtCutoff allows specifying a percentage lower than 100% at which the mechanical brakes are added on top of the regenerative brakes. The regenerative brake power continues to increase past the above cutoff when the brake pedal is pressed further by the driver until it reaches its full potential and the regenerative percentage is 100%.

4.3. ABS Enable/Disable Any solar car competition allows for Anti­lock Brake Systems (ABS) to be installed in

cars, however, rules are that any ABS system needs to be turned off for brake tests and in a case of emergencies. In order to comply with these regulations, any ABS system needs either a physical kill switch or a piece of logic implemented in software to disable the ABS system completely. This is to be implemented on any solar car. As a proof of concept, we implemented a simple ABS system which is always enabled. It is to be noted that our ABS system will not be active at low speeds, at low speeds there is no need for assisted braking and usually there is no risk of wheel slippage at reduced velocities. The cutoff speed value can be set in code, a more detailed explanation of all variables and all parameters related to the ABS code can be found in the following section.

18

4.4. ABS Active/Inactive Any solar car competition allows for Anti­lock Brake Systems (ABS) to be installed in cars, however, rules are that any ABS system needs to be turned off for brake tests and in a case of emergencies. In order to comply with these regulations, any ABS system needs either a physical kill switch or a piece of logic implemented in software to disable the ABS system completely. This is to be implemented on any solar car. As a proof of concept, we implemented a simple ABS system which is always enabled. It is to be noted that our ABS system will not be active at low speeds, at low speeds there is no need for assisted braking and usually there is no risk of wheel slippage at reduced velocities. The cutoff speed value can be set in code, a more detailed explanation of all variables and all parameters related to the ABS code can be found in the following section.

4.4.1. Input and Computation

The general idea of any ABS system is to compare two sensor inputs with each other to detect whether or not a wheel is slipping. In our case, we compare the speed sensor which is mounted on the motor controller and the Hall effect sensor which ideally would be mounted on each of the 4 wheels or, less ideally, on each of the wheel connected to the motor and thus more sensitive to acceleration and deceleration. In our proof of concept car, the ABS logic accepts two inputs, current speed from the motor in m/s. The motor controller is to be trusted, speeds are generally accurate and they are subject to very small deviations from the actual speed of the car. This is why the motor controller speed input is set as our reference point when detecting whether or not a wheel is slipping. In addition to the trustworthy speed sensor, the ABS logic accepts inputs from Hall Effect sensors at each wheel. Hall Effect sensors measure rotations per minute of a wheel. Finally, the last parameter to the ABS function is another function which is responsible for computing the wheel rotation cutoff at the current speed, more detail on this function can be found below, after an explanation of the general algorithm. The ABS algorithm transforms the current speed which is received from the motor controller into an ideal RPM value. The computed RPM value would be the desired speed of each wheel at the current speed. It is extremely rare that a wheel is rotating at the exact optimal RPM value due to various factors such as road conditions, friction, acceleration or deceleration or the wind. It is necessary to compute a cutoff value, a lower boundary RPM value for the current speed. The lower boundary value is lower than the ideal RPM value and if a wheel is rotating below this lower boundary value it is most certainly slipping. The cutoff value needs to be determined dynamically based on the current speed and it depends on the properties of the car.

19

Because computing a cutoff value is not trivial and dependent on the situation a design choice was made to pass a function pointer to the ABS logic. The function pointer allows users and engineers of future solar cars to adjust cutoff values based on their specific car. In our proof of concept car, a very simple function was used to compute the cutoff value. While this function demonstrated that the ABS kicks in extreme situations of wheels slipping, it is by far not ideal and needs tweaking.

4.4.2. Output and Computation

The output of the ABS system is straightforward. The algorithm outputs an integer value of 1 if no slipping was detected. This indicates that no action is required to adjust the currently applied brake force. If the ABS algorithm finds a wheel to be slipping the integer value 0 is outputted. It is up to a separate logic to handle the case where a wheel is slipping.

4.4.3. Variables to be set before usage As discussed in section 4.2.1 it is advantageous to not check for slipping wheels

at low speeds. The cutoff value beneath which the ABS will be deactivated needs to be set in a variable in main.c: float speedCutoff = 0.44; This variable is set to a speed cutoff in m/s.

4.5. MSP430F5529 ADC Library 4.5.1. This library contains three separate configurations for the ADC unit of the

MSP430F5529: Single Pin Single Conversion, Single Pin Repeat Conversion, and Multiple Channel Single Conversion.

4.5.2. The MSP430F5529 ADC module converts an analog signal to a scaled uint16_t value between 0 and 4095. The module requires inputs voltages to be between 0V and 3.3V. All voltages exceeding 3.3V will be reported back as 4095.

4.5.3. Single Pin Single Conversion setup 4.5.3.1. This configuration sets the MSP430 to perform a single ADC conversion

on pin 6.0. 4.5.3.2. Step one: Initialize with the ADCModuleInit() function. This will

initialize the ADC module on the MSP430. 4.5.3.3. Step two: Configure the input GPIO pins with

ADCSingleGPIOInputSetup(). This will configure pin 6.0 as the input pin for the ADC on the MSP430.

4.5.3.4. Step three: Setup the sampling timer with ADCSingleSampleTimerSetup(). This will configure the ADC’s sample and hold time. This determines how many ADC clock cycles the ADC will hold to read in an analog value.

20

4.5.3.5. Step four: Configure the memory buffer for the ADC using ADCSingleMemConfig(). This will setup memory buffer 0 to store the converted value of the ADC.

4.5.3.6. Step five: Enable ADC interrupts with ADCSingleInterruptEnable(). This will allow the ADC to gain control of the MSP430 and perform a conversion once the unit has been enabled.

4.5.3.7. Step six: Enable the ADC with ADCSingleConversionStart(). This will cause the ADC to trigger and interrupt and perform a conversion of the voltage signal read on pin 6.0. To perform another conversion re­enable the ADC with ADC12CTL0 |= ADC12ENC;.

4.5.4. Single Pin Repeat Conversion 4.5.4.1. This configuration sets the MSP430 to continuously convert the voltage

value of pin 6.1. 4.5.4.2. Step one: Initialize with the ADCModuleInit() function. This will

initialize the ADC module on the MSP430. 4.5.4.3. Step two: Configure pin 6.1 as input with

ADCSingleRepeatGPIOInputSetup(). 4.5.4.4. Step three: Configure the sampling timer using

ADCSingleRepeatSampleTimerSetup(). 4.5.4.5. Step four: Set up memory buffer 1 to store the converted value with

ADCSingleRepeatMemConfig(). 4.5.4.6. Step five: Enable interrupts using ADCSingleRepeatInterruptEnable(). 4.5.4.7. Step six: Begin the conversion process with

ADCSingleRepeatConversionStart(). 4.5.5. Multiple Pin Single Conversion

4.5.5.1. This configuration sets the MSP430 to perform a single conversion on pins 6.0, 6.1, and 6.2. The value of pin 6.0 is stored in the static variable brakeVal. The value of pin 6.1 is stored in the static variable speedSensor1. The value of pin 6.2 is stored in the static variable speedSensor2.

4.5.5.2. Step one: Configure the input pins and initialize the ADC module with ADCMultipleChannelSingleConversionInit().

4.5.5.3. Step two: Set up the sampling timer with ADCMultipleChannelSampleTimerSetup().

4.5.5.4. Step three: Configure memory buffer’s 0­2 for storing the converted values with ADCMultipleChannelMemConfig().

4.5.5.5. Step four: Perform a single conversion on each channel using ADCMultipleChannelConversion().

4.5.5.6. Step five: To retrieve the converted values, use the functions: ADCMultpileChannelGetBrakeValue(), ADCMultipleChannelGetSensorValue1(), and ADCMultipleChannelGetSensorValue2().

5. Demo Rig

21

5.1. Throughout our project we found ourselves needing to demonstrate and test our code with real, physical systems. Initially we built one­off test rigs out of Lasercut Acrylic & 3D printed components to demo each sensor’s functionality, however this soon became tiresome. We eventually settled on trying to acquire a golf cart to use as a test platform, however it proved to be too costly. As an alternative, we were able to modify a Barbie Power wheels jeep, a children’s toy, to function as a basic test platform. Though we were not able to implement the braking, we were able to implement the Hall Effect wheel speed sensor and a functional yet crude model of the accelerator & brake pedals.

6. TroubleShooting 6.1. Code Composer Studio

6.1.1. Unable to find “driverlib.h” 6.1.1.1. Solution: Install MSPWARE from the CCS app center.

6.1.2. Error initializing emulator: No USB FET was found 6.1.2.1. Solution: Check that the MSP430 usb cable is properly connected to both

the MSP430 and the computer running CCS. The MSP is “on” when LED 101 and 102 are on/flashing.

6.2. MCP2515 CAN Controller J1939 library 6.2.1. The library has only been tested using “polling” 6.2.2. The next step is to configure library to use interrupts, which will improve overall

performance. 6.2.3. There is a lot of comments in library code, but the topic is still very confusing. In

depth study of the subject is required. 6.3. Jeep Integration Demo Program

6.3.1. The ADC is only reporting conversion values around 1500 no matter what the potentiometer is set to.

6.3.1.1. Solution: First ensure that the potentiometer is properly wired up. Next, stop the current debug session in CCS and unplug the MSP430. Wait approximately 10 seconds and reconnect the USB cable. Retry running the debug mode. If the problem still persists, right click the project in the project explorer and select “clean project”. Rebuild the program and run the debug mode again.

7. Frequently Asked Questions

7.1. Where is the Solar Car? 7.1.1. The Solar Car itself is still in the design phase. As such, much of the hardware

required for actually implementing this project does not yet exist. 7.2. Why are so many of the library constants and pin values hardcoded, wouldn’t it be more

usable if there were configuration functions? 7.2.1. The microcontrollers we are using have limited memory and resources. Many of

the final constants, pin numbers and values won’t be determined until the entire car is constructed, however once the car is on the road very few code changes will be possible. Because of this, we have hardcoded as many values and constants as possible.

22

8. Contact Information 8.1. UC Davis Solarri Team

8.1.1. solarri.ucdavis@gmail.com 8.2. Nile Mittow

8.2.1. Alternative Fabrication Specialist 8.2.2. Sensor integrator 8.2.3. namittow@ucdavis.edu

8.3. Sebastian Bloem 8.3.1. MCP2515 CAN Controller circuit 8.3.2. svbloem@ucdavis.edu

8.4. Francois Demoullin 8.4.1. Software engineer 8.4.2. fdemoullin@ucdavis.edu

8.5. Chris Ellis 8.5.1. MSP430 Analog­to­Digital (ADC) System Designer 8.5.2. Chellis@ucdavis.edu

9. Appendix 9.1. Requirements Document

UC Davis Solar Car:

ABS & Regenerative Braking System

Requirements Document

Team Members:

Sebastian Bloem

Christopher Ellis

Francois Demoullin

Nile Mittow

Revision History:

1/25/16 ­ Document Creation ­ Nile Mittow

1/29/16 ­ Draft of intro added ­ Chris Ellis

1/30/16 ­ Intro draft updated, Microcontroller section, and related terms ­ Chris Ellis

1/30/16 ­ Added decision flowchart and description; added brake caliper sensor information ­

Francois Demoullin

23

1/30/16 ­ Revised high­level block diagram and explanation added; formatting modified; Intro to

Requirements and Responsibilities section added ­ Nile Mittow

2/6/16 Milestone Document creation ­ Sebastian Bloem

2/17/16 ­ Appended Milestone Document to Initial Requirements Document, as per email

from TA Albara (2/17/16 8:23 PM) ­ Sebastian Bloem

2/17/16 ­ Added updated high­level block diagram ­ Nile Mittow

2/20/16 ­ Added repository information ­ Chris Ellis

3/12/16 ­ Updated microcontroller information and added simulation section ­ Chris Ellis

5/31/16 ­ Added Power Wheels Jeep section. ­Chris Ellis

5/31/16 ­ Updated microcontroller section about floating point feature, msp430 ­ Chris Ellis

Intro:

For this project, we will develop a regenerative braking system with integrated ABS for a solar

vehicle which will compete in the American Solar Challenge and Formula Sun Grand Prix. Regenerative

braking is a technique which attempts to recapture some of the energy that is normally lost as heat

through regular mechanical braking as electricity. This recaptured energy is then given back to the battery

to recharge it, which extends the amount of time the solar vehicle is able to operate before needing to be

fully recharged. However, because the amount of braking force that can be provided through regenerative

braking is limited (and will eventually consume more energy than it recovers), it will be necessary for the

system to be able to transition smoothly between the regenerative braking system and the mechanical

brakes. Most importantly, the system must guarantee that the driver will always receive the total brake

force they are requesting, regardless of which combination of the two braking systems is currently being

used.

Our team is working with a mechanical engineering senior design team to design and implement

the system. We are responsible for implementing and developing the hardware and software required for

the control system of the regenerative braking system. Because the solar vehicle will be used to compete,

we will also have to adhere to the specific rules and regulations for each event. For example, all of the

24

energy that the system uses must be provided by the electric motor, electric battery and solar panels in the

vehicle. To implement this system, we will be using a microcontroller. This microcontroller will take in

signals such as the current brake pressure, the current charge level of the battery, the amount of requested

braking force, the amount of energy being recaptured, etc and use these signals to determine how much

regenerative braking should be used and then output these necessary control signals to the electric motor

and mechanical braking system.

In terms of development models, our team is using a waterfall model. This is due to the fact that

there are some uncertainties in our project, such as the specifics of certain key pieces of hardware that will

interact with our system. This model will allow us to verify that each decision we make will work with

the decisions that have been made by the other parties involved in the entire development of the solar

vehicle. To manage our workflow, we have decided to use the scrum software Axosoft. This enables us to

easily organize all each team member’s current responsibilities, their current progress, and keep track of

our estimated time needed to complete the current tasks. Additionally, we are relying heavily on weekly

meetings, google drive, and constant communication with the mechanical engineering team.

25

Glossary Terms:

Pulse­width modulation (PWM) – A modulation technique used to encode a message into a pulsing

signal.

Microcontroller (MCU) – A small computer on an integrated circuit that contains a processor, memory,

and programmable input/output peripherals.

Analog­to­digital convert (ADC) – A device that converts a continuous physical quantity (usually

voltage) to a digital number that represents that quantities amplitude.

Anti­lock braking system (ABS) – an automotive safety system that allows the wheels on a vehicle to

maintain active tractive contact with the road surface according to the driver input while braking,

preventing the wheels from locking up and avoiding uncontrolled skidding.

Controller area network (CAN bus) – A vehicle bus standard design to allow microcontrollers and

devices to communicate with each other in applications without a host computer.

Bluetooth low energy (BLE) – a wireless technology intended to provide considerably reduced power

consumption and cost while maintaining similar communication range.

Code Composer Studio (CCS) – An IDE used to develop applications for Texas Instruments embedded

processors.

Integrated Circuit (IC) – A small electronic component built to perform some specific task ­ anything

from an Op­Amp to a single NAND gate to a full­fledged MCU.

Electronic Control Unit (ECU) – Term commonly used in the automotive industry to refer to an

automobile’s main onboard computer, usually a purpose­built MCU.

Serial Peripheral Interface (SPI) – A serial data communication protocol implementing the synchronous

transmission of data in embedded systems.

Inter­IC (I2C) – A bi­directional serial communication protocol which allows multiple devices to be

connected to a single bus by assigning a unique (to the bus) address to each device.

26

Potentiometer (Pot) – A variable resistor often used as a control knob.

Caliper (brake) – A common method of braking which utilizes two pads to compress a disc attached to

the automobile’s wheel.

Torque – Angular rotation of the motor. Torque is an easy way to compute the power produced by the

motor and the force needed to brake.

Brake Chamber – Pressing the brake pedal fills a chamber with compressed air, causing the

diaphragm to move and push out the pushrod to apply the brakes. The pressure in the brake

chamber can be measured to gain information about the brake force.

ME Team – Used occasionally throughout this document to refer to the mechanical engineering team

working on the project. They are our clients, essentially.

ECS Team – Used occasionally throughout this document to refer to the computer science & engineering

team (ourselves).

27

High­Level System Block Diagram:

As stated above, this is a high­level block diagram of the physical system, touching on some of

the components that are to be implemented by the ME and EE teams. While the MCU that the ECS team

is in charge of (labeled MCU in the above block diagram) is likely going to function as the main ECU, the

motor and power systems will have their own control units either as separate MCUs or off­the­shelf

solutions. Additionally, there is a dedicated data acquisition team that may be implementing their own

data logging solution to function in tandem with out MCU.

In the above diagram, there is a fair amount of data coming back from the calipers into the MCU.

The caliper system itself, including what sensors are to be attached to the wheel, have yet to be decided or

implemented, thus the diagram simplifies the unit by simply labelling it as coming from the calipers. In

reality, it may be two to 3 independent sensors.

As we’ve moved through this project, we realized that a more robust communication system

28

would be required, and thus have shifted from having one main central controller, to having a smaller

MCU located at each sensor position. These sensors would now communicate with each other via the

CAN interface system. Can is more robust, more immune to faults, has much better error

detection/correction, and is widely used in the automotive industry. Additionally, it simplifies our bus

arbitration issues by having an arbitration system built into the communications protocol already.

In trade for this more robust behavior however, we gain a more complicated protocol to

implement. This will manifest itself as more code that needs to be written, but we’ve deemed this to be

worth it and beneficial in the long run.

Currently, we have acquired some CAN interface chips and are working on getting them talking

in a small network. In addition to this, we have procured some smaller MCUs (PIC MCU,s MSP430s)

which will function as the small local controllers to handle the interactions between the local CAN

controllers and the sensors themselves.

29

High­level System Behavior / Algorithm

The above flow diagram is a high­level abstraction of how our code on the microcontroller should

execute. In the diagram, we are purposely neglecting any constraints on signal format and signal input.

30

We simply assume speed is an input from the motor controller and brake pedal force is a direct input from

the brake pedal. These two inputs are enough for the regenerative braking computations.

Similarly, we neglect any mechanical constraints on the output, we assume the output is simply a

brake force which will be applied by the mechanical brakes as well as a separate brake force which will

be applied by the regenerative brake system. Starting at the given signals for brake force and speed our

microcontroller first needs to check whether or not to apply the brakes. If the brakes need to be applied a

computation estimates whether the regenerative braking system needs to be activated. Regenerative

braking cannot be used if the battery is fully charged, furthermore, at low speeds and at low brake forces

it is wise not to use regenerative brakes. At low speeds, regenerative braking only generates small charges

and regenerative braking usually feels different than mechanical braking which has significant effects on

the controllability of the car.

Ideally, we come up with an algorithm that computes the correct distribution of regenerative

brake force and mechanical brake force in order to keep the car drivable but yet as energy efficient as

possible.

Requirements & Responsibilities:

As we are only a small part of a larger team working on the entire solar car project, the scope of

our responsibilities is tied to those elements which need to interface directly with our microcontroller, and

the actual implementation of many of the components we will be interfacing with are ultimately decided

by those on the ME team. Our job is to work closely with the ME team and be prepared to implement a

wide variety of the different possible control signals that may be used later down the line. As such, we

are actively learning and making ourselves familiar with as many control and data communication

protocols as necessary, which included finding miscellaneous components to test out when possible.

Simulator

31

One of the main hurdles with this project is that the solar car that will be used in the competition

has not yet been built. This means that there is no physical vehicle that we can use to test the functionality

of our system with. Unfortunately, in order to test the functionality of our system, we must have the

external signals produced by the other components of the vehicle. In addition to this, all of the

components that will be used by the solar car have not been decided upon, which makes designing the

system difficult. In order to alleviate this design hurdle, we have decided to build a signal simulator that

will produce the expected signals we are expecting to receive from the other components in the solar car

based on the information provided to us by the mechanical team. One added benefit to creating this

simulator is that it will give us the flexibility to update the details of the signals it produces as components

for the solar vehicle are chosen. This will allow us to move forward with designing the regenerative

braking system and anti­lock brake systems without having the actual components of the vehicle on hand.

To create the simulator, we are currently utilizing a Raspberry Pi model B, a Texas Instrument

CC3200 microcontroller, a small DC motor, and a rotary encoder. Furthermore, we are utilizing a solar

vehicle performance simulation program provided to us by Dr. Nitta. This software produces a wide

variety of output data based on the power of the electric motor, the weight and material of the vehicle, and

other physical parameters. For our purposes, we are utilizing the current miles­per­hour (Mph) relative to

the current time throughout the simulation. In the actual solar vehicle system, we are expecting to receive

either the current rotations­per­second (Rpm) or Mph as one of our input signals. Using the Mph being

produced by the simulation software, we are controlling the speed of the DC motor through the Raspberry

Pi in real­time. Using the rotary encoder connected to the CC3200 we are able to read the current speed of

the motor and detect whether there is acceleration or deceleration occurring. Using the calculations on

braking force our group has calculated, we are then able to determine the amount of braking force that is

needed to be applied in order to change the speed of the motor. This braking force calculation will be

essential for us to determine how much regenerative and mechanical braking we will need the system to

32

produce in response to the driver pressing the brakes on the actual solar vehicle. A video of this system in

action can be seen here:

https://drive.google.com/a/ucdavis.edu/folderview?id=0BxtTn1sGEoXiSmh5LUZQV05qSzQ&usp=shari

ng

Proof of Implementation ­ Barbie Jeep

While the simulator provided a convenient starting platform to develop both the ABS and

regenerative braking systems on, our team decided that we wanted a more realistic platform to

demonstrate the systems on. Because of this, the team invested in a power wheels jeep in order to have an

actual vehicle platform to prototype the system on. The jeep was remodeled to be closer to an actual

electric vehicle to allows us to present the system operating in a far more realistic environment then the

simulator could allow. Additionally, because the ME team had begun purchasing some hardware samples

of components they were considering using, when possible, these components were either integrated on to

the jeep or verified to be compatible with the system through small scale testing.

One example of this was a Hall effect sensor that is planned to be used to capture the rotation per

minutes of the solar vehicle wheels in the ABS system. The ME team gave us a single sensor that we will

implement onto the jeep to show that system is able to read the sensor values and convert them into a

useable format for our ABS code. With the use of part of an old egg beater to function as a tone ring, we

were able to demonstrate capture of wheel speed and conversion to Miles Per Hour by using our Hall

Effect sensor library to parse the frequency output from the hall effect sensor into actual wheel speed.

The ME team also provided us with a sample of the pressure sensor that they wish to use with

their brake system. This sensor was tested with the MSP430 ADC module of the system on a small scale

to verify that the ADC was compatible with the output of the sensor. While we were able to simulate

33

pressure values by blowing into the sensor, because it is a high pressure sensor and we had no high

pressure system we could only verify that we were able to capture a signal. We were not able to interpret

the signal as a particular pressure.

Additionally, we were able to model the potentiometer based pedal system that will eventually

serve as the accelerator, and part of the brake pedal for controlling regenerative braking. The pedal is

functional and drives the jeep.

Microcontroller

The heart of our control system will be a microcontroller that will be programmed to output the

necessary control signals to the brakes, dumper, and motor based on the incoming signals from the rest of

the vehicle. For our design, we have chosen to use a TI Hercules microcontroller as our main

microcontroller. The reason we chose to use the Hercules microcontroller is because the Hercules family

of microcontrollers are designed for safety­critical transportation applications, such as our project. The

reason the Hercules boards are ideal for safety­critical applications is because they utilize multiple

processor operating in lockstep in order to detect when errors occur. This allows the Hercules to run our

code separately on both processors and compare the outputs produced by both processors. If they outputs

are ever detected to in disagreement, we are able to design the system to safely respond to a possible

failure. Furthermore, the Hercules also comes with built­in self­test hardware, a memory protection unit,

and parity checking. These features will be critical in ensuring that the driver of the vehicle is never in

any danger due to any unforeseeable problems with the system.

On top of its numerous safety features, the Hercules also has much of the necessary hardware our

system will need. It supports both pulse­width modulation (PWM) and analog­to­digital conversion

(ADC). This will allow the Hercules to accept both analog and digital signals as well as generate them.

Furthermore, because our system will be utilizing a controller area network bus (CAN bus), the Hercules

34

is also ideal because it comes with multiple CAN modules. This will allow the Hercules to be connected

to the main CAN bus and monitor all data being sent between the components in the system. Finally, the

Hercules supports floating point operations, which will be an essential feature for both the regenerative

braking and ABS calculations. When the actual solar vehicle is built, the Hercules will provide the ideal

microcontroller platform for the solar car team to implement our systems with.

For the ADC component of the system, a low power MSP430 microcontroller was selected to

perform the analog to digital conversions. This component provides the ME team with additional

flexibility in their hardware choices because they no do not need to focus on purely digital sensors, which

are often much more expensive and complicated to set up, when choosing the final hardware that will be

used in the solar vehicle. The advantage to the MSP430 is that it is a cheap component that offers

excellent low power consumption through its multiple low power modes. As electrical efficiency is

critical to the overall operational performance of the solar vehicle, it is an ideal piece choice to use with

the final solar vehicle that the team will build later this year.

Control & Data Lines

As previously stated because many of the physical components of our design, and thus the

specific controllers to be implemented, are still being decided upon by the ME team, we do not know for

certain exactly what types of control signals will be used to interface with the other sensors and control

systems on the solar vehicle.

Regenerative Braking Control Signal ­ Output:

According the the motor controller specification that we have to work with, regenerative braking

is implemented in the motor controller device and controlled via a potentiometer. Because of this, we will

need to use a digital potentiometer to allow this signal to be controlled from our MCU. We have already

spec'd out a couple options and received samples to begin testing with, namely the

35

TPL0501­100DCNR­256 and TPL0102­100PWR­256 which are SPI and I2C controlled digital

potentiometer ICs made by TI.

Measuring brake force

As of right now, we have been analyzing torque blending with serial regenerative braking. This

means that at every brake process the brake force is distributed between the regenerative braking system

and the mechanical brakes. We blend both braking systems in order to maintain a constant brake feeling

for the driver. Generally, the regenerative braking force cannot be made large enough to provide all the

required braking force of the vehicle. In addition, the regenerative braking system may not be used in

situations where the battery is at a high level of charge, or where the battery is at risk of overheating.

The mechanical braking force is determined by the air pressure in the brake chamber, so the

mechanical braking force can be controlled by the duty valves that the Mechanical Engineering team is

adding to the system. There is a very smaller uncertainty in driving or braking torque generated by an

electrical motor. The torque force can be known from the motor controller by simply measuring the

change in speed. Therefore, a simple ’driving force observer’ can be designed and we can easily estimate

the driving and braking force between tire and road surface in real time. The regenerative braking force is

calculated by comparing the demanded brake torque and the motor torque available.

Brake Force Computation

The mechanical Engineering team shared their preliminary report about computing Brake Force

for the solar car. From their report, the following equations were used to compute the brake force on both

the rear axle and the front axle according to the weight distribution of the car. Considering that the exact

weight distribution is unknown right now, we resort to passing a preliminary weight distribution as a

parameter, which, once the actual car has been built, can be adjusted accordingly. The implemented

formula can be found on Github in the “Brake.py” module.

36

Static axle load distribution (optimum straight line braking):

W = vehicle weight Dynamic brake force

, static = static rear axle loadF zR

a = vehicle deceleration

L = wheelbase

h = CG height

χ = h/L

ψ = , static /WF zR

Following this, the force in the x direction of the front and the rear axle can be computed using:

= (1 − ψ + χa) * aW F xF

= (ψ − χa) * aW F xR

Finally brake torque can be deduced from the motor torque:

= effective radius of the rotor (measured from rotor center of rotation to center of pressure of caliperRef f

pistons)

= torque generated by rotorT r

F friction = Rolling resistance between wheel and road

= F friction * T r Ref f

Prototyping Code:

We will be using Github as the main repository for our code. It will be used to provide private version

control to the solar car microcontroller control system as well as our simulator code.

The repository can be seen at:

https://github.com/CEllis18/ECS193AB­­­Solar­Car

37

Appendices:

Appendix I: External Resources:

Axosoft ­ The project management site we are using, can be found at ucdavis.axosoft.com. All pertinent

project members and client have been added and should have received an invitation email.

Google Drive ­ Our current goto location for storing spec sheets, flowcharts and documents. All spec

sheets refrenced in this equirements document can be found there, including all the data we have on the

motor, motor controller, batteries, and solar panels:

https://drive.google.com/open?id=0B5s7cmi1vrM2dzQ4MXBJaVJwSnM

Flowchart ­ The flowchart diagram is based on the example found at:

http://www.mate.tue.nl/mate/pdfs/12673.pdf

Texas Instruments ­ The microcontroller manufacturers site detailing features of their Microcontrollers

http://www.ti.com/lsds/ti/microcontrollers_16­bit_32­bit/products.page

Preliminary Report by the Mechanical Engineering team ­ The detail of all the physics computations

related to the solar car brakes