April 10 / 2011

My final year design project at George Brown College that I had taken with permission a year early. None the less, due to the open nature of post-secondary research and development projects, I am making my part of the project available for anyone who wishes to adapt the technology further.

The Car pre-body stage showing the bamboo frame of the vehicle.

The electronic system of the car, is regulated by the design of the wheels that were donated to us by Magna International. When in contact with Magna in the beginning of the year, it was made known that the system was proprietary and as such they would not release any information to us for use in the project. This meant that the rest of the design methodology focused primarily on using what I already knew about the system and working backwards by using a working system. 

As such, the meeting the previous year with Magna Marque was a very good starting point. By visiting the site, allowing me to see the assembly of the system, and their presentation allowed a better understanding of the over all system intentions. By using a book on the CAN Bus by Wilfried Voss and Bosch's own specification document that is available as a free PDF on their website, the over all implementation of a CAN Bus network design was available. This allowed for a better understanding of the needs for a hardware solution.

In January using a CAN Bus analyzer purchased from ESD Electronics, the BionX network was checked, and shown to not be based on any standard CAN protocol. While in a sense this can be a down side, at the same time this can be a positive result, due to the fact that some more “free flowing” CAN protocols exist which make the interpretation of the data slightly more difficult to follow. And within approximately 8 hours of running the BionX system, enough information from the system had been obtained to work on the construction of the system.

The test bed built to be able to test the BionX system in a fixed environment.

The CAN protocol that BionX is using for their wheels, is non standard as I had mentioned. And uses either 2 byte data packets or 4 byte packets. Additionally it uses 3 packet identifiers, 8 for the console itself, 16 for the battery pack, and 32 for the motor. This data was discovered through a couple of million of packets that we had collected using the analyzer.

A picture of the computer with the CAN Bus analyzer software opened.

The discovery of the ID's came to be by looking at the specific method of communication. Since the BionX system was previously had used the I2C system of serial communication. It stood to reason, that since the ID's are not preforming the regular functions of a proper CAN bus protocol, and by that, I mean a message based networking system as apposed to the more common physical networks we are used to. That the CAN bus protocol on the BionX system was using a physical based network. To eliminate what of the ID's were calling to what, I looked at the way the strings of messages were calling each other, message ID 16 and 32 always started a 2 message string, with the first byte of data zeros, and the second byte of data, a command. When such a message was sent on the CAN Bus, the response always came with a message ID of 8, and the 1st byte of zeros, the 2nd byte of the same command byte, the 3rd byte zeros again, and the 4th byte the response data. The only exception to this is when ID 32 comes up to send the speed to the motor. Which gave me the impression that ID 16 and 32 must be functioning devices, while 8 is the network “master” device. To eliminate which of 16 and 32 were the motor and battery, by comparing command byte 0x09, 0x11, 0x14 and 0x32, which were the more commonly addressed bytes to the two devices.

I had noticed that 0x32 is slowly decreasing based on time of the system running, and since I had a volt meter connected to the power lines of the system, I approximated a graph showing the codes for the various voltages as shown below.

As you can see there are a few fluctuations of the data in the code column, however that can be accounted for the slightly imprecise method to collect the data (variables changed quickly, which means that the data at the time the volt meter was checked and the time was noted, there is a slight time delay).

The test set up used to locate which CAN Bus variable is the battery voltage.

While for the command code 0x09, 0x11 and 0x14, there seemed to be correlations, and because of the fact that 0x09 came up first, I knew that it was the code from the console to the motor, while, 0x11 and 0x14 seemed to follow the movement. Which gave me a indication that at least one of them should be the speed signal. By experimenting with the pressure applied to the wheel, and ultimately having a group member hold the wheel to prevent it from spinning, it was clear that although the wheel was not turning, 0x14 was giving me higher then expected values, and 0x11 was showing zero. This meant that 0x11 must be the speed variables, while, 0x14 was the force applied (torque) sensor sending its values.

