AUTOMATIC SHIFT MANUAL TRANSMISSION Written By

HYBRID ELECTRIC VEHICLE ENTERPRISE TECHNICAL REPORT

AU T OM ATI C S H I F T M A NUA L T R A N SM I S SIO N APRIL 24, 2015

Written By: Dylan Bingle James Hingst Cameron Smith Will Tuttle

~ ABSTRACT ~ The core objective of this project is to take the T5 Tremec manual transmission from the current HEV project vehicle and develop a system that will make it function as an automatic transmission. The methods used to create such a system include: a designated communication protocol and control unit hardware, small but appropriate motors for performing the transmission shift movements, a control model for receiving commands from the vehicle and orchestrating the motors. Through experimentation, the first control unit (a MotoTron ECU) was deemed overly complicated to develop a program for due to the fact the ECU was repurposed and not designed for what the team had intended. This ECU was replaced by an easy-to-program Arduino device. The control system is built to the point of integrating control of the three necessary motors for shifting and currently being developed to allow control of these motors over the CAN bus.

TA B L E O F C O N T E N T S

EXECUTIVE SUMMARY ..................................................................................................................... 3 INTRODUCTION ................................................................................................................................. 3 TECH NICAL APPROACH ................................................................................................................... 7 CONCLUSIONS ................................................................................................................................... 15 REFERENCES ..................................................................................................................................... 15 APPENDIX ........................................................................................................................................... 15

2

AU T O M A T I C S H I F T M A N UA L TRANSMISSION E X E C U T I V E S U M M A RY

The main objective of this project is to automate a Tremec T5 Manual transmission. This involves first identifying tools needed to replace the movement traditionally done by the driver, then identifying a way to link and control those tools to complete the shifting, and finally incorporate the transmission into the vehicle. Motor selection was completed by the previous senior design team and considered out of scope for this project. However, these tools should be revalidated to ensure shifting reliability. This report details the process of choosing and testing hardware to control the motors, how a control system was developed, and finally discusses the communication protocol to receive gear change requests and send confirmation signals. In the system’s current state, an Arduino Mega2560 is being used as a hardware control platform. Fully integrated control of the three motors being used – one for the clutch, two for gear shifts – has also been achieved. While motor control works, the team has just recently got CAN communication working. Desired CAN message IDs and data bytes must be determined to implement into the control scheme. One problem is a mechanical issue with the transmission and that shifting is limited to only a select number of gears, even when the shift is attempted by hand. I N T RO D U C T I O N

The Tremec T5 transmission, as shown below in Figure 1, is a 5 speed manual transmission that was chosen as the transmission for the 1949 Chevrolet Pickup Hybrid Electric Vehicle project vehicle. The core goal, as described above, was to fully automate the transmission so that the shifting would be done by the vehicle supervisory controller.

Figure 1. Tremec T5 Transmission This supervisory controller would be developed by another team who would send requests signals to the transmission controller for actions such as clutch actuation and gear changes. In a traditional manual vehicle, a shifting lever is used to move the transmission between gears. The Tremec T5 transmission has a shifting pattern of a typical 5-speed gearbox and is seen in Figure 2 below.

3

Figure 2. 5-Speed Shift Pattern The autoshift mechanism is designed to shift through the gears without the driving having to manually change the gear position. To accomplish this goal, tools were selected to mimic this shifting motion done by the vehicle driver. A controller was selected to control the shifting process. A Motion Systems 12V linear actuator was chosen to control the linear shifting done by the driver; the forward and backward motion. A 3.3 V stepper motor was chosen to control the shaft angle, as done by the left and right motion from the driver. Together, the actuator and stepper motor can provide the range of motion to move through all the gears on the transmission. These components are shown below in Figure 3.

Figure 3. Tools: Linear Actuator and Stepper Motor (Left to Right) It was identified that a subsystem controller would be required to operate the shifting process of the transmission. This controller would then communicate with the supervisory controller on the vehicle by CAN network. A MotoTron ECU was selected by a previous team on this project. The senior design team this semester constructed a controls strategy and implemented the MotoTron unit so that control over the linear actuator and stepper motor was established. Before calibration work could be started on the using the MotoTron, the transmission was disassembled so that a new input shaft could be machined. Due to the uncertainty of time frame when the transmission would be fully functional, the team outlined a parallel path in order to continue forward progress. Through work on the MotoTron ECU, it was discovered that the MotoTron software and system as a whole were bulky and difficult to use. There was a large amount of wires that were left unused and the process of running the generated code from MATLAB into the MotoTron software was complicated and difficult to troubleshoot. While the MotoTron unit was functional, the team decided that there better control options available. An Arduino controller was chosen to replace the MotoTron controller. The new setup was much smaller and less complex, which made operating and troubleshooting much simpler.

4

Figure 4. Old Control Hardware Setup

Figure 5. New Control Hardware Setup Control over the individual tools was first achieved using the MotoTron unit and its associated Simulink model. This made the transition over to the Arduino a very simple process. As the MotoTron unit offers a functional control option and the team was successful using it, this report will also include the progress with the MotoTron unit. This document will discuss construction and implementation of the transmission shifting sequence by both the MotoTron unit and Arduino controller. A series of steps were outlined, also shown in Appendix A, to reach the final goal of incorporating the transmission into the vehicle. These steps start by taking the tools outlined previously and confirming their selection, then establishing communication, developing the overall strategy, mounting the tools on the transmission, calibrating and eventually refining in the project vehicle. A complete series of steps and brief outline is described below. Review Control System Options In the initial phase of this project it was essential to determine that the team had the appropriate controls hardware and software that would be necessary for supporting the controls model

