ConceptCar - User contributions [en]

ECUs implementing Sensorboards and Actorboard

2010-02-18T10:36:48Z

153.96.133.33:

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 (a<sub>x</sub>) || 50ms || align="center" width="150px" | [[Image:Table2_5_eq1.JPG]]
|-
| 0x011 || Lateral Acceleration (a<sub>y</sub>) || 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.

==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]]
|}

Adding Resources to the Concept Car

2009-10-21T11:19:19Z

153.96.133.33:

The Concept Car has a modular architecture allowing the addition of resources in a simple way. In order to integrate a new element in the Car architecture it is necessary to integrate it to a new AT90CAN128 board. The AT90CAN128 boards are the interface between the sensors and actuators (i.e. the environment) and the Concept Car's CAN bus. Their main purpose is to do low level tasks, like PWM de- and encoding.

The characteristics of the AT90CAN128 boards are presented in the following.

==Board Dimensions==

[[image:StackableBoardLayout.png|thumb|200px|Figure 4.1. Board Dimensions]]

All boards featuring an AT90CAN128 microcontroller are supposed to fit into any of the 8 spaces at the CAN bus box. Therefore they share the same dimensions, drill holes for mounting and SUB-D jack position. They all have the same dimensions to be interchangeable in place.

This dimensions are precisely the same used for the SensorBoards in the old Hardware Revision 1.0, all Revisions >= 1.2 must comply with these dimensions.

Since the boards can be stacked, it is a good idea to place all connectors, switches and LEDs near the borders.

Figure 4.1 presents the board dimensions.

===Schematic===

First apply this in the schematic:
* Add the 4 drill holes as parts ''MOUNT-HOLE3.0''
* The SUB-D CAN connector must be of type ''F09H''

===Board===

To get a proper board, follow these steps in eagle (when starting from scratch):
# Set the grid to ''1mm''
# Move the edges of the dimension polygon so that it's a square of 73mm x 73mm, with its origin being in the bottom left edge.
# Move the drill holes to the positions 4mm apart from each edge
# Rotate the SUB-D CAN connector to face upwards and move it to position 37.506mm/60.88mm. <tt>MOVE CAN_BUS (37.506mm 60.88mm)</tt> would do this.

==Operational Controls==

[[image:Actorboard_boardDesignIllustration.png|thumb|350px|Figure 4.2. An example of good placement of the operational controls and of their labeling.]]

These are recommendations on what operational controls to use to supply a uniform look&feel (and in some aspects programming) of the sensor- and actor-boards. The placement is not critical, it just looks better this way.

* The CAN bus driver is designed to signal the bus state with 2 LEDs (a green one for ''error active'' state and a red one for ''bus off'' state). Those LEDs are attached to I/O-Pins PA7 (red LED) and PA6 (green LED), over a resistor of 220 Ohms to ground each. The LEDs (package: <tt>CHIP-LED0805</tt>) should be placed as follows:
** suggested position for green LED: 1250x200mil, parallel to side
** suggested position for red LED: 1075x200mil, parallel to side
* A green power on LED (<tt>CHIP-LED0805</tt>) that is directly attached to the power supply is recommended. It should be placed at 850x200mil, parallel to side (next to the CAN LEDs), with a resistor of 220 Ohms.
* The reset switch (<tt>10-XX</tt>) should be placed near the boarder at 550x275mil.
* The ISP and JTAG adapters (both <tt>ML10L</tt>) should be placed at 2450x800mil (JTAG) and 2450x1610mil (ISP). ISP is mandatory, but JTAG can be omitted.
* If any additional LEDs are required, they should be placed at the lower border, like the CAN LEDs 200mil away from it.
* Connectors to peripherals or other boards must be low enough to avoid trouble with other boards in the stack. Recommended type is for example <tt>L02P</tt>, <tt>L03P</tt>, <tt>L05P</tt>.

Adding Resources to the Concept Car

2009-10-21T11:15:56Z

153.96.133.33:

The Concept Car has a modular architecture allowing the addition of resources in a simple way. In order to integrate a new element in the Car architecture it is necessary to integrate it to a new AT90CAN128 board. The AT90CAN128 boards are the interface between the sensors and actuators (i.e. the environment) and the Concept Car's CAN bus. Their main purpose is to do low level tasks, like PWM de- and encoding.