The realization of the battery data, and the speed sensors output to the CAN bus allowed me to realize what I had mentioned earlier that the CAN ID's are 8 for the console, 16 for the battery pack and 32 for the motor.

Currently the CAN Bus commands and their limits that are known are:

The values of the variables.

The function of the variables.

I have been informed by Tom Salwach, that the hubs temperature is the Command 0x16, being sent to the console at ID 8.

Thank you!

While there are more codes running on the system, for replacement of the console to control the motor, these are the primary ones required. The other ones appear at first glance to be unnecessary for basic functionality of the motor. Further testing would be needed in a controlled environment to decipher the rest of the variables.

The wheel running off the Bionx Battery Pack but without the console controller.

The CAN Bus structure is similar to this as shown, with the console sending the speed factor it wishes the wheel to move, along with a check of the wheels speed followed afterwords.

A typical cut out of the CAN Bus logs.

Because of the speed that that wheels can do maximum is regulated not at the console controller alone but the wheel's own motor controller speeds above 26.1km/h seem unlikely without extensive modifications to the system, but the consoles themselves appear to be able to handle data that is above that, unlike the motor's and their need for values of 0x40 or below. As such I included a short table of values that are permissible by the console for command 0x11 which have been tested.

All speed values in km/h.

Each set of frames, appears to end with a call to check the battery voltage (0x32 command) then a ID 88 command that restarts the process. The format of the blocks of packets allows for easy dissection of the codes used in various stages of the running of the wheel. It also allows for easier start and end points to be defined in the software to control the wheel instead of making one very large program it can be broken apart into chunks that can be called upon in the program.

Since the platform was selected by the professor, to follow the lines of the programming class that is in 2nd year's change to the Arduino from the Basic Stamp, the electric race car this year uses a Arduino as well. Due to the nature of the Arduino, and the lack of requirement to use circuit board manufacturing houses, a quick prototype can be produced using commercially available “shields”. This controller that was built for the race car, has a Sparkfun CAN Bus shield, which uses the Microchip CAN Bus to SPI bridge chip known as the MCP2515 along with the required transceiver chip the MCP2551. Since this is a pretty standard platform, both the Arduino, and the MCP2515 chips being used to interface into microcontroller systems that were not originally designed for the CAN Bus, I decided the easiest way to use it would be by using Frank Kienast's library.

Frank's link:

For a control input for the speed required for the driver, a potentiometer is used, however due to the nature of the BionX system, and its motor being effectively on or off depending if it reaches a high enough speeds, speeds lower then 20km/h seem improbable. This is to be expected due to the lack of gearing, and electric motors requiring a constant turning of the magnets verses the coil assembly to keep them in the constantly cycling state.

On the BionX system cables, the cable connected from the battery pack to the console has the following color code:

Color coding of the cable. Pin assignment on the circular connector is based on 1 being the pin to the right of the key and going clockwise.
See below for the connector itself.

The analyzers connector attached to the BionX cable while obtaining the CAN bus logs showing the connection to the CAN bus on the wiring as noted in the above table.

As such, the .100” header on the CAN Bus shield was extended out to a terminal block arrangement including CAN High, CAN Low, Ground and +5V, soldered and heat shrink tubing to hold it into place onto the original BionX cable. This in turn is connected to the motor using the original circular connector. It appears to be HRS-30 manufactured by Hirose Connectors, however I've been unable to find a source of these cables prefabricated.

The circular HRS-30 Connector.

The Power lines into the motor uses a 2 pin, one exposed, one not exposed automotive connector.

The automotive style connector, the red covered exposed pin is the positive pin.

By using the 6” extension cable that is commonly available, 2 power cables feeding from the motor to the battery packs were fabricated. This allows the use of other battery packs that are not the original one to be used. Radio Shack/The Source or Canadian Tire among other sources.