5

development. The team approached this by coming up with a couple of options and conducting a basic analysis of the advantages and disadvantages of each option. This resulted in a confirmation that the team would be able to utilize the hardware and software already available using the MotoTron ECU hardware and Simulink software. However later, while the team waited on the transmission input shaft to be machined, it was determined a better controller option was available. An Arduino controller was implemented which resulted in a much simpler design. Establish Communication with the Control Module The Mototron ECU does not have a direct USB communication protocol and software link to Simulink. There are specific hardware and software conditions that need to be met in order to establish communication between the MotoTron ECU and a computer. This connection is necessary in order to flash the controls model onto the ECU. This task was accomplished by implementing the correct hardware and software configurations along with a fair share of troubleshooting. Using the Arduino setup, a cable is plugged directly from the Arduino into the computer. Using various shields that are plugged directly into the Arduino main unit, the computer can communicate with the Arduino controller and the motors that are connected to it. The Arduino setup was much easier to use, in terms of programming functions, than the MotoTron setup. Establish Communication from Control Module to Tools In order to instruct the motors in the shift system they must be controlled using the transmission controller. This means using a controls model to control the physical signal output on the controller pins. This was accomplished by forcing certain signal characteristics on specific controller pins and observing the output using an oscilloscope or by the motor’s reaction. For this step, separate controls models were written to control one motor at a time. While the linear actuator was directly controlled by the controller, the stepper motor required an external driver chip. After each control model was tested and proved to be functioning properly, the models were combined and the motors were able to operate simultaneously. The MotoTron control used specific ECU pins and internal H-bridges to drive the motors. Controls for the MotoTron unit were built using Simulink. The Arduino controller used two motor driver shields to operate the transmission tools. The Arduino code was wrote using C code in the Arduino IDE developer software. Establish Tool Feedback to Controller and Calibrate Certain parts of the controls model required feedback from the physical world back to the model. The transmission controller required position feedback in order to shift the transmission through the correct gears. Two potentiometers were used; one built into the linear actuator, the other attached externally to the stepper motor rotor. The resistance change of the potentiometer was measured using pins on the controller. Established tool feedback allowed the motors to be moved to specific positions. Mount and Calibrate Tools on Transmission A working/calibrated set of motors worked well sitting on the test bench. However, to be any use, they needed to be attached to the transmission. This step involved the calibration and troubleshooting of the transmission tools. The linear actuator and stepper motor were mounted on the transmission. Integration of Transmission Tools in Overall Strategy Until this point the stepper motor and linear actuator have been controlled by separate controls models. Now they must be integrated into one and lead by an overall controls strategy that can receive and interpret commands from the vehicle and appropriately command each submodel to accomplish the desired shift. This step has not been approached yet.

6

Calibration of Transmission Tools Once the tools are operating within the same control mode, the stepper motor and linear actuator must perform a fast and error free shift. This will involve extensive calibration within the new overall controls model as well as within the submodels. This step has not been approached yet. Integration and Calibration of Clutch Tool The transmission control strategy will not time the clutch activation. This will be done from the vehicle supervisory controller. The Arduino will power the clutch actuator, however it will only do so when commanded by the supervisory controller. This step requires establishing control over the clutch actuator, then simply relaying a message from the supervisory controller. This step has not been approached yet. Finalize Control Strategy Time must be taken to carefully check any and all cases in which the system will need special calibration or controls strategies. There should be no loose ends before putting this system in the vehicle. Think of how vehicle driving loads will affect performance. This step has not been approached yet. Implement into Vehicle The ultimate goal of this project is to implement the system into an actual vehicle to be driven. This step will be both the most exciting and most likely the most troublesome. There will likely be issues we run into that cannot simply be fixed by calibration. Hopefully at this point we have avoided the most critical ones and can troubleshoot appropriately. T E C H N I C A L A P P R OA C H

Initial Project Status The stepper motor and linear actuator were inherited from the previous transmission team for this project. As a control option, a MotoTron Electronic Control Module was obtained for this project. Along with the MotoTron module, the interface software and Simulink library were also inherited. First, the team assessed the current status of the project. It was determined that both motors would provide the functionality necessary to move the transmission through the shifting process. Although the MotoTron ECU appeared to be overkill for the project, it would provide the necessary functionality in terms of speed and power. The controls model could be developed in Simulink. The advantage of this system was that the MotoTune software could be used for real time calibration and troubleshooting. The MotoTron ECU is shown below in Figure 6.

7

Figure 6. MotoTron ECU The model for the MotoTron unit was created in Simulink using MATLAB. Once built it was opened in MotoHawk, a program used by the MotoTron ECU. MotoHawk established a communication with the ECU using the serial port on the computer. The ECU was flashed, cleared of any previous programing, in preparation for it to receive new programing. Using the MotoHawk software, various tools, such as calibration and display blocks, could be implemented to troubleshoot and test the circuit and equipment. Calibration blocks could be created to input values into the program that were previously defined as calibration variables. Display blocks could be used to measure the real time values from the system.

