ConceptCar - User contributions [en]

ECUs implementing Sensorboards and Actorboard

2010-04-28T14:41:52Z

Stefan: /* Plotting the logged Data */

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 [[Electronic_System|Section Electronic_System]] in the Input and Output Processing levels of the Figure 1.3.

==The AT90CAN128 board==

The AT90CAN128 board is composed by 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 [[Bibliography|[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.

Table 1.2 presents the CAN messages for the Sensorboard steering.

{| border="1"
|+ '''Table 1.2: Sensorboard Steering's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x025 || Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_2_eq1.JPG]]
|-
| 0x00a || Wheel speed (ω) from rear left wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq2.JPG]]
|-
| 0x009 || Wheel speed (ω) from the front right wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq3.JPG]]
|}

==Sensorboard Throttle==

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.

Table 1.3 presents the CAN messages for the Sensorboard Throttle.

{| border="1"
|+ '''Table 1.3: Sensorboard Throttle's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x022 || Desired throttle value for the engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_3_eq1.JPG]]
|-
| 0x008 || Wheel speed (ω) from front left wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq2.JPG]]
|-
| 0x00b || Wheel speed (ω) from the rear right wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq3.JPG]]
|}

==Sensorboard Distance==

This ECU accesses the distance sensors over an I²C-Bus. It features safety architecture, described in [[Bibliography|[Zim09]]].

Table 1.4 presents the CAN message for the Sensorboard Distance.

{| border="1"
|+ '''Table 1.4: Sensorboard Distance's CAN message'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x030 || Distance (d) to the next obstacle up front. || 65ms || align="center" width="150px" | [[Image:Table2_4_eq1.JPG]]
|}

==Sensorboard Acceleration & Datalogging==

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. [[Image:Inertialboard_sensors.png|right|frame|Sensors for acceleration and yaw rate. Arrows indicate positive values.]]

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.

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.

Due to a design failure in revision 1.2, the display is mounted at the bottom side of the sensor board. This will be corrected in the next revision.

* 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.
* 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.

{| border="1"
|+ '''Table 1.5: Sensorboard Acceleration's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x010 || Longitudinal Acceleration (ax) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (ay) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq2.JPG]]
|-
| 0x012 || Rotation (ω) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq3.JPG]]
|-
| 0x00d || Voltage (U) of the electrical system’s battery || 200ms || align="center" width="150px" | [[Image:Table2_5_eq4.JPG]]
|}

====Data Logging====

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.

;LED "LOGGER ON"
:When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
;LED "LOGGER WRI"
: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/mmcblk0 is your MMC/SD card device,

> 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 (gnuplot.info)[http://gnuplot.info]

==Actorboard==
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.

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 and 0x25) or processed values from the Controlboard (CAN ids 0x122 and 0x125) as inputs.

Based on the value from the CAN bus, the ECU implements the following features:
* Entering a safe mode, i.e. producing a PWM signal that makes the car stop if one of these conditions hold:
** A Sensor Board detects a malformed PWM input signal and throws an error message on the CAN bus
** No new values arrive from the CAN bus (lost connectivity)
* A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals.

As described above, the Concept has two actuators, throttle motor and the steering servo.

* Throttle
**The brushless controller gets as input a PWM signal generated by the Actuator Board based on the received CAN messages.
* Steering Servo
**Steering is performed by a steering jumbo-servo that turns both front wheels. The steering servo directly processes the PWM signal that is generated by the Actuator Board.

Table 1.6 presents the CAN messages for the Actorboard.

{| border="1"
|+ '''Table 1.6: Actorboard's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x020 || Selected source for actuator control. The source can be selected with the switch on the Actorboard. || 1s || align="center" width="150px" | [[Image:Table2_6_eq1.JPG]]
|}

ECUs implementing Sensorboards and Actorboard

2010-04-28T10:05:09Z

Stefan: /* Plotting the logged Data */

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 [[Electronic_System|Section Electronic_System]] in the Input and Output Processing levels of the Figure 1.3.

==The AT90CAN128 board==

The AT90CAN128 board is composed by 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 [[Bibliography|[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.

Table 1.2 presents the CAN messages for the Sensorboard steering.

{| border="1"
|+ '''Table 1.2: Sensorboard Steering's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x025 || Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_2_eq1.JPG]]
|-
| 0x00a || Wheel speed (ω) from rear left wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq2.JPG]]
|-
| 0x009 || Wheel speed (ω) from the front right wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq3.JPG]]
|}

==Sensorboard Throttle==

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.

Table 1.3 presents the CAN messages for the Sensorboard Throttle.

{| border="1"
|+ '''Table 1.3: Sensorboard Throttle's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x022 || Desired throttle value for the engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_3_eq1.JPG]]
|-
| 0x008 || Wheel speed (ω) from front left wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq2.JPG]]
|-
| 0x00b || Wheel speed (ω) from the rear right wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq3.JPG]]
|}

==Sensorboard Distance==

This ECU accesses the distance sensors over an I²C-Bus. It features safety architecture, described in [[Bibliography|[Zim09]]].

Table 1.4 presents the CAN message for the Sensorboard Distance.

{| border="1"
|+ '''Table 1.4: Sensorboard Distance's CAN message'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x030 || Distance (d) to the next obstacle up front. || 65ms || align="center" width="150px" | [[Image:Table2_4_eq1.JPG]]
|}