The characteristics of the AT90CAN128 boards are presented in the following.

==Board Dimensions==

[[image:StackableBoardLayout.png|thumb|200px|Figure 4.1. Board Dimensions]]

All boards featuring an AT90CAN128 microcontroller are supposed to fit into any of the 8 spaces at the CAN bus box. Therefore they share the same dimensions, drill holes for mounting and SUB-D jack position. They all have the same dimensions to be interchangeable in place.

This dimensions are precisely the same used for the SensorBoards in the old Hardware Revision 1.0, all Revisions >= 1.2 must comply with these dimensions.

Since the boards can be stacked, it is a good idea to place all connectors, switches and LEDs near the borders.

Figure 4.1 presents the board dimensions.

===Schematic===

First apply this in the schematic:
* Add the 4 drill holes as parts ''MOUNT-HOLE3.0''
* The SUB-D CAN connector must be of type ''F09H''

===Board===

To get a proper board, follow these steps in eagle (when starting from scratch):
# Set the grid to ''1mm''
# Move the edges of the dimension polygon so that it's a square of 73mm x 73mm, with its origin being in the bottom left edge.
# Move the drill holes to the positions 4mm apart from each edge
# Rotate the SUB-D CAN connector to face upwards and move it to position 37.506mm/60.88mm. <tt>MOVE CAN_BUS (37.506mm 60.88mm)</tt> would do this.

==Operational Controls==

[[image:Actorboard_boardDesignIllustration.png|thumb|350px|An example of good placement of the operational controls and of their labeling.]]

These are recommendations on what operational controls to use to supply a uniform look&feel (and in some aspects programming) of the sensor- and actor-boards. The placement is not critical, it just looks better this way.

* The CAN bus driver is designed to signal the bus state with 2 LEDs (a green one for ''error active'' state and a red one for ''bus off'' state). Those LEDs are attached to I/O-Pins PA7 (red LED) and PA6 (green LED), over a resistor of 220 Ohms to ground each. The LEDs (package: <tt>CHIP-LED0805</tt>) should be placed as follows:
** suggested position for green LED: 1250x200mil, parallel to side
** suggested position for red LED: 1075x200mil, parallel to side
* A green power on LED (<tt>CHIP-LED0805</tt>) that is directly attached to the power supply is recommended. It should be placed at 850x200mil, parallel to side (next to the CAN LEDs), with a resistor of 220 Ohms.
* The reset switch (<tt>10-XX</tt>) should be placed near the boarder at 550x275mil.
* The ISP and JTAG adapters (both <tt>ML10L</tt>) should be placed at 2450x800mil (JTAG) and 2450x1610mil (ISP). ISP is mandatory, but JTAG can be omitted.
* If any additional LEDs are required, they should be placed at the lower border, like the CAN LEDs 200mil away from it.
* Connectors to peripherals or other boards must be low enough to avoid trouble with other boards in the stack. Recommended type is for example <tt>L02P</tt>, <tt>L03P</tt>, <tt>L05P</tt>.

CAN IDs

2009-10-16T07:34:19Z

153.96.133.33: /* CANid_WheelSpeedXX */

This document describes the messages used to transport sensor and actuator information over the ConceptCar CAN Bus. All information regarding the CAN Messages such as IDs, data width, payload and semantics are defined in this document.

==CAN bus operation==

* The CAN bus is operated in CAN 2.0A mode. No component is expected to put 2.0B messages on the bus.
* The Speed is 1MBit/s highspeed.
* The bit timing is 75%.

==Data format==

To establish a convenient and simple way of data interchange between different components on different platforms communicating over the bus, there is a unique data format for interchange here. All data passed over the CAN bus must be packed into a 4 Byte CAN message whose contents are interpreted as one 4 Byte unsigned integer variable. The byte order inside each of these CAN messages is as usual on the CAN bus: lowest byte first.

As an example, the value 0x12345678 is sent over the bus 0x78, 0x56, 0x34, 0x12.