First Steps MotoControls Once it was determined to move forward with the current components, development of the Simulink model progressed. The MotoHawk Simulink library allowed individual control of the pins on the MotoTron ECU. A large variety of pins were available on the MotoTron for different functions such as digital outs, analog ins, and PWM signals. Based on function type, pins on the MotoTron were chosen for controlling the two motors that would be mounted on the transmission. Linear Actuator H-bridge 2 was set aside for controlling the linear actuator, shown in Figure 7 below. The H-bridge produced a PWM signal to the motor. By changing the duty cycle and frequency of the signal, the speed of the actuator could be adjusted. Negative duty cycle was used to move the linear actuator in and a positive duty cycle to move the linear actuator out. In the control module, a feedback loop was established using the potentiometer built into the linear actuator. The error between the requested position and feedback position was then used to move the actuator in the correct direction at the correct speed. The potentiometer feedback was read using analog pins CD-4, B-D3, and C-F1.

8

Figure 7. Linear Actuator Stepper Motor The approach for operating the stepper motor is somewhat different to the operation of the linear actuator. Instead of running the motor directly off from the ECU (as was done in the case of the linear actuator) a motor driver chip was required to provide input for the stepper motor. The motor driver chip was required to control the two coils in the stepper motor. A wiring diagram of the stepper motor chip is shown below in Figure 8.

Figure 8. Pololu md20b Motor Driver Chip The motor driver chip used is the Pololu md20b. There are several inputs and outputs on this chip. The main ones used are the voltage input, step input, step size inputs, direction, enable, and motor outputs. The voltage input for the chip requires a 12V DC input and ground in order to run the stepper motor. 3.3V is used to signal a logic high. The step input is a 3.3V square wave that will determine the speed of the motor. The direction pin, when high, turns the motor clockwise. Low turns the motor counter-clockwise. The enable pin, when triggered high, will disable the stepper motor chip. The step size inputs, M0, M1, and M2, are binary inputs that determine the step size of the motor, in degrees. If the step size is larger, the rotation of one step will be larger, and if the step size is smaller, the rotation becomes smaller. There is a benefit of using a smaller step size because it increases the resolution of the stepper motor and allows a more exact position to be achieved. If a small angle is not needed, the step size can be increased to increase the speed and decrease the complexity of the system. A full range of possible step sizes is shown in Table 1. Table 1 Step Size Inputs on the md20b Motor Driver Chip Steps Per Pulse M0 M1 1 0 0 1/2 0 0 1/4 0 1 1/8 0 1 1/16 1 0

9

M2 0 1 0 1 0

1/32 1/32 1/32

1 1 1

0 1 1

1 0 1

The chip required a large number of control signals to operate correctly. Most of these signals were digital inputs: direction, enable, step size, sleep and reset. All of these signals were supplied using the EST pins on the MotoTron. These pins supplied a logic 3.3V output when activated. The step input on the chip proved more troublesome as it required a PWM wave input. H-bridge 1 was used to supply the PWM input for this chip. However, the PWM input on the MotoTron was designed to output a 12V signal. A voltage divider was implemented in order to step the voltage down to the 3.3V logic signal the chip needed. The voltage divider used a 470k resistor and a 200k resistor. The PWM signal was attached to the 470k side and the ground to the 200k side. The complete list of used signal wires on the ECU for the driver chip is shown below in Table 2. Table 2 MotoTron ECU Pins for Stepper Motor Pin Datasheet Required For A-A4 EST1 Logic High/Low for direction A-A3 EST2 Logic High/Low for enable pin A-A2 EST3 Logic High/Low for reset pin A-A1 EST4 Logic High/Low for sleep pin A-B4 EST5 Logic High/Low for resolution A-B3 EST6 Logic High/Low for resolution A-B2 EST7 Logic High/Low for resolution C-H4 H-Bridge Driver Chip PWM Input The stepper motor did not have a feedback sensor built in. The control strategy required a feedback for the stepper motor position. Two options considered for this purpose were a hall effect sensor and a potentiometer. A hall effect sensor would essentially create a home position on the motor. It will signal when the motor has reached its position. While this option is simple, it will not have the as high of accuracy as the potentiometer. The potentiometer would return a resistance value to the controller, which would then be converted to an angular position. A Bourns 10k precision potentiometer was identified for this need. This potentiometer manufacturer part number was 6539S-1-103. Servo mount allowed the potentiometer to be mounted to the end of the gear so that it shared the same shaft as the stepper motor. This sensor is also continuous, meaning that it could spin infinitely without stopping. As before with the linear actuator potentiometer, the stepper motor potentiometer was monitored using an analog input on the MotoTron: pins C-E4, A-D4, and C-E2. The complete datasheet is included in Appendix A. The potentiometer mounted on the assembly is shown in Figure 9 below.

10

Figure 9. Potentiometer Mounted On Housing While the stepper motor and potentiometer worked separately, neither would operate when connected together using the same shaft. Monitoring the two devices with a multimeter, it was apparent that the stepper motor seemed to ground through its shaft. As the motor and potentiometer were connected by a metal gear, every time the motor was energized, it would ground through the potentiometer. In order to insulate the potentiometer from the stepper motor, a plastic gear was 3D printed. Once installed, the ground issue was resolved. The 3D model and finished gear are shown in Figure 10 below.