==Sensorboard Acceleration & Datalogging==

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. [[Image:Inertialboard_sensors.png|right|frame|Sensors for acceleration and yaw rate. Arrows indicate positive values.]]

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.

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.

Due to a design failure in revision 1.2, the display is mounted at the bottom side of the sensor board. This will be corrected in the next revision.

* 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.
* 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.

{| border="1"
|+ '''Table 1.5: Sensorboard Acceleration's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x010 || Longitudinal Acceleration (ax) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (ay) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq2.JPG]]
|-
| 0x012 || Rotation (ω) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq3.JPG]]
|-
| 0x00d || Voltage (U) of the electrical system’s battery || 200ms || align="center" width="150px" | [[Image:Table2_5_eq4.JPG]]
|}

====Data Logging====

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.

;LED "LOGGER ON"
:When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
;LED "LOGGER WRI"
: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/mmcblk0 is your MMC/SD card device,

> 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. Here comes the script:

######## Type your configuration here ########
canid = 16
infile = 'LOG0018.csv'
outfile = ''
##############################################
# Touch the rest only if you know, what you are doing!
i_string = sprintf("< grep ';%d;' '%s'", canid, infile);
if (outfile == "") outfile = "gplot_out.png"

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 ';'
plot [:] [:] i_string using 1:3 w lines

You can get further information on and download gnuplot here (gnuplot.info)[http://gnuplot.info]

==Actorboard==
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.

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 and 0x25) or processed values from the Controlboard (CAN ids 0x122 and 0x125) as inputs.

Based on the value from the CAN bus, the ECU implements the following features:
* Entering a safe mode, i.e. producing a PWM signal that makes the car stop if one of these conditions hold:
** A Sensor Board detects a malformed PWM input signal and throws an error message on the CAN bus
** No new values arrive from the CAN bus (lost connectivity)
* A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals.

As described above, the Concept has two actuators, throttle motor and the steering servo.

* Throttle
**The brushless controller gets as input a PWM signal generated by the Actuator Board based on the received CAN messages.
* Steering Servo
**Steering is performed by a steering jumbo-servo that turns both front wheels. The steering servo directly processes the PWM signal that is generated by the Actuator Board.

Table 1.6 presents the CAN messages for the Actorboard.

{| border="1"
|+ '''Table 1.6: Actorboard's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x020 || Selected source for actuator control. The source can be selected with the switch on the Actorboard. || 1s || align="center" width="150px" | [[Image:Table2_6_eq1.JPG]]
|}

ECUs implementing Sensorboards and Actorboard

2010-04-28T10:04:16Z

Stefan: /* Plotting the logged Data */

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 [[Electronic_System|Section Electronic_System]] in the Input and Output Processing levels of the Figure 1.3.

==The AT90CAN128 board==

The AT90CAN128 board is composed by 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 [[Bibliography|[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.

Table 1.2 presents the CAN messages for the Sensorboard steering.

{| border="1"
|+ '''Table 1.2: Sensorboard Steering's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x025 || Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_2_eq1.JPG]]
|-
| 0x00a || Wheel speed (ω) from rear left wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq2.JPG]]
|-
| 0x009 || Wheel speed (ω) from the front right wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq3.JPG]]
|}

==Sensorboard Throttle==

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.

Table 1.3 presents the CAN messages for the Sensorboard Throttle.

{| border="1"
|+ '''Table 1.3: Sensorboard Throttle's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x022 || Desired throttle value for the engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_3_eq1.JPG]]
|-
| 0x008 || Wheel speed (ω) from front left wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq2.JPG]]
|-
| 0x00b || Wheel speed (ω) from the rear right wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq3.JPG]]
|}

==Sensorboard Distance==

This ECU accesses the distance sensors over an I²C-Bus. It features safety architecture, described in [[Bibliography|[Zim09]]].

Table 1.4 presents the CAN message for the Sensorboard Distance.

{| border="1"
|+ '''Table 1.4: Sensorboard Distance's CAN message'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x030 || Distance (d) to the next obstacle up front. || 65ms || align="center" width="150px" | [[Image:Table2_4_eq1.JPG]]
|}

==Sensorboard Acceleration & Datalogging==

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. [[Image:Inertialboard_sensors.png|right|frame|Sensors for acceleration and yaw rate. Arrows indicate positive values.]]

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.

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.

Due to a design failure in revision 1.2, the display is mounted at the bottom side of the sensor board. This will be corrected in the next revision.

* 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.
* 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.

{| border="1"
|+ '''Table 1.5: Sensorboard Acceleration's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x010 || Longitudinal Acceleration (ax) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (ay) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq2.JPG]]
|-
| 0x012 || Rotation (ω) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq3.JPG]]
|-
| 0x00d || Voltage (U) of the electrical system’s battery || 200ms || align="center" width="150px" | [[Image:Table2_5_eq4.JPG]]
|}

====Data Logging====

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.

;LED "LOGGER ON"
:When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
;LED "LOGGER WRI"
: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/mmcblk0 is your MMC/SD card device,

> 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. Here comes the script:

