University of Strathclyde Eco-Vehicle: Powertrain Development Team

Our powertrain development team is responsible for creating all electrical aspects of the drive system in our electric prototype vehicle. The team is made up of a series of development sub-teams tackling distinct modules which come together to provide the full working system, each of which serve a specific purpose. Each module consists of a blend of custom firmware and hardware which must be designed, built and tested by each development team.

Logic Board

The most obvious of these is the Motor Controller (MC). This module is split into two sections: the main inverter board which encompasses the all power electronics, power supplies and filtering used to drive the motor; and the logic board (pictured above) which runs the control firmware for correctly driving the inverter stage and ensuring safe operation of the motor/vehicle at all times. This firmware executes on an ST STM32 microcontroller which is clocked at 76MHz and features many integrated peripherals specifically designed for advanced motor control techniques. All other modules in the car communicate with the MC via a custom CANbus network.

Until this year the “Powertrain” team consisted of development of the motor controller and selection of a suitable motor. This year however the scope of the systems in the vehicle was expanded to include more isolation/distribution between sensitive sub-systems, additional sensing elements for added driver safety. This required the addition of new modules: the Speed Sensor and Body Controller, which started off as two independent units, but were later realised to be similar enough in the core hardware design that a single custom PCB (the ‘Combined Board’) was developed which is populated differently for each module and flashed with the corresponding firmware. This decision has allowed us to reduce the costs and testing time for these modules, and should prove to make maintenance of these modules easier in the coming years.

Combined Board

Our Body Controller module allows us to sample the driver’s desired actions via a physical interface composed of two pedals: accelerator and front brakes. These physical inputs are sampled via potentiometers, the signals from which are read by the Body Controller, packaged into a suitable data format and sent the the MC via the CANbus for it to react accordingly.

Previously this was handled in the motor controller itself, but issues with noise, processing and consistency required us to push these tasks on to an independent unit which could carry out this sampling independently, and more importantly, would be isolated from the noisy environment of the motor controller. Hence, the Body Controller and subsequent need for a CANbus were born.

The Speed Sensor module consists of specially populated instance of the previously described Combined Board, as well as a second PCB containing hall sensors (pictured below). This second board is mounted into a specially design mechanical support which places the hall sensors in such a way so as to detect the magnetic field of rotating magnets placed in a second mechanical structure attached to the rear wheel. This was a particularly challenging area due to the close electrical and mechanical design aspects that had to be fully integrated with one another.

Hall Sensor Board

The core speed sensor hardware board is mounted further back from the mechanical aspects of rear wheel mount and takes the readings from the hall sensors, works out the speed of the vehicle and sends this data back to the motor controller for processing via the CANbus. Furthermore, the module has additional inputs for temperature sensors to be placed on the battery and/or motor for additional performance measurement and recording by the telemetry module we are developing this year, which will be discussed in more detail in a seperate post.

As mentioned, another new development for this year is our custom CANbus protocol. We decided to group CAN under the Powertrain Development Team instead of Telemetry as the primary area of collaboration was going to be between people working on CAN and Powertrain. The network will transport messages between five main areas of the car which are, in order of priority: Body Controller, Motor Controller, Speed Sensor, Battery Management System and Telemetry Modules. For each of the three Powertrain nodes, there are 3 message types with unique Identifiers: Error, Data and Heart Beat, which confirms that the node is able to send/receive messages. A sample message coming from the MC (with an Identifier of 9) is shown below.

Sample CANbus Message

The Data section of the message is split up into blocks based on the node the data is coming from. The above message which is being sent from the Motor Controller is split up into temperature, motor current, supply current and bus voltage, each taking up 12 bits of the data packet.

As an 8-bit Identifier has been chosen, this leaves plenty of room for future expansion as new nodes are added to the system, with only 12 Identifiers currently being used.

Motivity Ltd

This year we are lucky to be working with Motivity, a company specialising in bespoke motors, based in Galashiels. In previous years off the shelf motors were used, but this year through this partnership we have developed a bespoke brushed motor for the competition, and have plans to work together on a complete brushless solution in the coming year. Additionally, they have provided us with a variety of services including use of their dynamometer, profiling of last year’s motor for further analysis and a deeper understanding of our requirements.

We welcome any comments or questions on our system! As we are a relatively young Shell Eco-Marathon team, we are grateful for any and all feedback on our designs. Thank you!