Figure 10. Plastic Gear With both the linear actuator and stepper motor operating with feedback, the next step was to incorporate them into an overall control strategy. A Simulink model, shown in Appendix D, was developed that moved both stepper motor and potentiometer upon position command. The next step was to map out the gears on the transmission and attempt shifting.

A Path Diverges However, before mapping of the gears could commence, the transmission was disassembled to move the overall vehicle project forward. In order to assemble the powertrain, a new shaft needed to be machined to couple the transmission to e-motor. The input shaft for the transmission was sent out as a reference piece to Liberty Gears. A fabrication and return date of the input shaft was unknown. The team could not move forward mapping the gears until the new input shaft arrived. In order to continue forward progress with the automated transmission project, the team moved its focus to address concerns that had arisen over the controller option. While the MotoTron ECU would perform the function necessary, it was physically bulky and programming in Simulink proved much more difficult than necessary. The automated shift mechanism was only using a handful of the available pins on the ECU. Also, due to the ECU’s reliance on the MotoHawk Simulink library, the team was constrained to the blocks that had been previously constructed by the MotoHawk company. The ECU also only had two H-bridge outputs. With the clutch, the automated shift mechanism would need 3 H-bridge outputs.

11

Due to these concerns, the team looked at different methods of controlling the automated shift mechanism. An Arduino controller was quickly identified as a great replacement for the MotoTron ECU. First, the Arduino developer environment could be downloaded to any computer, making it easier to perform calibration outside the sub-basement lab. Additionally, the control strategy could be written in C code instead of Simulink. Finally, the Arduino was easily expandable to fill the needs of the team. Additional shields could be purchased to control all of the motors on the automated shift mechanism. Arduino Controller In short, an Arduino is a small PCB (roughly 3” W x 5” D x 2” H) which houses a configurable microcontroller. Additionally, these boards have many headers that connect to both analog and digital inputs and outputs, including PWM signals. There are also various models of the Arduino, in which different microcontrollers are used and the number of accessible inputs and output change. The base model is the Arduino Uno, which is shown below in the left of Figure 9. Due to the limited number of digital inputs and outputs, a higher end model was used - the Arduino Mega2560. The Mega is shown below in the right of Figure 11.

Figure 11. Arduino Uno vs. Arduino Mega2560 In order to add functionality onto the Arduino board, ‘shields’ can be purchased, which line up with and stack onto the main board. For the transmission project, the team required control of two linear actuators, one stepper motor, and the ability to send and receive CAN messages. Through research, a Pololu Dual VNH5019 Motor Driver Shield was selected to drive the linear actuators (Figure 12 below). This shield has two motor outputs that can be controlled individually and rated for a high current (12 A continuous, 30 A peak per channel).

12

Figure 12. Pololu Motor Driver Shield The second function needed was a CAN shield. The Sparkfun CAN shield is a commonly used shield and selected for the Mega. This shield is seen in Figure 13.

Figure 13. Sparkfun CAN Shield The remaining function was a way to control the stepper motor. A Pololu stepper motor driver chip was previously tested with the MotoTron ECU and verified to work with the selected stepper motor. Knowing this, the digital inputs and outputs on the Arduino Mega2560 would be used to control this driver chip instead of purchasing a separate Arduino shield with this ability. CAN Network and Supervisory Controller The transmission controller required communication with the supervisory controller. The supervisory controller was responsible for instructing the transmission controller when to shift the gears and when to activate the clutch. In order for the Arduino to communicate with the supervisory controller, the Arduino was added to the CAN network. The CAN shield shown previously was used to communicate on the CAN bus. A complete map of the vehicle CAN bus is shown below in Figure 14.

13

Figure 14. Vehicle CAN Bus A single CAN message was created on the network for automated transmission control. A CAN message is comprised of a number of packaged signals. The default size for a signal is 8 bits. The default size for a message is 8 bytes, meaning that 8 signals could be packaged in each message. For testing purposes, the transmission message was created in CANalyzer and assigned signals. One signal was set for the gear request and another for clutch activation. CANalyzer was configured so that the message was sent out onto the bus every 50ms. By changing the values in the Interactive Generator Block, shown below in Figure 15, control requests could be sent to the Arduino controller.

Figure 15. CANalyzer Interactive Generator Messages Information Additional information, datasheets, schematics, pinouts, etc. can be found at the following directory path (accessible anywhere on campus):

M:\mtu_hev\Sub-Team Folders\Transmission

The current Arduino controller code is “AutoShifting_v4.2.ino”. The Arduino development environment used for writing and compiling this code was “Arduino 1.6.1”. The modified Canbus and motor shield library must be imported to the Arduino IDE prior to compilation or it will not function properly. The Arduino controller was successfully: receiving CAN messages, identifying CAN messages

14