######## Type your configuration here ########
canid = 16
infile = 'LOG0018.csv'
outfile = ''
##############################################
# Touch the rest only if you know, what you are doing!
i_string = sprintf("< grep ';%d;' '%s'", canid, infile);
if (outfile == "") outfile = "gplot_out.png"

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 ';'
plot [:] [:] i_string using 1:3 w lines

You can get further information on and download gnuplot on gnuplot.info[http://gnuplot.info]

==Actorboard==
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.

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 and 0x25) or processed values from the Controlboard (CAN ids 0x122 and 0x125) as inputs.

Based on the value from the CAN bus, the ECU implements the following features:
* Entering a safe mode, i.e. producing a PWM signal that makes the car stop if one of these conditions hold:
** A Sensor Board detects a malformed PWM input signal and throws an error message on the CAN bus
** No new values arrive from the CAN bus (lost connectivity)
* A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals.

As described above, the Concept has two actuators, throttle motor and the steering servo.

* Throttle
**The brushless controller gets as input a PWM signal generated by the Actuator Board based on the received CAN messages.
* Steering Servo
**Steering is performed by a steering jumbo-servo that turns both front wheels. The steering servo directly processes the PWM signal that is generated by the Actuator Board.

Table 1.6 presents the CAN messages for the Actorboard.

{| border="1"
|+ '''Table 1.6: Actorboard's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x020 || Selected source for actuator control. The source can be selected with the switch on the Actorboard. || 1s || align="center" width="150px" | [[Image:Table2_6_eq1.JPG]]
|}

ECUs implementing Sensorboards and Actorboard

2010-04-27T10:24:33Z

Stefan: /* Plotting the logged Data */

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 [[Electronic_System|Section Electronic_System]] in the Input and Output Processing levels of the Figure 1.3.

==The AT90CAN128 board==

The AT90CAN128 board is composed by 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 [[Bibliography|[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.

Table 1.2 presents the CAN messages for the Sensorboard steering.

{| border="1"
|+ '''Table 1.2: Sensorboard Steering's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x025 || Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_2_eq1.JPG]]
|-
| 0x00a || Wheel speed (ω) from rear left wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq2.JPG]]
|-
| 0x009 || Wheel speed (ω) from the front right wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq3.JPG]]
|}

==Sensorboard Throttle==

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.

Table 1.3 presents the CAN messages for the Sensorboard Throttle.

{| border="1"
|+ '''Table 1.3: Sensorboard Throttle's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x022 || Desired throttle value for the engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_3_eq1.JPG]]
|-
| 0x008 || Wheel speed (ω) from front left wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq2.JPG]]
|-
| 0x00b || Wheel speed (ω) from the rear right wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq3.JPG]]
|}

==Sensorboard Distance==

This ECU accesses the distance sensors over an I²C-Bus. It features safety architecture, described in [[Bibliography|[Zim09]]].

Table 1.4 presents the CAN message for the Sensorboard Distance.

{| border="1"
|+ '''Table 1.4: Sensorboard Distance's CAN message'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x030 || Distance (d) to the next obstacle up front. || 65ms || align="center" width="150px" | [[Image:Table2_4_eq1.JPG]]
|}

==Sensorboard Acceleration & Datalogging==

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. [[Image:Inertialboard_sensors.png|right|frame|Sensors for acceleration and yaw rate. Arrows indicate positive values.]]

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.

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.

Due to a design failure in revision 1.2, the display is mounted at the bottom side of the sensor board. This will be corrected in the next revision.

* 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.
* 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.

{| border="1"
|+ '''Table 1.5: Sensorboard Acceleration's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x010 || Longitudinal Acceleration (ax) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (ay) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq2.JPG]]
|-
| 0x012 || Rotation (ω) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq3.JPG]]
|-
| 0x00d || Voltage (U) of the electrical system’s battery || 200ms || align="center" width="150px" | [[Image:Table2_5_eq4.JPG]]
|}

====Data Logging====

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.

;LED "LOGGER ON"
:When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
;LED "LOGGER WRI"
: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/mmcblk0 is your MMC/SD card device,

> 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.

You can get further information on and download gnuplot on gnuplot.info[http://gnuplot.info]

==Actorboard==
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.

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 and 0x25) or processed values from the Controlboard (CAN ids 0x122 and 0x125) as inputs.

Based on the value from the CAN bus, the ECU implements the following features:
* Entering a safe mode, i.e. producing a PWM signal that makes the car stop if one of these conditions hold:
** A Sensor Board detects a malformed PWM input signal and throws an error message on the CAN bus
** No new values arrive from the CAN bus (lost connectivity)
* A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals.

As described above, the Concept has two actuators, throttle motor and the steering servo.

* Throttle
**The brushless controller gets as input a PWM signal generated by the Actuator Board based on the received CAN messages.
* Steering Servo
**Steering is performed by a steering jumbo-servo that turns both front wheels. The steering servo directly processes the PWM signal that is generated by the Actuator Board.

Table 1.6 presents the CAN messages for the Actorboard.

{| border="1"
|+ '''Table 1.6: Actorboard's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x020 || Selected source for actuator control. The source can be selected with the switch on the Actorboard. || 1s || align="center" width="150px" | [[Image:Table2_6_eq1.JPG]]
|}

ECUs implementing Sensorboards and Actorboard

