ECUs implementing Sensorboards and Actorboard

From ConceptCar
Revision as of 12:38, 14 June 2011 by Donald (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The interfaces between the sensors and actuators and the Concept Car’s CAN Bus are implemented using AT90CAN128 boards. Their main purpose is to do low level tasks, for example PWM de- and encoding.

In the following, the AT90CAN128 board is presented and the ECUs that are implemented over AT90CAN128 boards are described in details. Those ECUs were presented in the Section Electronic_System in the Input and Output Processing levels of the Figure 1.3.

The AT90CAN128 board

All ECUs described on this page adhere to the form factor for small ECUs on the ConceptCar. They all share the same MCU, an AT90CAN128 which is an 8-bit RISC Microcontroller with AVR core, 128K bytes of programmable Flash memory, 4K byte EEPROM and 4K byte of internal SRAM, 53 general purpose I/O lines, 32 general purpose working registers, CAN Controller , 4 timers, and others resources described in [Atm08].

In the following, a table is presented for each ECU showing the CAN messages this ECU emits. In those tables, the "CAN-IDs" column presents the integer representing the ID of the message. Column "Semantics" describes the type (or meaning) of the message. Column "Interval" describes the interval in which the message is sent. Finally, the column "Conversion" holds a formula that is used for converting the message content which is usually a float value to the integer data that is packed into the message.

Sensorboard Steering

This ECU decodes the steering PWM channel from the radio receiver and the wheel speed sensors from the rear left and front right wheels. Analogue amplifiers (MCP6002) increase the signal level of the wheel speed sensors so their signal can be decoded on a digital input of the AT90CAN128.

See CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL as well as CANID_STEERING for a description of this ECU's output signals.

PWM Decoding and Signal Validity

The ConceptCar receives the driver's wishes from the remote control over a radio channel. The radio receiver may show very unpleasant behavior: on signal loss (either through remote control being shut down or too big distance) the receiver produces a random output signal. This can be seen when servos are directly connected to the receiver - when the remote control is off, the servo starts to twitch unpredictably.

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if

  1. its rising edge is 16ms - 18ms after the last rising edge and
  2. its duty cycle is 0.5ms - 2.5ms.

However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared. The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

Connectors to external Sensors

As you can see on the picture, the Sensorboards Steering and Throttle both have 3 Connectors. One is for attaching the measured PWM signal, the other two are reserved for the Rotation Sensors. The Pinout is as follows:

  1. PWM Connector:
    1. Pin 1 --> PWM Input, digital levels
    2. Pin 2 --> Ground
  2. Sensor Connector:
    1. Pin 1 --> Ground
    2. Pin 2 --> (infrared) LED Power Supply, connect to the Anode and Cathode to ground
    3. Pin 3 --> Photo transistor Collector, connect Emitter to ground

Sensorboard Throttle

Sensorboard Throttle, Revision 1.2

This ECU decodes the throttle PWM channel from the radio receiver and the wheel speed sensors from the front left and rear right wheels. Analogue amplifiers (MCP6002) increase the signal level of the wheel speed sensors so their signal can be decoded on a digital input of the AT90CAN128. The throttle signal creates an acceleration signal (CANID_THROTTLE) for positive values (throttle lever on the remote pulled) and brake signals (CANID_BRAKEFL and CANID_BRAKEFR) for negative values (throttle lever pushed). The thoughts in PWM decoding and signal validity hold as well for this board.

See CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR as well as CANID_THROTTLE and CANID_BRAKEFL and CANID_BRAKEFR for a description of this ECU's output signals.

Sensorboard Distance

Sensorboard Distance, Revision 1.2

This ECU accesses the SRF02 distance sensor over an serial UART Bus.

See CANID_DISTANCE for more information about this ECU's output signals.

Sensorboard Acceleration and Datalogging

Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3

This ECU controls the acceleration (longitudinal and lateral) and rotation (yaw rate) sensors over a SPI-Bus. It also measures the voltage of the battery that supplies the electrical components.

It additionally features data logging capabilities; it dumps all data on the CAN-Bus to a file on a FAT-formatted SD- or MMC-Card.

LCD Display

Atop of this, since revision 1.2, it features a 8x2 digits LCD display and a 8 Pin DIP switch, intended for selecting the currently displayed information. The display gets updated every 250ms.

  • If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
  • Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
  • Else if DIP switch 3 is "on", the display shows the current yaw rate.
  • Else if DIP switch 4 is "on", the display shows the current supply voltage.
  • Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
  • Else if DIP switch 6 is "on", the display shows the current CAN load in CAN messages per second.
  • Else if DIP switch 7 is "on", the display shows the input signal for throttle and steering. If a signal is not present, a horizontal bar is shown, if the signal is present, a vertical bar presents its current value.
  • Independent of the other switches, the DIP 8 switch selects the mode of the display. If it is set to "on", the current raw value (as transferred over the CAN bus) is shown, if it is set to "off", the display shows the value converted to its respective physical unit (m/s^2, °/s, V).

Table 1.5 presents the CAN messages for the Sensorboard Acceleration & Datalogging.

Table 1.5: Sensorboard Acceleration's CAN messages
CAN ID Semantics Interval Conversion
0x010 Longitudinal Acceleration (ax) 50ms
Error creating thumbnail: Unable to save thumbnail to destination
0x011 Lateral Acceleration (ay) 50ms
Error creating thumbnail: Unable to save thumbnail to destination
0x012 Rotation (ω) 50ms
Error creating thumbnail: Unable to save thumbnail to destination
0x00d Voltage (U) of the electrical system’s battery 200ms
Error creating thumbnail: Unable to save thumbnail to destination

Data Logging

The SD Card Holder

The Sensorboard Acceleration & Datalogging can write data to a FAT16-formatted SD or MMC card that is inserted into the card reader slot. When the board is booted and a valid card is detected, a new file is created and data from all messages on the can bus is written into this file. There is no mechanism to specifically close the log file. Just remove the card or power down the board.

When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
This LED blinks once each time a 512 Byte sector is dumped to the SD card. A good indicator if logging actually works. Every 8 sectors the file size is updated, resulting in an irregularity in the blinking. Thus, the filesize always is a multiple of 512 * 8 = 4096 Bytes. You can configure this number in the Makefile.
The Write LED is turned on after the SD card has been initialized. If it stays on and the "LOGGER ON" LED stays off, the file system could not be initialized. Most likely this means that the SD card has the wrong format, but for some reasons even if the format is correct, filesystem initalization always fails on some cards.
  • File Naming Scheme
    • The data is stored to a newly created file with the naming scheme LOG<nr>.CAN. The <nr> part is a consecutive number to name all files differently and not to overwrite an older log. An internal counter increments each time a new log file is written, and the counter state is conserved in EEPROM over reboots. Reflashing the board resets the counter to 0.
  • Requirements for the card
    • The SD or MMC card must meet the following conditions:
      • A partition table exists.
      • The "DOS compatibility flag" must be set.
      • There is exactly one primary partition.
      • The partition's type is "FAT16" (set partition code to 0x06 with fdisk).
      • The partition is formatted with FAT16, two fats.

Using a Unix/Linux system, if /dev/mmcblk0p1 is your MMC/SD card device's primary partition,

 > mkfs.vfat -F 16 /dev/mmcblk0p1

would create a valid FAT 16 partition.

On a Windows XP system, formatting the card with FAT (not FAT32!) works.

Despite having the correct partition scheme and formatting, some cards just did not work. We can not tell you why and how, just check if the red LED indicates that the logger works. Cards with 2GB or more tend to be problematic, try using a 1GB card.

  • Log file format
    • The log file has a binary format, containing a dump of all CAN messages including a timestamp for each. For each CAN message, the following data fragment is written:
 | Header | Timestamp | CAN ID  | Data Length |     Data    |
 |  0xca  |  4 Bytes  | 2 Bytes |    1 Byte   | 0 - 8 Bytes |

The Header field is always one Byte with hex value 0xca. The Timestamp field holds the time in ms since the board was booted up. The remainder of the data fragment is the CAN message's id and content. For each received CAN message, a new fragment of this sort is appended to the log file. The writing format is set in [1]. Since there is no mechanism for explicitly closing the log file, the last message fragment in the log file is usually cut off.

Plotting the logged Data

There are several ways to evaluate the logged data graphically. Here is how to do it with Gnuplot, that is available for all common operating systems. The logged Data has the following format: TIMESTAMP:CAN-ID:VALUE. In Gnuplot type:

 # <- Comment, you do not have to write, what comes after #
 file = "C:\\the\\directory\\LOGxxxx.txt"     # \ has to be escaped with \\
 show = 10
 set datafile separator ':'
 plot file using 1:($2 == show ? $3 : 1/0)

Explanation: First we simply save the path to our Log-file to 'file'. After that, we save a constant to 'show' that says us, which channel we want to plot. The third line says Gnuplot, what separates each data information from another. In our log files, separator is ':'. The last line does the plotting: Define x-Axes equals column 1 of our Log file; y-Axes is column 3, but only if column 2 of the same row equals our defined 'show'-variable, otherwise y is a number Gnuplot isn't able to plot.

This will throw a window onto the screen.

If you want to plot more data into one single screen, you can do this by simply typing

 set multiplot
 unset multiplot

before the first plot and after the last plot.

And here follows a completely self-running version. Simply edit the lines marked and run this script, save it to a text-file and run it with gnuplot filename from any unix-shell. You can also handle files, logged from MiniMon. Simply switch minimon to 1; if normal file, to 0. Here comes the script:

 ######## Type your configuration here ########
 canid = 8
 infile = 'MiniMonLOG.csv'
 outfile = "ploop.png"
 minimon = 1
 # Touch this only if you know, what you are doing!
 #this line prepares the logfiles
 #note: theres a difference between data logged on the car and data logged from MiniMon
 if(minimon) i_string = sprintf("< gawk -F\\; '{ gsub(/\\\"|:|\\.|[:blank:]/,\"\", $1); gsub(/\\\"|:|\\.|[:blank:]/,\"\",$2); s2 = strtonum(sprintf(\"0x%s\",$2)); gsub(/\\\"|:|\\.|blank:/,\"\",$5); s3 = strtonum(sprintf(\"0x%s\",$5)); printf \"%s\\n\",$1,s2,s3 }' %s | sort | grep \";%d;\"", "%s", "%s", "%s;%s;%s", infile, canid); else i_string = sprintf("< grep ';%d;' '%s'", canid, infile)
 # The above code has to be in a single line!
 #initializing output
 set terminal png large size 1280,1024
 set output outfile
 set grid
 set xlabel 'Value'
 set ylabel 'Time'
 set title 'Messages sent via CAN'
 unset key
 set datafile separator ';'
 #and plot data, prepared some lines above
 plot [:] [:] i_string using 1:3 w lines

This has been tested under Windows XP with Cygwin and Gnuplot version 4. You have to change a bit to get it run in older versions of Gnuplot. But I think you should have no problems, running it on Gnuplot for windows or on a real Linux System.

You can get further information on and download gnuplot here ([1]


Actorboard, Revision 1.2

The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:

  1. Steering (servo)
  2. Throttle (brushless motor controller)
  3. Brake Front Left (servo)
  4. Brake Front Right (servo)

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 through 0x25) or processed values from the Controlboard (CAN ids 0x122 through 0x125) as inputs. On the CAN bus, it announces the current selection with a periodic message. See CANID_THROTTLE, CANID_BRAKEFL and CANID_BRAKEFR and CANID_STEERING for more information about this ECU's input signals.

Based on the value from the CAN bus, the ECU implements the following features:

  • No PWM signals are produced for a fixed period of time (default: 200ms) if a SensorBoard has sent a PWM error message
  • If the last PWM message for one output is outdated (default: >100ms old), the respective channel stops generating a signal. To avoid damage to the Servos by shutting down the output signal too rapidly, it then generates a ramp towards the neutral PWM signal. The "SIGNAL" LED indicates the soundness of the 4 input channels by glowing for 5ms every 20ms if the respective channel is currently generating a PWM output. (Meaning that the LED is off if no channel does anything an completely on if all channels have valid data).
  • A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals and LEDs to indicate that state. The selection is global for all channels.