specific to the Arduino on the network, performing desired motor actions based off of the CAN message data, and formatting a response for transmission over CAN. Next Steps The transmission tools, Arduino controller, and associated Arduino shields are operating successfully. Additionally, the transmission tools are mounted on the transmission. At this point, the next step is to attempt shifting with the tools. Assuming the autoshift tools have the strength and accuracy to make a shift, the gear positions on the transmission could be mapped. As far as the electrical and controls side of the project is concerned, everything is in working order. In the past week, a new transmission input shaft was purchased from American Powertrain and is now installed in the transmission. However, the transmission itself is still not operating smoothly. Many of the gears cannot be located. Additionally, the gears that can be found are very difficult to move into and require a fair amount of play. The control system developed is meant to work on a smoothly shifting transmission. Before calibration work can be continued, the mechanical issues with the transmission must be resolved.

CONCLUSIONS

As a recap, communication to each transmission tool was made and a control model for each tool was developed. These models were individually tested and calibrated. Then, the models were integrated into one model and simultaneous control was achieved and calibrated. Currently, the controller can successfully function as desired will off of the transmission. It can accept commands over CAN, perform linear and rotational movements in sequence, and send confirmations back over CAN. Due to complications like current vehicle status and transmission-motor mount dynamics, the desired scope for the Automatic Manual Transmission will not be achieved at this point in time. However, based on the severity and unfamiliar complexity of issues that arose, there was still significant progress made. REFERENCES

Motion Systems, “Motion Custom Actuators”, Accessed April 20, 2015, http://www.actuator.com/ Polou, “DRV8825 Stepper Motor Diver Carrier, High Current”, Accessed April 20, 2015, http://www.pololu.com/product/2132 Sparkfun, “CAN-BUS Shield”, Accessed April 21, 2015, https://www.sparkfun.com/products/10039

APPENDIX

15

APPENDIX A

Automatic Shift Manual Transmission Project Proposal Team: Dylan Bingle James Hingst Cameron Smith William Tuttle Date: September 9, 2014 Project Purpose The project team is made up of four electrical engineering students with strong interest in automotive engineering. This interest brought each team member to the Hybrid Electric Vehicle Enterprise. Several of the team members have an interest in controls engineering and mechatronic systems. Given the freedom and inline with common interests, the team chose a project that would benefit the HEV Enterprise and their current project vehicle (the 1949 Chevy Truck). This project is to take the vehicles T5 Tremec Manual Transmission and bring it to the status of a fully functional Automatic Manual Transmission (AMT). The T5 is a common and versatile 5-speed transmission used in a variety of vehicles. The purpose of converting this transmission to an AMT lies in its ability to combine the fuel economy and performance of a true manual with the everyday convenience of an automatic and to provide an exemplary automotive controls learning experience. Project Function Typically a transmission refers simply to the gearbox that uses gears and gear trains to provide speed and torque conversions from a rotating power source to another device. In the case of the HEV project vehicle, this conversion is from either the front mounted internal combustion engine or the 3-phase electric motor to the drive shaft. This conversion is controlled by the driver in the form of shifting gears. Shifting gears is executed by pushing in the clutch and pushing the shift column which moves the gear selecting forks inside the transmission. With an AMT, the driver will not have to perform this gear shifting process themselves. Instead there is a mechanical and electrical control system that automates and increases efficiency. The electrical controls system is most basically a Simulink model run on an Electronic Control Unit (ECU). This model will receive commands from the Engine Control Unit and send the corresponding signals and power to the mechanical controls system. The mechanical controls system is comprised of a linear actuator for engaging/disengaging the clutch, a linear actuator for linear gear fork movement, and a stepper motor for rotational gear fork movement. Project Implementation The first stage of the project will be to determine whether or not the current hardware is the best option to move forward with. In the next stage, the team will work to establish communication with the control module and then from the control module to each tool. The ‘tools’ are divided into three sections - tool feedback, transmission tools, and the clutch. Each of these will require the development of a separate, but similar control strategy to function properly. The final stage of this project will be integrating all three of these components, implementing them onto the vehicle, and then performing extensive calibrations and control revisions to smooth out any bugs or problems.

16

Goals 1. Establish Controller and Individual Tools 2. Build Control Strategy and Establish Communication 3. Integrate and Calibrate Transmission into Vehicle Schedule 1. Review Control System Options (Sept. 4 - Sept. 10) 2. Establish Communication with the Control Module (Sept. 11 - Sept. 22) 3. Establish Communication from Control Module to Tools (Sept. 23 - Sept. 29) 4. Establish Tool Feedback to Controller and Calibrate (Sept. 30 - Oct. 6) 5. Mount and Calibrate Tools on Transmission (Oct. 7 - Oct. 13) 6. Integration of Transmission Tools in Overall Strategy (Oct. 14 - Nov. 3) 7. Calibration of Transmission Tools (Nov. 4 - Nov. 10) 8. Integration and Calibration of Clutch Tool (Nov. 11 - Nov. 21) 9. Finalize Control Strategy (Jan. 12 - Feb. 9) 10. Implement into Vehicle (Feb. 9 - April 1)

17

APPENDIX B

18

APPENDIX C

19

APPENDIX D

20

APPENDIX E

21