2010-04-27T10:22:48Z

Stefan: /* Plotting the logged Data */

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 [[Electronic_System|Section Electronic_System]] in the Input and Output Processing levels of the Figure 1.3.

==The AT90CAN128 board==

The AT90CAN128 board is composed by 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 [[Bibliography|[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.

Table 1.2 presents the CAN messages for the Sensorboard steering.

{| border="1"
|+ '''Table 1.2: Sensorboard Steering's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x025 || Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_2_eq1.JPG]]
|-
| 0x00a || Wheel speed (ω) from rear left wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq2.JPG]]
|-
| 0x009 || Wheel speed (ω) from the front right wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq3.JPG]]
|}

==Sensorboard Throttle==

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.

Table 1.3 presents the CAN messages for the Sensorboard Throttle.

{| border="1"
|+ '''Table 1.3: Sensorboard Throttle's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x022 || Desired throttle value for the engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_3_eq1.JPG]]
|-
| 0x008 || Wheel speed (ω) from front left wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq2.JPG]]
|-
| 0x00b || Wheel speed (ω) from the rear right wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq3.JPG]]
|}

==Sensorboard Distance==

This ECU accesses the distance sensors over an I²C-Bus. It features safety architecture, described in [[Bibliography|[Zim09]]].

Table 1.4 presents the CAN message for the Sensorboard Distance.

{| border="1"
|+ '''Table 1.4: Sensorboard Distance's CAN message'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x030 || Distance (d) to the next obstacle up front. || 65ms || align="center" width="150px" | [[Image:Table2_4_eq1.JPG]]
|}

==Sensorboard Acceleration & Datalogging==

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. [[Image:Inertialboard_sensors.png|right|frame|Sensors for acceleration and yaw rate. Arrows indicate positive values.]]

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.

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.

Due to a design failure in revision 1.2, the display is mounted at the bottom side of the sensor board. This will be corrected in the next revision.

* 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.
* 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.

{| border="1"
|+ '''Table 1.5: Sensorboard Acceleration's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x010 || Longitudinal Acceleration (ax) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (ay) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq2.JPG]]
|-
| 0x012 || Rotation (ω) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq3.JPG]]
|-
| 0x00d || Voltage (U) of the electrical system’s battery || 200ms || align="center" width="150px" | [[Image:Table2_5_eq4.JPG]]
|}

====Data Logging====

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.

;LED "LOGGER ON"
:When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
;LED "LOGGER WRI"
: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/mmcblk0 is your MMC/SD card device,

> 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

before the first plot.

You can get further information on and download gnuplot on gnuplot.info[http://gnuplot.info]

==Actorboard==
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.

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 and 0x25) or processed values from the Controlboard (CAN ids 0x122 and 0x125) as inputs.

Based on the value from the CAN bus, the ECU implements the following features:
* Entering a safe mode, i.e. producing a PWM signal that makes the car stop if one of these conditions hold:
** A Sensor Board detects a malformed PWM input signal and throws an error message on the CAN bus
** No new values arrive from the CAN bus (lost connectivity)
* A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals.

As described above, the Concept has two actuators, throttle motor and the steering servo.

* Throttle
**The brushless controller gets as input a PWM signal generated by the Actuator Board based on the received CAN messages.
* Steering Servo
**Steering is performed by a steering jumbo-servo that turns both front wheels. The steering servo directly processes the PWM signal that is generated by the Actuator Board.

Table 1.6 presents the CAN messages for the Actorboard.

{| border="1"
|+ '''Table 1.6: Actorboard's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x020 || Selected source for actuator control. The source can be selected with the switch on the Actorboard. || 1s || align="center" width="150px" | [[Image:Table2_6_eq1.JPG]]
|}

ECUs implementing Sensorboards and Actorboard

2010-04-27T10:21:07Z

Stefan: /* Plotting the logged Data */

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 [[Electronic_System|Section Electronic_System]] in the Input and Output Processing levels of the Figure 1.3.

==The AT90CAN128 board==

The AT90CAN128 board is composed by 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 [[Bibliography|[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.

Table 1.2 presents the CAN messages for the Sensorboard steering.

{| border="1"
|+ '''Table 1.2: Sensorboard Steering's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x025 || Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_2_eq1.JPG]]
|-
| 0x00a || Wheel speed (ω) from rear left wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq2.JPG]]
|-
| 0x009 || Wheel speed (ω) from the front right wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq3.JPG]]
|}

==Sensorboard Throttle==

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.

Table 1.3 presents the CAN messages for the Sensorboard Throttle.

{| border="1"
|+ '''Table 1.3: Sensorboard Throttle's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x022 || Desired throttle value for the engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_3_eq1.JPG]]
|-
| 0x008 || Wheel speed (ω) from front left wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq2.JPG]]
|-
| 0x00b || Wheel speed (ω) from the rear right wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq3.JPG]]
|}

==Sensorboard Distance==

This ECU accesses the distance sensors over an I²C-Bus. It features safety architecture, described in [[Bibliography|[Zim09]]].

Table 1.4 presents the CAN message for the Sensorboard Distance.

{| border="1"
|+ '''Table 1.4: Sensorboard Distance's CAN message'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x030 || Distance (d) to the next obstacle up front. || 65ms || align="center" width="150px" | [[Image:Table2_4_eq1.JPG]]
|}