If the value can't be directly evaluated, a linear marshaling function has to be defined here. Other marshaling functions than linear ones are '''not allowed'''.

==CAN IDs and Description==

In this section the CAN IDs used by the concept car are defined and a brief description of them is given. Later on the semantics of each message is defined.

{| border="1"
|+ '''Table 1: CAN ID Definition'''
! CAN ID !! Identifier !! Description
|-
| 0x08 || CANid_WheelSpeedFL || Wheel speed average
|-
| 0x09 || CANid_WheelSpeedFR || Wheel speed average
|-
| 0x0a || CANid_WheelSpeedRL || Wheel speed average
|-
| 0x0b || CANid_WheelSpeedRR || Wheel speed average
|-
| 0x0d || CANid_Voltage || Board supply voltage
|-
| 0x0e || CANid_ResetCounter || Reset logger counter
|-
| 0x10 || CANid_Inertial_X || Inertial System acceleration X axis
|-
| 0x11 || CANid_Inertial_Y || Inertial System acceleration Y axis
|-
| 0x12 || CANid_Inertial_Yaw || Inertial System yaw rate
|-
| 0x20 || CANid_SelectJumper || Select between original or generated
|-
| 0x22 || CANid_Steering || PWM signal for steering (transmitter signal)
|-
| 0x25 || CANid_Throttle || PWM signal for throttle (transmitter signal)
|-
| 0x32 || CANid_Steering_new || PWM signal for steering (generated)
|-
| 0x35 || CANid_Throttle_new || PWM signal for throttle (generated)
|-
| 0x400 || CANid_ErrorController || Controller error 5 ([[#CAN Controller Error Messages|Table 5]])
|-
| 0x402 || CANid_EmergencyKey || Emergency key pressed ([[#CAN Emergency Key Messages|Table 6]])
|}

==Semantics of CAN Messages==

In this section the semantics of each CAN Message is described. Some of the messages have special quality descriptors attached to them, which are also described here.
The first important definition about the CAN Messages is their size. All of the CAN Messages going over the ConceptCar CAN Bus are 32bit long. While this is not unchangeable, it is necessary to change the code to allow messages bigger than 32bits.

====CANid_WheelSpeedXX====

Information about wheel speed coming from the wheel speed sensors. The wheel speed is calculated using the time interval between two measures done by the speed sensor. Messages informing the vehicle speed are sent every 20ms. If no measurement is accomplished during the 20ms time slot, no speed information is available.
For this reason the semantic of the messages and measurements are defined. A quality descriptor is inserted into the message to describe the quality of the information provided by the message payload, so listeners of this messages can decide what to do with the information.
The speed is calculated using the average of measures obtained within the 20ms time slot. When several readings occur during the time slot, the value 2 is said to have a high quality. If the time between measures take longer than 20ms, the quality of the information is decayed and follows Equation 1.

<math> f(x)=\frac{1}{x^2+1} </math>

This equation maps four time slots to a value between the interval ]0; 1] that can be used to determine the quality of the information being sent over the CAN bus. The variable x represents the time slot in which the computation is currently being made. For instance, if no measurements were accomplished during the last 3 time slots, the quality descriptor will have the value mapped
to the value yielded by f(3).
Using only discrete values to map the evaluation of Equation 1 to a quality level allows the decay of quality based on the number of cycles (time slots) where there was no reading from the speed sensor.
The semantics of the Wheel Speed CAN messages is as follows. The message consists of a 32bit payload. Values are given in meters per second (m/s). The two MSBs (Most Significant Bits) are used for determining the message quality level. These two bits allow four levels of quality: High, Medium-high, Medium-low and Low quality. Table 2 shows the mapping of quality information to bit values.

{| border="1"
|+ '''Table 2: Quality-Bit Mapping'''
! Quality level !! Bit setting
|-
| High || 00
|-
| Medium-high || 01
|-
| Medium-low || 10
|-
| Low || 11
|}

The issue of mapping the value yielded by equation 1 to a quality level is addressed by the component responsible for the speed measurements and the requirements imposed by the system.

====CAN Board Voltage Message====

The Board Voltage can be used to determine the battery level of the ConceptCar. If low voltages are detected this information can be used to stop the car or to gracefully degrade the configuration actually being executed. For example, less important sensors can be turned off.
The CAN Message carrying the board voltage also uses 32bits as payload where the two MSBs are quality descriptors as defined for the Wheel Speed Sensors in section [[#CANid WheelSpeedXX|CANid WheelSpeedXX]] and depicted by Equation 1 and Table 2.
The value contained in the CAN Board Voltage messages are obtained through the evaluation of Equation 2.

<math>U=x\times\frac{3.7}{1024}\times 5V</math>

====CAN Reset Counter Message====

This message resets the logger indexing counter. If this message is present on the CAN Bus, the logger counter will be reset. The contents of the message are not considered in order to reset the counter.
Later specification can be defined for use of the reset message contents.

====CAN Inertial Sensor Messages====

The inertial sensors interface with the sensor boards directly through a digital communication channel. The digital channel allows a digital value to be directly delivered to the sensor board without the need for further D2A (Digital to Analog) conversions.
Since the readings are already provided by the sensors in digital format. It is not necessary to treat these values and the sensor boards can directly send the values over CAN.

====CAN Select Jumper Message====

The select jumper messages inform the ConceptCar system to switch between generate PWM signals to the original signals coming from the Radio Transmitter handled by the driver, or vice versa.
The message must contain the ID of the PWM source to which the car should switch to. The IDs are described in [[#CAN Select Jumper Message|Table 3]].

{| border="1"
|+ '''Table 3: Select Jumper Source IDs'''
! ID !! Description
|-
| 0x1 || Original PWM Signals (From Transmitter)
|-
| 0x2 || Generated PWM Signals (From Car)
|}

====CAN PWM Signal Messages====

PWM signals control the Servo-Motors of the vehicle. There are two sources of PWM signals used in the ConceptCar. One of them are the signals coming from the RC Transmitter. These signals can go directly to the car's steering and throttle units.
The other source of signals are the signals generated by the car's circuitry. The generated signals can be used to adjust driving behavior, such as compen sating for a slipping wheel when the RC Transmitter is setting the Throttle to full.
The PWM signals are unfortunately not quite accurate. For this reason some measures must be taken in order to allow a certain
flexibility during PWM signal interpretation. The interpretation is done by the board responsible for generating a CAN message with the signal data. The CAN messages use 29bit data payload, 1bit orientation payload and 2bits quality description payload. [[#CAN PWM Signal Messages|Table 4]] describes the message format.
The quality levels are the same as the ones described in Table 2 in section [[#CANid_WheelSpeedXX|CANid_WheelSpeedXX]]. Based on the message quality listener modules can decide what to do with the information.

{| border="1"
|+ '''Table 4: PWM CAN Message format'''
! Quality !! Orientation !! Value
|-
| 31-30 || 29 || 28-0
|}

====CAN Controller Error Messages====

The ConceptCar Controller might experience problems when decoding PWM signals. This happens because PWM signals are not discreetly defined. Sometimes the signal gets out of range and the controller issues an error. An error message assumes one of the values described in table 5 and components that listen to these messages can take action upon the error signaled by the message.

{| border="1"
|+ '''Table 5: Controller Error Messages'''
! ID !! Identifier !! Description
|-
| 0x1 || ErrorType_PulseOutOfBounds || Indicates too short or too long PWM pulses
|-
| 0x2 || ErrorType_PWMFrequency || Indicates a wrong PWM frequency
|-
| 0x4 || ErrorType_NoSignal || Indicates lack of signal (low is longer than 18ms)
|-
| 0x8 || ErrorType_ActorEnteredError || -
|}

====CAN Emergency Key Messages====

The ConceptCar is equipped with a emergency (panic) remote control. This remote control has 3 buttons that can be used for different functions. One of the current uses is to hit the brakes of the car if the button is pressed. This allows the driver to stop the car if it gets uncontrollable or if the car's system behaves in unexpected ways.
Table 6 gives the description of the CAN Message contents generated when at least one of the three available buttons is pressed.

{| border="1"
|+ '''Table 6: Emergency Key Mapping'''
! Button !! Bits
|-
| 1 || 0x01(001)
|-
| 2 || 0x02(010)
|-
| 3 || 0x04(100)
|}

CAN IDs

2009-10-16T07:34:04Z

153.96.133.33: /* CANid_WheelSpeedXX */

This document describes the messages used to transport sensor and actuator information over the ConceptCar CAN Bus. All information regarding the CAN Messages such as IDs, data width, payload and semantics are defined in this document.

==CAN bus operation==

* The CAN bus is operated in CAN 2.0A mode. No component is expected to put 2.0B messages on the bus.
* The Speed is 1MBit/s highspeed.
* The bit timing is 75%.

==Data format==

To establish a convenient and simple way of data interchange between different components on different platforms communicating over the bus, there is a unique data format for interchange here. All data passed over the CAN bus must be packed into a 4 Byte CAN message whose contents are interpreted as one 4 Byte unsigned integer variable. The byte order inside each of these CAN messages is as usual on the CAN bus: lowest byte first.

As an example, the value 0x12345678 is sent over the bus 0x78, 0x56, 0x34, 0x12.

If the value can't be directly evaluated, a linear marshaling function has to be defined here. Other marshaling functions than linear ones are '''not allowed'''.

==CAN IDs and Description==

In this section the CAN IDs used by the concept car are defined and a brief description of them is given. Later on the semantics of each message is defined.

{| border="1"
|+ '''Table 1: CAN ID Definition'''
! CAN ID !! Identifier !! Description
|-
| 0x08 || CANid_WheelSpeedFL || Wheel speed average
|-
| 0x09 || CANid_WheelSpeedFR || Wheel speed average
|-
| 0x0a || CANid_WheelSpeedRL || Wheel speed average
|-
| 0x0b || CANid_WheelSpeedRR || Wheel speed average
|-
| 0x0d || CANid_Voltage || Board supply voltage
|-
| 0x0e || CANid_ResetCounter || Reset logger counter
|-
| 0x10 || CANid_Inertial_X || Inertial System acceleration X axis
|-
| 0x11 || CANid_Inertial_Y || Inertial System acceleration Y axis
|-
| 0x12 || CANid_Inertial_Yaw || Inertial System yaw rate
|-
| 0x20 || CANid_SelectJumper || Select between original or generated
|-
| 0x22 || CANid_Steering || PWM signal for steering (transmitter signal)
|-
| 0x25 || CANid_Throttle || PWM signal for throttle (transmitter signal)
|-
| 0x32 || CANid_Steering_new || PWM signal for steering (generated)
|-
| 0x35 || CANid_Throttle_new || PWM signal for throttle (generated)
|-
| 0x400 || CANid_ErrorController || Controller error 5 ([[#CAN Controller Error Messages|Table 5]])
|-
| 0x402 || CANid_EmergencyKey || Emergency key pressed ([[#CAN Emergency Key Messages|Table 6]])
|}

==Semantics of CAN Messages==

In this section the semantics of each CAN Message is described. Some of the messages have special quality descriptors attached to them, which are also described here.
The first important definition about the CAN Messages is their size. All of the CAN Messages going over the ConceptCar CAN Bus are 32bit long. While this is not unchangeable, it is necessary to change the code to allow messages bigger than 32bits.

====CANid_WheelSpeedXX====

Information about wheel speed coming from the wheel speed sensors. The wheel speed is calculated using the time interval between two measures done by the speed sensor. Messages informing the vehicle speed are sent every 20ms. If no measurement is accomplished during the 20ms time slot, no speed information is available.
For this reason the semantic of the messages and measurements are defined. A quality descriptor is inserted into the message to describe the quality of the information provided by the message payload, so listeners of this messages can decide what to do with the information.
The speed is calculated using the average of measures obtained within the 20ms time slot. When several readings occur during the time slot, the value 2 is said to have a high quality. If the time between measures take longer than 20ms, the quality of the information is decayed and follows Equation 1.

<math> f(x)=\frac{1}{x^2+1 </math>

This equation maps four time slots to a value between the interval ]0; 1] that can be used to determine the quality of the information being sent over the CAN bus. The variable x represents the time slot in which the computation is currently being made. For instance, if no measurements were accomplished during the last 3 time slots, the quality descriptor will have the value mapped
to the value yielded by f(3).
Using only discrete values to map the evaluation of Equation 1 to a quality level allows the decay of quality based on the number of cycles (time slots) where there was no reading from the speed sensor.
The semantics of the Wheel Speed CAN messages is as follows. The message consists of a 32bit payload. Values are given in meters per second (m/s). The two MSBs (Most Significant Bits) are used for determining the message quality level. These two bits allow four levels of quality: High, Medium-high, Medium-low and Low quality. Table 2 shows the mapping of quality information to bit values.

{| border="1"
|+ '''Table 2: Quality-Bit Mapping'''
! Quality level !! Bit setting
|-
| High || 00
|-
| Medium-high || 01
|-
| Medium-low || 10
|-
| Low || 11
|}

The issue of mapping the value yielded by equation 1 to a quality level is addressed by the component responsible for the speed measurements and the requirements imposed by the system.

====CAN Board Voltage Message====

The Board Voltage can be used to determine the battery level of the ConceptCar. If low voltages are detected this information can be used to stop the car or to gracefully degrade the configuration actually being executed. For example, less important sensors can be turned off.
The CAN Message carrying the board voltage also uses 32bits as payload where the two MSBs are quality descriptors as defined for the Wheel Speed Sensors in section [[#CANid WheelSpeedXX|CANid WheelSpeedXX]] and depicted by Equation 1 and Table 2.
The value contained in the CAN Board Voltage messages are obtained through the evaluation of Equation 2.

<math>U=x\times\frac{3.7}{1024}\times 5V</math>

====CAN Reset Counter Message====

This message resets the logger indexing counter. If this message is present on the CAN Bus, the logger counter will be reset. The contents of the message are not considered in order to reset the counter.
Later specification can be defined for use of the reset message contents.

====CAN Inertial Sensor Messages====

The inertial sensors interface with the sensor boards directly through a digital communication channel. The digital channel allows a digital value to be directly delivered to the sensor board without the need for further D2A (Digital to Analog) conversions.
Since the readings are already provided by the sensors in digital format. It is not necessary to treat these values and the sensor boards can directly send the values over CAN.

====CAN Select Jumper Message====

The select jumper messages inform the ConceptCar system to switch between generate PWM signals to the original signals coming from the Radio Transmitter handled by the driver, or vice versa.
The message must contain the ID of the PWM source to which the car should switch to. The IDs are described in [[#CAN Select Jumper Message|Table 3]].

{| border="1"
|+ '''Table 3: Select Jumper Source IDs'''
! ID !! Description
|-
| 0x1 || Original PWM Signals (From Transmitter)
|-
| 0x2 || Generated PWM Signals (From Car)
|}

====CAN PWM Signal Messages====

PWM signals control the Servo-Motors of the vehicle. There are two sources of PWM signals used in the ConceptCar. One of them are the signals coming from the RC Transmitter. These signals can go directly to the car's steering and throttle units.
The other source of signals are the signals generated by the car's circuitry. The generated signals can be used to adjust driving behavior, such as compen sating for a slipping wheel when the RC Transmitter is setting the Throttle to full.
The PWM signals are unfortunately not quite accurate. For this reason some measures must be taken in order to allow a certain
flexibility during PWM signal interpretation. The interpretation is done by the board responsible for generating a CAN message with the signal data. The CAN messages use 29bit data payload, 1bit orientation payload and 2bits quality description payload. [[#CAN PWM Signal Messages|Table 4]] describes the message format.
The quality levels are the same as the ones described in Table 2 in section [[#CANid_WheelSpeedXX|CANid_WheelSpeedXX]]. Based on the message quality listener modules can decide what to do with the information.

{| border="1"
|+ '''Table 4: PWM CAN Message format'''
! Quality !! Orientation !! Value
|-
| 31-30 || 29 || 28-0
|}

====CAN Controller Error Messages====

The ConceptCar Controller might experience problems when decoding PWM signals. This happens because PWM signals are not discreetly defined. Sometimes the signal gets out of range and the controller issues an error. An error message assumes one of the values described in table 5 and components that listen to these messages can take action upon the error signaled by the message.

{| border="1"
|+ '''Table 5: Controller Error Messages'''
! ID !! Identifier !! Description
|-
| 0x1 || ErrorType_PulseOutOfBounds || Indicates too short or too long PWM pulses
|-
| 0x2 || ErrorType_PWMFrequency || Indicates a wrong PWM frequency
|-
| 0x4 || ErrorType_NoSignal || Indicates lack of signal (low is longer than 18ms)
|-
| 0x8 || ErrorType_ActorEnteredError || -
|}

====CAN Emergency Key Messages====

The ConceptCar is equipped with a emergency (panic) remote control. This remote control has 3 buttons that can be used for different functions. One of the current uses is to hit the brakes of the car if the button is pressed. This allows the driver to stop the car if it gets uncontrollable or if the car's system behaves in unexpected ways.
Table 6 gives the description of the CAN Message contents generated when at least one of the three available buttons is pressed.

{| border="1"
|+ '''Table 6: Emergency Key Mapping'''
! Button !! Bits
|-
| 1 || 0x01(001)
|-
| 2 || 0x02(010)
|-
| 3 || 0x04(100)
|}