APPENDIX F Arduino Code v4.2 /* * AutoShifting Arduino Controller * * Created by: Dylan Bingle, Jim Hingst, * Cameron Smith, and Will Tuttle * * Description: Controls a stepper motor and linear actuator * based on desired transmission gear request. The * desired gear request will be read via the CAN bus. * A second linear actuator will also be controlled to * engage/disengage the clutch. * * Changelog: * ---------------------* version 1: 3/21/2015 * -Create general code skeleton * -Manual control of a motor with arduino * ---------------------* version 1.1: 3/26/2015 * -Edited by: Jim//Model status: working * -Established closed loop control with pot feedback * -Renamed pot_wiperPos to la_currPos * ---------------------* version 2: 3/27/2015 * -Edited by: Jim//Model status: working * -Linear Actuator Control * -Begin Stepper Motor Control * ---------------------* version 2.1: 4/1/2015 * -Edited by: Jim,Dylan//Model status: working * -Stepper motor controlled separately * -Stepper motor feedback also working * ---------------------* version 2.2: 4/2/2015 * -Edited by: Jim,Dylan * -Integrate stepper motor and linear actuator controls * ---------------------* version 3: 4/4/2015 * -Edited by: Jim,Dylan * -Improve stepper motor control * ---------------------* version 4: 4/20/2015 * -Edited by: Jim,Dylan * -Added Request to Position look ups within the motor functions

22

* -Altered entire code to function on a single command and action basis(so no command queing or backing out of an action) * version 4.1: 4/24/2015 * -Edited by: Jim,Dylan,Cameron * -CAN shield now working * -Basic CAN integration now in code * version 4.2: */ grey - 3.3v orange 5v blue - gnd */ // Library includes #include "DualVNH5019MotorShield.h" #include // CAN related variables unsigned char buffer[16]; unsigned int newmessage_id; unsigned int arduinoCAN_id = 0x222; String newwest_message = "x"; #define COMMAND 0xFE #define CLEAR 0x01 #define LINE0 0x80 #define LINE1 0xC0 // Motor shield declarations DualVNH5019MotorShield mtr_shld_1(2,4,6,'A0',7,8,12,'A1'); //linear actuator shield // "la_" denotes linear actuator variables const int la_posTol = 10; // tolerance to prevent oscialltion from overshoot int la_speed = 75; // range: 0 to 400 const int la_speedStop = 0; // motor speed of 0 (to stop motor) int la_currPosition; // current position of linear actuator via pot int la_currLimit=4500; // mA const int la_potWiper_pin = 13; // Analog Pin 13 String la_status="--"; // "sm" denotes stepper motor variables const int sm_posTol = 15; // to prevent oscialltion from overshoot int sm_speed = 64; // range: 0 to 255, 0 = 0% duty, 255 = 100% duty const int sm_speedStop = 0; // motor speed of 0 String sm_status="--"; int sm_currPosition; const int sm_step_pin = 13; // PWM pin 13 const int sm_rst_pin = 22; // Digital pin 22 const int sm_slp_pin = 26; // Digital pin 26

23

const int sm_dir_pin = 30; // Digital pin 30 const int sm_potWiper_pin = 11; // Analog Pin 11 // "ca" denotes clutch actuator variables const int ca_posTol = 10; // tolerance to prevent oscialltion from overshoot int ca_speed = 75; // range: 0 to 400 const int ca_speedStop = 0; // motor speed of 0 (to stop motor) int ca_currPosition; // current position of clutch actuator via pot int ca_currLimit=4500; // mA const int ca_potWiper_pin = 15; String ca_status="--"; void setup() { delay(2000); Serial.begin(115200); // set baud rate to 115200 // Initialize motor shields //mtr_shld_1.init(); // Initialize CAN shield and bus if(Canbus.init(CANSPEED_500)){ /* Initialise MCP2515 CAN controller at the specified speed */ Serial.print("CAN Init ok"); } else{ Serial.print("Can't init CAN"); } // Initialize arduino pins as outputs for stepper motor pinMode(sm_rst_pin,OUTPUT); pinMode(sm_slp_pin,OUTPUT); pinMode(sm_step_pin,OUTPUT); pinMode(sm_dir_pin,OUTPUT); digitalWrite(sm_rst_pin,HIGH); // Initialize SPI pins // These pins are the SPI pins on the Mega2560 and map to the // PWM pins (10->53, 11->51, 12->50, 13->52) since the SPI pin mapping // on the Uno differs from the Mega2560's pins // pinMode(53, OUTPUT); // pinMode(52, OUTPUT); // pinMode(51, OUTPUT); // pinMode(50, OUTPUT); } void loop() { //**Read CAN for instructions - START** //CAN Shield to Arduino

24

//Pin2 to PWM2 //Reset to Power Reset //3.3V to 3.3V //5V to 5V //GND to GND //13 to 52 //12 to 50 //11 to 51 //10 to 53 newmessage_id = Canbus.message_rx(buffer); if(newmessage_id == arduinoCAN_id){ Serial.println(buffer[2]); //newwest_message = buffer[2]; } //**Read CAN for instructions - END** //**Clutch Actuator - START** if(newwest_message == "CE" || "CD") { // sm_status = sm_actuate(newwest_message); // Serial.println(sm_status); // Canbus.message_tx(sm_status);//send status to supervisory controller } //**Clutch Actuator - END** //**Linear Actuator - START** if(newwest_message == "1" || newwest_message == "2" || newwest_message == "3" || newwest_message == "4" || newwest_message == "5" || newwest_message == "R" || newwest_message == "N"){ // if(ca_status == "CE") // { // //send amir an error message stating that clutch is still engaged // Serial.println("Clutch still engaged. Will not perform linear actuator request"); // break; // } la_status = la_actuate(newwest_message); Serial.println(la_status); //Canbus.message_tx(la_status);//send status to supervisory controller } //**Linear Actuator - END** //**Actuate Stepper Motor - START** if(newwest_message == "S1" || newwest_message == "S2" || newwest_message == "S3"){ // if (la_status != "N") // { // Serial.println("Not in Neutral gear. Will not perform stepper motor request");