==Sensorboard Acceleration & Datalogging==

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. [[Image:Inertialboard_sensors.png|right|frame|Sensors for acceleration and yaw rate. Arrows indicate positive values.]]

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.

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.

Due to a design failure in revision 1.2, the display is mounted at the bottom side of the sensor board. This will be corrected in the next revision.

* 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.
* 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.

{| border="1"
|+ '''Table 1.5: Sensorboard Acceleration's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x010 || Longitudinal Acceleration (ax) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (ay) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq2.JPG]]
|-
| 0x012 || Rotation (ω) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq3.JPG]]
|-
| 0x00d || Voltage (U) of the electrical system’s battery || 200ms || align="center" width="150px" | [[Image:Table2_5_eq4.JPG]]
|}

====Data Logging====

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.

;LED "LOGGER ON"
:When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
;LED "LOGGER WRI"
: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/mmcblk0 is your MMC/SD card device,

> 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

multiplot

before or after the first plot.

You can get further information on and download gnuplot on gnuplot.info[http://gnuplot.info]

==Actorboard==
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.

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 and 0x25) or processed values from the Controlboard (CAN ids 0x122 and 0x125) as inputs.

Based on the value from the CAN bus, the ECU implements the following features:
* Entering a safe mode, i.e. producing a PWM signal that makes the car stop if one of these conditions hold:
** A Sensor Board detects a malformed PWM input signal and throws an error message on the CAN bus
** No new values arrive from the CAN bus (lost connectivity)
* A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals.

As described above, the Concept has two actuators, throttle motor and the steering servo.

* Throttle
**The brushless controller gets as input a PWM signal generated by the Actuator Board based on the received CAN messages.
* Steering Servo
**Steering is performed by a steering jumbo-servo that turns both front wheels. The steering servo directly processes the PWM signal that is generated by the Actuator Board.

Table 1.6 presents the CAN messages for the Actorboard.

{| border="1"
|+ '''Table 1.6: Actorboard's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x020 || Selected source for actuator control. The source can be selected with the switch on the Actorboard. || 1s || align="center" width="150px" | [[Image:Table2_6_eq1.JPG]]
|}

ECUs implementing Sensorboards and Actorboard

2010-04-27T10:13:30Z

Stefan: /* Data Logging */

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 [[Electronic_System|Section Electronic_System]] in the Input and Output Processing levels of the Figure 1.3.

==The AT90CAN128 board==

The AT90CAN128 board is composed by 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 [[Bibliography|[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.

Table 1.2 presents the CAN messages for the Sensorboard steering.

{| border="1"
|+ '''Table 1.2: Sensorboard Steering's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x025 || Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_2_eq1.JPG]]
|-
| 0x00a || Wheel speed (ω) from rear left wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq2.JPG]]
|-
| 0x009 || Wheel speed (ω) from the front right wheel || 50ms || align="center" width="150px" | [[Image:Table2_2_eq3.JPG]]
|}

==Sensorboard Throttle==

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.

Table 1.3 presents the CAN messages for the Sensorboard Throttle.

{| border="1"
|+ '''Table 1.3: Sensorboard Throttle's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x022 || Desired throttle value for the engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. || Radio receiver’s frequency, 20ms typ. || align="center" width="150px" | [[Image:Table2_3_eq1.JPG]]
|-
| 0x008 || Wheel speed (ω) from front left wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq2.JPG]]
|-
| 0x00b || Wheel speed (ω) from the rear right wheel || 50ms || align="center" width="150px" | [[Image:Table2_3_eq3.JPG]]
|}

==Sensorboard Distance==

This ECU accesses the distance sensors over an I²C-Bus. It features safety architecture, described in [[Bibliography|[Zim09]]].

Table 1.4 presents the CAN message for the Sensorboard Distance.

{| border="1"
|+ '''Table 1.4: Sensorboard Distance's CAN message'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x030 || Distance (d) to the next obstacle up front. || 65ms || align="center" width="150px" | [[Image:Table2_4_eq1.JPG]]
|}

==Sensorboard Acceleration & Datalogging==

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. [[Image:Inertialboard_sensors.png|right|frame|Sensors for acceleration and yaw rate. Arrows indicate positive values.]]

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.

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.

Due to a design failure in revision 1.2, the display is mounted at the bottom side of the sensor board. This will be corrected in the next revision.

* 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.
* 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.

{| border="1"
|+ '''Table 1.5: Sensorboard Acceleration's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x010 || Longitudinal Acceleration (ax) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (ay) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq2.JPG]]
|-
| 0x012 || Rotation (ω) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq3.JPG]]
|-
| 0x00d || Voltage (U) of the electrical system’s battery || 200ms || align="center" width="150px" | [[Image:Table2_5_eq4.JPG]]
|}

====Data Logging====

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.

;LED "LOGGER ON"
:When this LED is on, the SD card is present, has been detected and the file could be opened for writing.
;LED "LOGGER WRI"
: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/mmcblk0 is your MMC/SD card device,

> 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.