While, I would like to mention that the charging circuit from the BionX Battery and Motor seems to play a critical role in the motor's operation, and I had discovered it a couple of weeks before the car needed to be complete, I was unable to find the exact charging circuit. And due to the fact Magna decided to black lacquer the parts makes the situation just a tad more difficult. Eventually a separate page will hopefully be attached to this site about the charge method.

The Controller running off the Lead Acids but using the BionX Battery board regretfully.

A video showing the system in reverse as it was decided to run the wheels in that orientation and a test to see if my assumptions on 0x42 were correct was also needed.

A semi-last minute change was to use one of my personal CAN shields along with the college funded shield to run the 2 wheels independently, as such the code is not quite available but will be shortly, this will allow individual control of the wheels. The method I used to change the class allows making a different line the chip select but will not create 2 different classes, which means that only the 2nd declared CAN Bus controller will work. This needs to be changed.

Special thanks to Justin (Design and Development of Bamboo Frame), Brent (Bike Integration and Welding), John (Steering Systems Design and Manufacturing), Rich (Liaison to the College) and Dave (Manufacturing).

Update: We ran the car on April 15th, We had a issue with one of the motors getting damaged, none the less, we still ran the race with one working motor, and drove a total of 5 miles on the track. A 25% increase from last year on one motor. The issue with zero torque on these motors is what caused our issues greatly as both times the car "died" on the track was at the turn that the drivers had to slow down slightly that leads into a up hill.

After the race we took it out for spins on the parking lot, the steering system that John and Brent worked on worked amazingly well, and with all of the side loads (that the race marshals told us it appeared to be about 4" of deflection that we tested afterwords) did not cause any spoke loss on the wheels. The frame held up in one piece without any of the issues we were afraid of and its definitely a viable option for bamboo with the covering that Justin worked on testing.

I hope you enjoyed this page, and feel free to contact me if needed about the project. All the code and my logs are released under the original BSD license, so commercial or open source projects are welcomed to spawn from this.

File List Below:
  • Bionx10.pde - Basic Arduino Sketch one for each wheel till I fix the library.
  • canbus_shield-v12.pdf - Sparkfun's Schematic for the shields I used for this project.
  • - Zipped file of the library.
  • BionX CAN Bus - Zipped Folder of the CAN Data I collected using my analyzer. The following sets are of note:
  • Set 1 - Initial Testing of the Analyzer
  • Set 2 - Longer Run to get a feel of the system with the BionX Wheel
  • Set 3 - Voltage Data collection run.
  • Set 4 - Various experiments
  • Set 5 - No Load Testing
  • Set 9 - Testing the Reverse feature
  • Set 10 - Start up with Reverse on
  • Set 11 - Set Reverse to off
  • Set 12 - Speed motor will start variable (0km/h or 3km/h)
  • Set 13 - Started system with the speed set to 3km/h
  • Set 17 - Ran BionX4 Code (Error)
  • Set 18 - No CAN Activity with the Arduino
  • Set 19 - Arduino in Battery Mode Not working
  • Set 20 - No motor response
  • Set 21 - Set to only respond as the battery for 0x32
  • Set 22 - Arduino set as Console, working as you saw in the video above.
  • Set 23 - Removed the 3.3V/Wake Up line, no change in system operation.
  • Set 24 - Problems with the Analog input apparent, tracked it down due to using the common ground.
  • Set 25 - Added a if less then 50 on the Analog comparator to better stabilize the start up of the system.
  • Set 26 - Start up Jolting due to CAN ground as noted in Set 24
  • Set 27 - Same as Set 24 and Set 26

Dimitrios Simitas

Dimitrios Simitas,
Apr 22, 2011, 5:51 AM
Dimitrios Simitas,
Apr 11, 2011, 7:54 PM
Dimitrios Simitas,
Apr 22, 2011, 5:55 AM
Dimitrios Simitas,
Apr 11, 2011, 7:39 PM