25

// //

break; } sm_status = sm_actuate(newwest_message); Serial.println(sm_status); //Canbus.message_tx(sm_status);//send status to supervisory controller

} //**Actuate Stepper Motor - END** }//**End Main Loop Here //**Functions Defined Below** String ca_actuate(String des_Gear){ /* Pot wiring: Wiper(white)=Analog Pin 13 Red(high)=5V VDD Black(GND)=Adjacent GND Actuator wiring (goes to motor shield): Red(power)=M1A Black(GND)=M1B Pot read range "" to "" on our linear actuator. +-1 accuracy of the pot analog read We do not have the specific datasheet but we think it is 12V, 6A No-load, 36A @1000lbs, 20:1 ratio */ int des_Position; String ca_status; //Set the desired position based on gear if(des_Gear == "CE"){des_Position = 525;}//last measured at 570 if(des_Gear == "CD"){des_Position = 600;} int finished = 0; ca_currPosition = analogRead(ca_potWiper_pin); // get current linear actuator position while(finished == 0){ ca_currPosition = analogRead(ca_potWiper_pin); // get current linear actuator position // Fault checking /*if (mtr_shld_1.getM1Fault()){ Serial.println("Status: Fault"); break; } if (mtr_shld_1.getM1CurrentMilliamps() > CurrentLimit){ Serial.print("Status: Overcurrent - "); Serial.println(mtr_shld_1.getM1CurrentMilliamps()); break; }*/ // Adjust linear actuator until current position is within the set tolerance if(ca_currPosition < (des_Position - ca_posTol)){ mtr_shld_1.setM1Speed(ca_speed); }

26

else if(ca_currPosition > (des_Position + ca_posTol)){ mtr_shld_1.setM1Speed(-ca_speed); } else /*( la_currPosition <= (des_Position + la_posTol) && la_currPosition >= (des_Position - la_posTol) )*/{ mtr_shld_1.setM1Speed(ca_speedStop); finished = 1; ca_status = "Complete"; } } return ca_status; } String la_actuate(String des_Gear){ /* Pot wiring: Wiper(white)=Analog Pin 13 Red(high)=5V VDD Black(GND)=Adjacent GND Actuator wiring (goes to motor shield): Red(power)=M1A Black(GND)=M1B Pot read range "100.00" to "940.00" on our linear actuator. +-1 accuracy of the pot analog read More current to push out than to pull in. 1.428A pull in at -75 speed. 1.598A push out at 75 speed. */ int des_Position; String la_status; //Set the desired position based on gear if(des_Gear == "1"){des_Position = 350;}//940 if(des_Gear == "2"){des_Position = 450;} if(des_Gear == "3"){des_Position = 300;} if(des_Gear == "4"){des_Position = 500;} if(des_Gear == "5"){des_Position = 250;} if(des_Gear == "R"){des_Position = 550;} if(des_Gear == "N"){des_Position = 760;}//760 int finished = 0; la_currPosition = analogRead(la_potWiper_pin); // get current linear actuator position while(finished == 0){ la_currPosition = analogRead(la_potWiper_pin); // get current linear actuator position // Fault checking /*if (mtr_shld_1.getM1Fault()){ Serial.println("Status: Fault"); break; } if (mtr_shld_1.getM1CurrentMilliamps() > CurrentLimit){

27

Serial.print("Status: Overcurrent - "); Serial.println(mtr_shld_1.getM1CurrentMilliamps()); break; }*/ // Adjust linear actuator until current position is within the set tolerance if(la_currPosition < (des_Position - la_posTol)){ mtr_shld_1.setM1Speed(la_speed); } else if(la_currPosition > (des_Position + la_posTol)){ mtr_shld_1.setM1Speed(-la_speed); } else /*( la_currPosition <= (des_Position + la_posTol) && la_currPosition >= (des_Position - la_posTol) )*/{ mtr_shld_1.setM1Speed(la_speedStop); finished = 1; la_status = "Complete"; } } return la_status; } String sm_actuate(String des_Column){ /*Pot wiring: Wiper=Analog Pin 11 Red=5V VDD Black=Adjacent GND Stepper Motor wiring: dir - digital pin 30 step - pwm out 13 slp - digital pin 26 rst - digital pin 22 */ int sm_desPos; String sm_status; //Set the desired position based on requested column if(des_Column == "S1"){sm_desPos = 155;}//gears 1&2 if(des_Column == "S2"){sm_desPos = 225;}//gears 3&4 174 to 246. so a distance of about 70 from S1 to S2 if(des_Column == "S3"){sm_desPos = 160;}//gears 5&R sm_currPosition = analogRead(sm_potWiper_pin); Serial.println(sm_currPosition); int finished = 0; while(finished == 0){ sm_currPosition = analogRead(sm_potWiper_pin); if(sm_currPosition < (sm_desPos - sm_posTol)){ digitalWrite(sm_slp_pin, HIGH); digitalWrite(sm_dir_pin, HIGH);