You can get further information on and download gnuplot on gnuplot.info[http://gnuplot.info]

==Actorboard==
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.

With a switch, the board can be toggled to use either the radio receiver decoders’ data from the Sensorboards (CAN ids 0x22 and 0x25) or processed values from the Controlboard (CAN ids 0x122 and 0x125) as inputs.

Based on the value from the CAN bus, the ECU implements the following features:
* Entering a safe mode, i.e. producing a PWM signal that makes the car stop if one of these conditions hold:
** A Sensor Board detects a malformed PWM input signal and throws an error message on the CAN bus
** No new values arrive from the CAN bus (lost connectivity)
* A hardware switch to select different CAN-IDs and by these different sources for the generated PWM signals.

As described above, the Concept has two actuators, throttle motor and the steering servo.

* Throttle
**The brushless controller gets as input a PWM signal generated by the Actuator Board based on the received CAN messages.
* Steering Servo
**Steering is performed by a steering jumbo-servo that turns both front wheels. The steering servo directly processes the PWM signal that is generated by the Actuator Board.

Table 1.6 presents the CAN messages for the Actorboard.

{| border="1"
|+ '''Table 1.6: Actorboard's CAN messages'''
! CAN ID !! Semantics !! Interval !! Conversion
|-
| 0x020 || Selected source for actuator control. The source can be selected with the switch on the Actorboard. || 1s || align="center" width="150px" | [[Image:Table2_6_eq1.JPG]]
|}

ECUs Emergency

2010-04-23T09:21:12Z

Stefan: /* Usage */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode.

The current mode is shown on the EmergencyLED which is switched on when in stop mode, and off when in running mode.

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====
The SHR-7 Decoder receives signals via the 433,920 MHz band and decodes them to a digital signal (shown in the next section).

Technical Data:
* Sending via 433,920 MHz
* Bandwidth: 20 Hz to 2kHz
* Current: 7 to 14 V DC
* Power consumption: 6,4mA

For more Information read [[Image:Shr7.pdf|this documentation (PDF)]]

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T09:16:44Z

Stefan: /* SHR7 Decoder/Transmitter */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====
The SHR-7 Decoder receives signals via the 433,920 MHz band and decodes them to a digital signal (shown in the next section).

Technical Data:
* Sending via 433,920 MHz
* Bandwidth: 20 Hz to 2kHz
* Current: 7 to 14 V DC
* Power consumption: 6,4mA

For more Information read [[Image:Shr7.pdf|this documentation (PDF)]]

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T09:12:12Z

Stefan: /* SHR7 Decoder/Transmitter */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====
The SHR-7 Decoder receives signals via the 433,920 MHz band and decodes them to a digital signal.

Technical Data:
* Sending via 433,920 MHz
* Bandwidth: 20 Hz to 2kHz
* Current: 7 to 14 V DC
* Power consumption: 6,4mA

For more Information read [[Image:Shr7.pdf|this documentation (PDF)]]

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T09:11:55Z

Stefan: /* SHR7 Decoder/Transmitter */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====
The SHR-7 Decoder receives signals via the 433,920 MHz band and decodes them to a digital signal.

Technical Data:
* Sending via 433,920 MHz
* Bandwidth: 20 Hz to 2kHz
* Current: 7 to 14 V DC
* Power consumption: 6,4mA

For more Information read [[Shr7.pdf|this documentation (PDF)]]

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T09:11:19Z

Stefan: /* SHR7 Decoder/Transmitter */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====
The SHR-7 Decoder receives signals via the 433,920 MHz band and decodes them to a digital signal.

Technical Data:
* Sending via 433,920 MHz
* Bandwidth: 20 Hz to 2kHz
* Current: 7 to 14 V DC
* Power consumption: 6,4mA

For more Information read [[Image:Shr7.pdf|this documentation (PDF)]]

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T09:10:53Z

Stefan: /* SHR7 Decoder/Transmitter */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====
The SHR-7 Decoder receives signals via the 433,920 MHz band and decodes them to a digital signal.

Technical Data:
* Sending via 433,920 MHz
* Bandwidth: 20 Hz to 2kHz
* Current: 7 to 14 V DC
* Power consumption: 6,4mA

For more Information read [[File:Shr7.pdf|this documentation (PDF)]]

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

File:Shr7.pdf

2010-04-23T09:10:33Z

Stefan:

ECUs Emergency

2010-04-23T09:10:03Z

Stefan: /* SHR7 Decoder/Transmitter */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====
The SHR-7 Decoder receives signals via the 433,920 MHz band and decodes them to a digital signal.

Technical Data:
* Sending via 433,920 MHz
* Bandwidth: 20 Hz to 2kHz
* Current: 7 to 14 V DC
* Power consumption: 6,4mA

For more Information read [[File:shr7.pdf|this documentation (PDF)]]

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

File:Shr7 decoder sm.png

2010-04-23T08:46:22Z

Stefan: uploaded a new version of "Image:Shr7 decoder sm.png"

ECUs Emergency

2010-04-23T08:45:26Z

Stefan: /* Prove correct order and validity of received characters through State Machine and decode */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small. But you must be sure, to never get stuck in a state, that does no reading from the buffer.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T08:43:55Z

Stefan: /* Prove correct order and validity of received characters through State Machine and decode */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

In the source code, the input tape is represented by a ring buffer "inputTape". Due to the definite higher frequency of the main loop, this buffer can be very small.

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T08:36:36Z

Stefan: /* Switch the cars running state */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).
The mode switching is done via two self describing functions setStartMode() and setStopMode().