28

analogWrite(sm_step_pin, sm_speed); } else if(sm_currPosition > (sm_desPos + sm_posTol)){ digitalWrite(sm_slp_pin, HIGH); digitalWrite(sm_dir_pin, LOW); analogWrite(sm_step_pin, sm_speed); } else /*( sm_currPosition <= (sm_desPos + sm_posTol) && sm_currPosition >= (sm_desPos - sm_posTol) )*/{ analogWrite(sm_step_pin, sm_speedStop); digitalWrite(sm_slp_pin, LOW); finished = 1; sm_status = "Complete"; } } return sm_status; }

Modified Header Files: “Canbus.cpp” /** * * * Copyright (c) 2008-2009 All rights reserved. */ //#include "WConstants.h" #include "Arduino.h" #include #include #include #include #include "pins_arduino.h" #include #include "global.h" #include "mcp2515.h" #include "defaults.h" #include "Canbus.h"

/* C++ wrapper */ CanbusClass::CanbusClass() { } unsigned int CanbusClass::message_rx(unsigned char *buffer) { tCAN message;

29

if (mcp2515_check_message()) {

// Lese die Nachricht aus dem Puffern des MCP2515 if (mcp2515_get_message(&message)) { // print_can_message(&message); // PRINT("\n"); buffer[0] = message.data[0]; buffer[1] = message.data[1]; buffer[2] = message.data[2]; buffer[3] = message.data[3]; buffer[4] = message.data[4]; buffer[5] = message.data[5]; buffer[6] = message.data[6]; buffer[7] = message.data[7]; return message.id; // // // //

buffer[] = message[]; buffer[] = message[]; buffer[] = message[]; buffer[] = message[]; } else { // PRINT("Kann die Nachricht nicht auslesen\n\n"); } }

} char CanbusClass::message_tx(unsigned int canid, unsigned char content, unsigned char *buffer) { tCAN message; // einige Testwerte message.id = canid; message.header.rtr = 0; message.header.length = 8; message.data[0] = 0x00; message.data[1] = 0x00; message.data[2] = content; message.data[3] = 0x00; message.data[4] = 0x00; message.data[5] = 0x00; message.data[6] = 0x00; message.data[7] = 0x00;

30

// mcp2515_bit_modify(CANCTRL, (1<
mcp2515_bit_modify(CANCTRL, (1<
SET(LED2_HIGH); if (mcp2515_send_message(&message)) { delay(100);

if (mcp2515_check_message()) {

31

if (mcp2515_get_message(&message)) { switch(message.data[2]) { /* Details from http://en.wikipedia.org/wiki/OBD-II_PIDs */ case ENGINE_RPM: // ((A*256)+B)/4 [RPM] engine_data = ((message.data[3]*256) + message.data[4])/4; sprintf(buffer,"%d rpm",(int) engine_data); break; case ENGINE_COOLANT_TEMP: //

A-40

[degree C] engine_data = message.data[3] - 40; sprintf(buffer,"%d degC",(int) engine_data); break; case VEHICLE_SPEED: // A engine_data = message.data[3]; sprintf(buffer,"%d km",(int) engine_data);

[km]

break; case MAF_SENSOR: // ((256*A)+B) / 100 [g/s] engine_data = ((message.data[3]*256) + message.data[4])/100; sprintf(buffer,"%d g/s",(int) engine_data); break; case O2_VOLTAGE: // A * 0.005 (B-128) * 100/128 (if B==0xFF, sensor is not used in trim calc) engine_data = message.data[3]*0.005; sprintf(buffer,"%d v",(int) engine_data);

break;

} }

32

else { // PRINT("Kann die Nachricht nicht auslesen\n\n"); } //

} RESET(LED2_LOW); return 1;

} else { // PRINT("Fehler: konnte die Nachricht nicht auslesen\n\n"); return 0; } return 1; }

char CanbusClass::init(unsigned char speed) { return mcp2515_init(speed); } CanbusClass Canbus;

“Canbus.h” /** * CAN BUS * * Copyright (c) 2010 Sukkin Pang All rights reserved. */ #ifndef canbus__h #define canbus__h #define CANSPEED_125 #define CANSPEED_250 #define CANSPEED_500

7 3 1

// CAN speed at 125 kbps // CAN speed at 250 kbps // CAN speed at 500 kbps

#define ENGINE_COOLANT_TEMP 0x05 #define ENGINE_RPM 0x0C #define VEHICLE_SPEED 0x0D #define MAF_SENSOR 0x10 #define O2_VOLTAGE 0x14

33

#define PID_REQUEST

0x7DF

class CanbusClass { public: CanbusClass(); char init(unsigned char); char message_tx(unsigned int canid, unsigned char content, unsigned char *buffer); unsigned int message_rx(unsigned char *buffer); char ecu_req(unsigned char pid, char *buffer); private: }; extern CanbusClass Canbus; //extern tCAN message; #endif

34