ECUs Emergency

2010-04-23T08:35:35Z

Stefan: /* State: CHANGE_CAR_STATE */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. This is further described in the next section.
This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T08:34:59Z

Stefan: /* State: ERROR */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. But we don't have to switch mode, if there is nothing to change. So two events lead to a change of mode: Car is in stop mode and three buttons have been pushed; or car is in start mode an any buttons have been pushed (the variable with informations about the buttons, has been set in GETBFLAG).
The functions for starting and stopping the car are setStartMode() and setStopMode().

This states only transition is to INIT with no input.

===== State: ERROR =====
In this state errors and invalid inputs can be catched. At the moment, this state simply gives a short signal to the EmergencyLED.
After that, state is again switched to INIT.

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T08:25:49Z

Stefan: /* State: CHANGE_CAR_STATE */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
In this state, we decide whether to set the car to start, or to stop mode. But we don't have to switch mode, if there is nothing to change. So two events lead to a change of mode: Car is in stop mode and three buttons have been pushed; or car is in start mode an any buttons have been pushed (the variable with informations about the buttons, has been set in GETBFLAG).
The functions for starting and stopping the car are setStartMode() and setStopMode().

This states only transition is to INIT with no input.

===== State: ERROR =====

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T08:09:10Z

Stefan: /* State: ENDSYNC */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
The last receiving state waits until "00" is sent via the tape. If successfull, switch to CHANGE_CAR_STATE, otherwise switch to ERROR.

===== State: CHANGE_CAR_STATE =====
===== State: ERROR =====

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T08:08:02Z

Stefan: /* State: GETBFLAG */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
This State waits until three characters '0','+' or '-' are received. These three characters represent the buttons that are pushed on the transmitter. These characters are saved to a variable, because they are needed in state CHANGE_CAR_STATE.

State is switched to ENDSYNC if nothing bad happened; or to ERROR if so.

===== State: ENDSYNC =====
===== State: CHANGE_CAR_STATE =====
===== State: ERROR =====

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T08:05:20Z

Stefan: /* State: MIDSYNC */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
MIDSYNC State awaits for signals for middle synchronization. Three times '0' and the last character is '-'. If an error occurs, in the case of an invalid character, state will switch to ERROR; else to the next State GETBFLAG.

===== State: GETBFLAG =====
===== State: ENDSYNC =====
===== State: CHANGE_CAR_STATE =====
===== State: ERROR =====

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T07:58:41Z

Stefan: /* State: STARTSYNC */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape. After receiving 'S', state will be changed to GETID.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
===== State: GETBFLAG =====
===== State: ENDSYNC =====
===== State: CHANGE_CAR_STATE =====
===== State: ERROR =====

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T07:58:07Z

Stefan: /* State: GETID */

The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, so it will still work, when the other systems don't work any more.
The Emergency Signal is given by an extra radio transmitter, sending on a frequency other then the main control unit.

=== Usage ===
Pushing any of the 3 Buttons on the emergency remote control sets the car in a stop mode. Changes on the main remote control do not affect the cars state. Only if all 3 Buttons are pushed on the emergency remote control, the car will leave the stop mode and reset to running mode. At

== How the Emergency Board works ==

The Emergency Board sits between the acceleration and the steering control boards, and the active parts (motor and steering). If an emergency signal arrives, the signals that come from the control boards are being replaced with stop signals generated from the emergency board itself. The replacement is done by simply switching a multiplexer.

The signal transmitting part works with a SHR7 decoder board and a fully assembled transmitter unit. The decoder board receives the signal from the transmitter and generates a code that contains information on the sending device and on which buttons on the 3-button-control were pushed.

=== Electrical Information ===
==== Emergency Board ====
==== SHR7 Decoder/Transmitter ====

=== Software Component ===
The main task of the software running on the Atmega88 is to decode the signals from the shr7 decoder and decide whether to switch the running/stop state.

The hole process is split into three main parts:
* Analyze signals arriving from the shr7 decoder
* Prove signals arrive in correct order and decode signals
* Switch the state of the car (run - stop)

==== Analyze signals arriving from the shr7 decoder ====
The signals arriving from the shr7 decoder can be split to 4 different codes, as shown in the next Figure:

[[Image:Shr7_decoder_timings.png]]
;Synchronization (S)
: The signal is lead by a synchronization preamble. Before each signal, there is a high-signal period of at least two long signal-time-periods.
;-, +, 0
: Each of the other signals - in the further text, referred to as characters - are represented by the times between 4 signal rise and falls.

The decoding is done by a interrupt service routine, that is called every time, a change of the incoming signal from the shr7 decoder occurs. The service routine measures the time between each call. After measuring enough times (9 or 4), the routine can decide whether a synchronization, a plus, a minus or a zero character has been sent.
The received characters are then written to the State Machine input tape (discussed later on).

==== Prove correct order and validity of received characters through State Machine and decode ====
Each packet from the shr7 decoder can be split up into 5 parts:
* One character Start Synchronization
* Nine characters Identification of the transmitter (8 chars ID + 1 syn)
* Four characters Middle Synchronization
* Three characters each representing the
* Two characters end synchronization
These parts can be represented by states in a state machine:

[[Image:Shr7_decoder_sm.png]]

===== State: INIT =====
Initialization State resets all values. Its only transition is to the STARTSYNC State via an empty input (eps).

===== State: STARTSYNC =====
The Startsynchronization State waits (no active waiting) until the character 'S' (for Synchronization) was sent to the tape.

===== State: GETID =====
After Synchronization was sent, GETID awaits 9 characters to be sent. For characters 1 to 5 and 7 to 9 values '+','-' and '0' are valid, for character 6 only '-' will lead to success. If this State was passed successfully, the state will switch to MIDSYNC. If an error occured, state will switch to ERROR State.

===== State: MIDSYNC =====
===== State: GETBFLAG =====
===== State: ENDSYNC =====
===== State: CHANGE_CAR_STATE =====
===== State: ERROR =====

==== Switch the cars running state ====
In SM state "CHANGE_CAR_STATE" we decide whether to start or stop the car, depending on the number of buttons pushed at the time and on the current state of the car (you don't need to set the car stop mode multiple times).
If switching from run to stop mode, the incoming control signal from the control boards, are being replaced by the boards own stop signal (corresponding PWM signal described in earlier section). Therefore the pin, connected to the control signal MUX is set to Vcc (1).
If switching from stop to run mode, this procedure is simply repeated reverse (Set MUX pin to Gnd (0)).

ECUs Emergency

2010-04-23T07:54:50Z

Stefan: /* State: STARTSYNC */

ECUs Emergency

2010-04-23T07:53:16Z

Stefan: /* State: INIT */

Main Page

2010-04-23T07:51:19Z

Stefan: /* WELCOME */

==WELCOME==

So here it is established, the Concept Car's wiki.

The Concept Car, presented in Figure 1.1, is an experimental embedded system. It is a research platform based on a remote control car and several resources allowing deployment of different classes of applications. The Car is a 1:5 scale radio controlled remote control car that is - depending on the ground conditions - capable of driving at a speed of up to 50 km/h.

:[[image:ConceptCarside.jpg|800px|Figure 1.1. Board Dimensions]]

This wiki describes the Concept Car, its structure, components, software and hardware architecture and functionalities and presents in a detailed way how to develop and deploy applications for the car.

The corresponding SVN can be accessed in [[Svn|this way]]. This should be a gathering point for all documentation.

*[[CCar_Architecture|1 - Concept Car Architecture]]
**[[Mechanical_System|1.1 - Mechanical System]]
***[[Mechanical_System#Engine|1.1.1 - Engine]]
***[[Mechanical_System#Radio_Control|1.1.2 - Radio Control]]
***[[Mechanical_System#Steering_System|1.1.3 - Steering System]]
**[[Power_Supply|1.2. Power Supply]]
**[[Electronic_System|1.3 - Electronic System]]
***[[CAN_Bus|1.3.1 - CAN Bus]]
***[[Sensors|1.3.2 - Sensors]]
***[[Electronic Control Units|1.3.3 - Electronic Control Units]]
****[[ECUs implementing Sensorboards and Actorboard|1.3.3.1 - ECUs implementing Sensorboards and Actorboard]]
****[[ECU implementing Controlboard|1.3.3.2 - ECU implementing Controlboard]]
****[[ECUs Emergency|1.3.3.3 - ECUs implementing Emergencyboard]]

*[[Application Development and Deployment|2 - Application development and deployment]]
**[[Platform Independent Application Development|2.1 - Platform Independent Application Development]]
***[[Platform Independent Application Development#2.1.1. Simulink_Models|2.1.1 - Simulink models]]
****[[Platform Independent Application Development#Software Application Code Generation|2.1.1.1 - Software Application Code Generation]]
**[[Platform Specific Code Generation|2.2 - Platform Specific Code Generation]]
**[[Application Deployment|2.3 - Application Deployment]]
***[[Flashing_the_ARM7_board|2.3.1 - Flashing the ARM7 board]]
***[[Deployment|2.3.2 - Deployment]]
***[[The_Cortex_M3_board|2.3.2 - About the newer Cortex M3 board]]

*[[Adding Resources to the Concept Car|3 - Adding Resources to the Concept Car]]

*[[Bibliography|4 - Bibliography]]

-------------------------------------------------------------------------------------------------------------------
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

== Getting started ==
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

ECUs Emergency

2010-04-21T12:47:17Z

Stefan:

ECUs Emergency

2010-04-21T12:41:38Z

Stefan:

ECUs Emergency

2010-04-21T12:16:57Z

Stefan: /* Prove correct order and validity of received characters through State Machine and decode */

File:Shr7 decoder sm.png

2010-04-21T12:16:04Z

Stefan:

ECUs Emergency

2010-04-21T12:02:51Z

Stefan: /* Software Component */

File:Shr7 decoder timings.png

2010-04-21T11:21:09Z

Stefan:

ECUs Emergency

2010-04-21T09:07:19Z

Stefan:

ECUs Emergency

2010-04-21T08:59:03Z

Stefan: New page: The Emergency Break Board gives a chance to remote stop the car. It is mostly independent from the other parts. Also its electric circuit is not connected to the main power supply system, ...