ConceptCar - User contributions [en]

Main Page

2011-06-17T12:49:02Z

Donald: /* 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|The Fraunhofer IESE ConceptCar]]

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]]
***[[FreeRTOS_CortexM3_HowTo|2.3.3 - Cortex M3 & FreeRTOS]]
**2.4 - Runtime Platforms
***[[FreeRTOS CortexM3 HowTo|2.4.1 - FreeRTOS CortexM3 HowTo]]

*[[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]

Sensors

2011-06-14T15:14:00Z

Donald: /* Wheel speed sensors */

The monitoring of the environment is implemented in the Concept Car using different sensors. In the following, all the sensors are described.

==Wheel speed sensors==

[[image:CNY70-pinout.jpg|thumb|150px|CNY 70 optical sensor]]
[[image:CCarWheel.JPG|thumb|150px|Black Stripes Marks inside the Concept Car Wheel]]

The rotation speed of the wheels is measured with simple optical sensors, where 26 black stripes in the inside of the wheel are passing a photo sensor. A photo diode (CNY 70) detects the passing of the stripes, and the interval between two stripes passing is measured with a resolution of 0.5µs. Every 20ms the wheel speed of all four sensors is written to the CAN-Bus. Depending on the current wheel speed, one of the following conditions holds:

# The wheel speed is so low that no black stripe has passed within the last 20ms (may happen if speed is lower than 692.3077°/s or 0.725m/s): The value 0xffffffff is sent via CAN.
# During 20ms exactly one black stripe has passed. In this case the period since the last stripe has passed is sent in the unit of 0.5µs. The last passing of a stripe may be several 20ms intervals ago, internally 24 bits are counted, resulting in a maximum interval of 0xffffff * 0.5µs = 8.39s. Values above that will be truncated.
# During 20ms multiple stripes pass. In this case the average value is taken.

The sensory data from the wheel speed sensors is to be considered as extremely noisy, and should not be used by any system without applying adequate filtering algorithms, as described in [[Bibliography|[Mit09]]].

==Distance Sensors==

[[image:SRF02_sensor.jpg|thumb|left|100px|SRF02 distance sensor]]
On the front side of the car there are two ultrasonic distance sensors. They are triggered in alternating order every 65ms to measure the distance to the next obstacle in front of the car. Their range is 15cm to 6m, with a resolution of 1cm. For further details consult the documentation, accessible under [[Bibliography|[RHW09]]].

 

==Acceleration Sensors==

The acceleration of the Concept Car is measured with the ADIS16006 sensors. The dual-axis accelerometer ADIS16006 is capable of measuring -5g to +5g at a resolution of 1,9mg at 60Hz measurement rate. The maximum measurement range is ±8g. It has a built-in temperature sensor to mask out the temperature drift of the measurement results. For further details consult the documentation [[Bibliography|[Ana07]]].

==Rotation Sensor==

The vehicle rotation along the yaw axis is measured using a rotation sensor of the type ADIS16100. The dynamic range of the yaw rate sensor ADIS16100 is 300°/s at a resolution of 0.244°/s. This sensor also provides temperature information for separating out the temperature drift. Further documentation can be found under [[Bibliography|[Ana09]]].

==Radio Receiver Decoder==

The Radio Receiver outputs a pulse width modulation (PWM) signal. The PWM signal from the radio receiver’s channels must be decoded to be usable inside the system. Therefore the length of the pulses (duty cycle is 5% to 10%) is measured and normalized, with 5% being -100 to 10% being +100. The resolution is 0.01%. Radio receiver signals are sent over the CAN-Bus whenever a PWM-pulse with a valid duty cycle has been measured, so under typical driving conditions every 20ms for each channel.

Sensors

2011-06-14T15:10:31Z

Donald: /* Wheel speed sensors */

The monitoring of the environment is implemented in the Concept Car using different sensors. In the following, all the sensors are described.

==Wheel speed sensors==

[[image:CCarWheel.JPG|thumb|200px|Black Stripes Marks inside the Concept Car Wheel]]

The rotation speed of the wheels is measured with simple optical sensors, where 26 black stripes in the inside of the wheel are passing a photo sensor.

[[image:CNY70-pinout.jpg|thumb|left|150px|CNY 70 optical sensor]] A photo diode (CNY 70) detects the passing of the stripes, and the interval between two stripes passing is measured with a resolution of 0.5µs. Every 20ms the wheel speed of all four sensors is written to the CAN-Bus. Depending on the current wheel speed, one of the following conditions holds:

# The wheel speed is so low that no black stripe has passed within the last 20ms (may happen if speed is lower than 692.3077°/s or 0.725m/s): The value 0xffffffff is sent via CAN.
# During 20ms exactly one black stripe has passed. In this case the period since the last stripe has passed is sent in the unit of 0.5µs. The last passing of a stripe may be several 20ms intervals ago, internally 24 bits are counted, resulting in a maximum interval of 0xffffff * 0.5µs = 8.39s. Values above that will be truncated.
# During 20ms multiple stripes pass. In this case the average value is taken.

The sensory data from the wheel speed sensors is to be considered as extremely noisy, and should not be used by any system without applying adequate filtering algorithms, as described in [[Bibliography|[Mit09]]].

==Distance Sensors==

[[image:SRF02_sensor.jpg|thumb|left|100px|SRF02 distance sensor]]
On the front side of the car there are two ultrasonic distance sensors. They are triggered in alternating order every 65ms to measure the distance to the next obstacle in front of the car. Their range is 15cm to 6m, with a resolution of 1cm. For further details consult the documentation, accessible under [[Bibliography|[RHW09]]].

 

==Acceleration Sensors==

The acceleration of the Concept Car is measured with the ADIS16006 sensors. The dual-axis accelerometer ADIS16006 is capable of measuring -5g to +5g at a resolution of 1,9mg at 60Hz measurement rate. The maximum measurement range is ±8g. It has a built-in temperature sensor to mask out the temperature drift of the measurement results. For further details consult the documentation [[Bibliography|[Ana07]]].

==Rotation Sensor==

The vehicle rotation along the yaw axis is measured using a rotation sensor of the type ADIS16100. The dynamic range of the yaw rate sensor ADIS16100 is 300°/s at a resolution of 0.244°/s. This sensor also provides temperature information for separating out the temperature drift. Further documentation can be found under [[Bibliography|[Ana09]]].

==Radio Receiver Decoder==

The Radio Receiver outputs a pulse width modulation (PWM) signal. The PWM signal from the radio receiver’s channels must be decoded to be usable inside the system. Therefore the length of the pulses (duty cycle is 5% to 10%) is measured and normalized, with 5% being -100 to 10% being +100. The resolution is 0.01%. Radio receiver signals are sent over the CAN-Bus whenever a PWM-pulse with a valid duty cycle has been measured, so under typical driving conditions every 20ms for each channel.

Sensors

2011-06-14T15:08:18Z

Donald: /* Wheel speed sensors */

The monitoring of the environment is implemented in the Concept Car using different sensors. In the following, all the sensors are described.

==Wheel speed sensors==

[[image:CCarWheel.JPG|thumb|200px|Black Stripes Marks inside the Concept Car Wheel]]

The rotation speed of the wheels is measured with simple optical sensors, where 26 black stripes in the inside of the wheel are passing a photo sensor.

[[image:CNY70-pinout.jpg|thumb|left|150px|CNY 70 optical sensor]] A photo diode (CNY 70) detects the passing of the stripes, and from the interval since the last stripe has passed the wheel speed is derived. The resolution of the timers that measure the interval between two stripes is 0.5µs. Every 20ms the wheel speed of all four sensors is written to the CAN-Bus. Depending on the current wheel speed, one of the following conditions holds:

# The wheel speed is so low that no black stripe has passed within the last 20ms (may happen if speed is lower than 692.3077°/s or 0.725m/s): The value 0xffffffff is sent via CAN.
# During 20ms exactly one black stripe has passed. In this case the period since the last stripe has passed is sent in the unit of 0.5µs. The last passing of a stripe may be several 20ms intervals ago, internally 24 bits are counted, resulting in a maximum interval of 0xffffff * 0.5µs = 8.39s. Values above that will be truncated.
# During 20ms multiple stripes pass. In this case the average value is taken.

The sensory data from the wheel speed sensors is to be considered as extremely noisy, and should not be used by any system without applying adequate filtering algorithms, as described in [[Bibliography|[Mit09]]].

==Distance Sensors==

[[image:SRF02_sensor.jpg|thumb|left|100px|SRF02 distance sensor]]
On the front side of the car there are two ultrasonic distance sensors. They are triggered in alternating order every 65ms to measure the distance to the next obstacle in front of the car. Their range is 15cm to 6m, with a resolution of 1cm. For further details consult the documentation, accessible under [[Bibliography|[RHW09]]].

 

==Acceleration Sensors==

The acceleration of the Concept Car is measured with the ADIS16006 sensors. The dual-axis accelerometer ADIS16006 is capable of measuring -5g to +5g at a resolution of 1,9mg at 60Hz measurement rate. The maximum measurement range is ±8g. It has a built-in temperature sensor to mask out the temperature drift of the measurement results. For further details consult the documentation [[Bibliography|[Ana07]]].

==Rotation Sensor==

The vehicle rotation along the yaw axis is measured using a rotation sensor of the type ADIS16100. The dynamic range of the yaw rate sensor ADIS16100 is 300°/s at a resolution of 0.244°/s. This sensor also provides temperature information for separating out the temperature drift. Further documentation can be found under [[Bibliography|[Ana09]]].

==Radio Receiver Decoder==

The Radio Receiver outputs a pulse width modulation (PWM) signal. The PWM signal from the radio receiver’s channels must be decoded to be usable inside the system. Therefore the length of the pulses (duty cycle is 5% to 10%) is measured and normalized, with 5% being -100 to 10% being +100. The resolution is 0.01%. Radio receiver signals are sent over the CAN-Bus whenever a PWM-pulse with a valid duty cycle has been measured, so under typical driving conditions every 20ms for each channel.

Sensors

2011-06-14T15:07:00Z

Donald: /* Wheel speed sensors */

The monitoring of the environment is implemented in the Concept Car using different sensors. In the following, all the sensors are described.

==Wheel speed sensors==

The rotation speed of the wheels is measured with simple optical sensors, where 26 black stripes in the inside of the wheel are passing a photo sensor. The Figure 1.5 shows the marks inside of the wheel.

[[image:CCarWheel.JPG|thumb|200px|Figure 1.5. Black Stripes Marks inside the Concept Car Wheel]]

[[image:CNY70-pinout.jpg|thumb|left|150px|CNY 70 optical sensor]] A photo diode (CNY 70) detects the passing of the stripes, and from the interval since the last stripe has passed the wheel speed is derived. The resolution of the timers that measure the interval between two stripes is 0.5µs. Every 20ms the wheel speed of all four sensors is written to the CAN-Bus. Depending on the current wheel speed, one of the following conditions holds:

# The wheel speed is so low that no black stripe has passed within the last 20ms (may happen if speed is lower than 692.3077°/s or 0.725m/s): The value 0xffffffff is sent via CAN.
# During 20ms exactly one black stripe has passed. In this case the period since the last stripe has passed is sent in the unit of 0.5µs. The last passing of a stripe may be several 20ms intervals ago, internally 24 bits are counted, resulting in a maximum interval of 0xffffff * 0.5µs = 8.39s. Values above that will be truncated.
# During 20ms multiple stripes pass. In this case the average value is taken.

The sensory data from the wheel speed sensors is to be considered as extremely noisy, and should not be used by any system without applying adequate filtering algorithms, as described in [[Bibliography|[Mit09]]].

==Distance Sensors==

[[image:SRF02_sensor.jpg|thumb|left|100px|SRF02 distance sensor]]
On the front side of the car there are two ultrasonic distance sensors. They are triggered in alternating order every 65ms to measure the distance to the next obstacle in front of the car. Their range is 15cm to 6m, with a resolution of 1cm. For further details consult the documentation, accessible under [[Bibliography|[RHW09]]].

 

==Acceleration Sensors==

The acceleration of the Concept Car is measured with the ADIS16006 sensors. The dual-axis accelerometer ADIS16006 is capable of measuring -5g to +5g at a resolution of 1,9mg at 60Hz measurement rate. The maximum measurement range is ±8g. It has a built-in temperature sensor to mask out the temperature drift of the measurement results. For further details consult the documentation [[Bibliography|[Ana07]]].

==Rotation Sensor==

The vehicle rotation along the yaw axis is measured using a rotation sensor of the type ADIS16100. The dynamic range of the yaw rate sensor ADIS16100 is 300°/s at a resolution of 0.244°/s. This sensor also provides temperature information for separating out the temperature drift. Further documentation can be found under [[Bibliography|[Ana09]]].

==Radio Receiver Decoder==

The Radio Receiver outputs a pulse width modulation (PWM) signal. The PWM signal from the radio receiver’s channels must be decoded to be usable inside the system. Therefore the length of the pulses (duty cycle is 5% to 10%) is measured and normalized, with 5% being -100 to 10% being +100. The resolution is 0.01%. Radio receiver signals are sent over the CAN-Bus whenever a PWM-pulse with a valid duty cycle has been measured, so under typical driving conditions every 20ms for each channel.

File:CNY70-pinout.jpg

2011-06-14T12:42:05Z

Donald:

Sensors

2011-06-14T12:41:50Z

Donald: /* Wheel speed sensors */

The monitoring of the environment is implemented in the Concept Car using different sensors. In the following, all the sensors are described.

==Wheel speed sensors==

The rotation speed of the wheels is measured with simple optical sensors, where 26 black stripes in the inside of the wheel are passing a photo sensor. The Figure 1.5 shows the marks inside of the wheel.

[[image:CCarWheel.JPG|thumb|200px|Figure 1.5. Black Stripes Marks inside the Concept Car Wheel]]

[[image:CNY70-pinout.jpg|thumb|left|150px|CNY 70 optical sensor]] A photo diode (CNY 70) detects the passing of the stripes, and from the interval since the last stripe has passed the wheel speed is derived. The resolution of the timers that measure the interval between two stripes is 0.25µs. Every 50ms the wheel speed of all four sensors is written to the CAN-Bus. Depending on the current wheel speed, one of the following conditions holds:

*1. The wheel speed is so low that no black stripe has passed within the last 50ms (may happen if speed is lower than 276.92°/s or 0.29m/s): The absence of a black stripe passing is communicated nevertheless
*2. During 50ms exactly one black stripe has passed. In this case the wheel speed is derived from this single value.
*3. During 50ms multiple stripes pass. In this case the average value is taken.

Let be the average interval length between two stripes with the resolution of 0.25µs. In the cases (2) and (3) the wheel speed can be calculated by Equation 1.1.

[[image:Equation2_1.JPG|thumb|200px|Equation 1.1]]

The sensory data from the wheel speed sensors is to be considered as extremely noisy, and should not be used by any system without applying adequate filtering algorithms, as described in [[Bibliography|[Mit09]]].

==Distance Sensors==

[[image:SRF02_sensor.jpg|thumb|left|100px|SRF02 distance sensor]]
On the front side of the car there are two ultrasonic distance sensors. They are triggered in alternating order every 65ms to measure the distance to the next obstacle in front of the car. Their range is 15cm to 6m, with a resolution of 1cm. For further details consult the documentation, accessible under [[Bibliography|[RHW09]]].

 

==Acceleration Sensors==

The acceleration of the Concept Car is measured with the ADIS16006 sensors. The dual-axis accelerometer ADIS16006 is capable of measuring -5g to +5g at a resolution of 1,9mg at 60Hz measurement rate. The maximum measurement range is ±8g. It has a built-in temperature sensor to mask out the temperature drift of the measurement results. For further details consult the documentation [[Bibliography|[Ana07]]].

==Rotation Sensor==

The vehicle rotation along the yaw axis is measured using a rotation sensor of the type ADIS16100. The dynamic range of the yaw rate sensor ADIS16100 is 300°/s at a resolution of 0.244°/s. This sensor also provides temperature information for separating out the temperature drift. Further documentation can be found under [[Bibliography|[Ana09]]].

==Radio Receiver Decoder==

The Radio Receiver outputs a pulse width modulation (PWM) signal. The PWM signal from the radio receiver’s channels must be decoded to be usable inside the system. Therefore the length of the pulses (duty cycle is 5% to 10%) is measured and normalized, with 5% being -100 to 10% being +100. The resolution is 0.01%. Radio receiver signals are sent over the CAN-Bus whenever a PWM-pulse with a valid duty cycle has been measured, so under typical driving conditions every 20ms for each channel.

ECUs implementing Sensorboards and Actorboard

2011-06-14T12:38:28Z

Donald: /* Sensorboard Throttle */

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

All ECUs described on this page adhere to the [[Adding_Resources_to_the_Concept_Car|form factor for small ECUs on the ConceptCar]]. They all share the same MCU, an AT90CAN128 which is an 8-bit RISC Microcontroller with AVR core, 128K bytes of programmable Flash memory, 4K byte EEPROM and 4K byte of internal SRAM, 53 general purpose I/O lines, 32 general purpose working registers, CAN Controller , 4 timers, and others resources described in [[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 [[Sensors#Wheel_speed_sensors|wheel speed sensors]] from the rear left and front right wheels. Analogue amplifiers (MCP6002) increase the signal level of the wheel speed sensors so their signal can be decoded on a digital input of the AT90CAN128.

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

===Connectors to external Sensors===

As you can see on the picture, the Sensorboards Steering and Throttle both have 3 Connectors. One is for attaching the measured PWM signal, the other two are reserved for the Rotation Sensors. The Pinout is as follows:
# PWM Connector:
## Pin 1 --> PWM Input, digital levels
## Pin 2 --> Ground
# Sensor Connector:
## Pin 1 --> Ground
## Pin 2 --> (infrared) LED Power Supply, connect to the Anode and Cathode to ground
## Pin 3 --> Photo transistor Collector, connect Emitter to ground

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

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

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

{| 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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 <tt>/dev/mmcblk0p1</tt> is your MMC/SD card device's primary partition,

> mkfs.vfat -F 16 /dev/mmcblk0p1

would create a valid FAT 16 partition.

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

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

* Log file format
** The log file has a binary format, containing a dump of all CAN messages including a timestamp for each. For each CAN message, the following data fragment is written:

/----------------------------------------------------------\
| Header | Timestamp | CAN ID | Data Length | Data |
| 0xca | 4 Bytes | 2 Bytes | 1 Byte | 0 - 8 Bytes |
\----------------------------------------------------------------------------------------/

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

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

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

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

This will throw a window onto the screen.

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

set multiplot
unset multiplot

before the first plot and after the last plot.

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

######## Type your configuration here ########
canid = 8
infile = 'MiniMonLOG.csv'
outfile = "ploop.png"
minimon = 1
##############################################

# Touch this only if you know, what you are doing!

#this line prepares the logfiles
#note: theres a difference between data logged on the car and data logged from MiniMon
if(minimon) i_string = sprintf("< gawk -F\\; '{ gsub(/\\\"|:|\\.|[:blank:]/,\"\", $1); gsub(/\\\"|:|\\.|[:blank:]/,\"\",$2); s2 = strtonum(sprintf(\"0x%s\",$2)); gsub(/\\\"|:|\\.|[[:blank:]]/,\"\",$5); s3 = strtonum(sprintf(\"0x%s\",$5)); printf \"%s\\n\",$1,s2,s3 }' %s | sort | grep \";%d;\"", "%s", "%s", "%s;%s;%s", infile, canid); else i_string = sprintf("< grep ';%d;' '%s'", canid, infile)
# The above code has to be in a single line!

#initializing output
set terminal png large size 1280,1024
set output outfile
set grid
set xlabel 'Value'
set ylabel 'Time'
set title 'Messages sent via CAN'
unset key
set datafile separator ';'
#and plot data, prepared some lines above
plot [:] [:] i_string using 1:3 w lines

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

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

==Actorboard==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2011-06-14T12:38:05Z

Donald: /* Sensorboard Steering */

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

All ECUs described on this page adhere to the [[Adding_Resources_to_the_Concept_Car|form factor for small ECUs on the ConceptCar]]. They all share the same MCU, an AT90CAN128 which is an 8-bit RISC Microcontroller with AVR core, 128K bytes of programmable Flash memory, 4K byte EEPROM and 4K byte of internal SRAM, 53 general purpose I/O lines, 32 general purpose working registers, CAN Controller , 4 timers, and others resources described in [[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 [[Sensors#Wheel_speed_sensors|wheel speed sensors]] from the rear left and front right wheels. Analogue amplifiers (MCP6002) increase the signal level of the wheel speed sensors so their signal can be decoded on a digital input of the AT90CAN128.

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

===Connectors to external Sensors===

As you can see on the picture, the Sensorboards Steering and Throttle both have 3 Connectors. One is for attaching the measured PWM signal, the other two are reserved for the Rotation Sensors. The Pinout is as follows:
# PWM Connector:
## Pin 1 --> PWM Input, digital levels
## Pin 2 --> Ground
# Sensor Connector:
## Pin 1 --> Ground
## Pin 2 --> (infrared) LED Power Supply, connect to the Anode and Cathode to ground
## Pin 3 --> Photo transistor Collector, connect Emitter to ground

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

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

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

{| 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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 <tt>/dev/mmcblk0p1</tt> is your MMC/SD card device's primary partition,

> mkfs.vfat -F 16 /dev/mmcblk0p1

would create a valid FAT 16 partition.

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

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

* Log file format
** The log file has a binary format, containing a dump of all CAN messages including a timestamp for each. For each CAN message, the following data fragment is written:

/----------------------------------------------------------\
| Header | Timestamp | CAN ID | Data Length | Data |
| 0xca | 4 Bytes | 2 Bytes | 1 Byte | 0 - 8 Bytes |
\----------------------------------------------------------------------------------------/

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

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

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

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

This will throw a window onto the screen.

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

set multiplot
unset multiplot

before the first plot and after the last plot.

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

######## Type your configuration here ########
canid = 8
infile = 'MiniMonLOG.csv'
outfile = "ploop.png"
minimon = 1
##############################################

# Touch this only if you know, what you are doing!

#this line prepares the logfiles
#note: theres a difference between data logged on the car and data logged from MiniMon
if(minimon) i_string = sprintf("< gawk -F\\; '{ gsub(/\\\"|:|\\.|[:blank:]/,\"\", $1); gsub(/\\\"|:|\\.|[:blank:]/,\"\",$2); s2 = strtonum(sprintf(\"0x%s\",$2)); gsub(/\\\"|:|\\.|[[:blank:]]/,\"\",$5); s3 = strtonum(sprintf(\"0x%s\",$5)); printf \"%s\\n\",$1,s2,s3 }' %s | sort | grep \";%d;\"", "%s", "%s", "%s;%s;%s", infile, canid); else i_string = sprintf("< grep ';%d;' '%s'", canid, infile)
# The above code has to be in a single line!

#initializing output
set terminal png large size 1280,1024
set output outfile
set grid
set xlabel 'Value'
set ylabel 'Time'
set title 'Messages sent via CAN'
unset key
set datafile separator ';'
#and plot data, prepared some lines above
plot [:] [:] i_string using 1:3 w lines

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

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

==Actorboard==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2011-06-14T12:35:13Z

Donald: /* Sensorboard Throttle */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

===Connectors to external Sensors===

As you can see on the picture, the Sensorboards Steering and Throttle both have 3 Connectors. One is for attaching the measured PWM signal, the other two are reserved for the Rotation Sensors. The Pinout is as follows:
# PWM Connector:
## Pin 1 --> PWM Input, digital levels
## Pin 2 --> Ground
# Sensor Connector:
## Pin 1 --> Ground
## Pin 2 --> (infrared) LED Power Supply, connect to the Anode and Cathode to ground
## Pin 3 --> Photo transistor Collector, connect Emitter to ground

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

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

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

{| 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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 <tt>/dev/mmcblk0p1</tt> is your MMC/SD card device's primary partition,

> mkfs.vfat -F 16 /dev/mmcblk0p1

would create a valid FAT 16 partition.

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

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

* Log file format
** The log file has a binary format, containing a dump of all CAN messages including a timestamp for each. For each CAN message, the following data fragment is written:

/----------------------------------------------------------\
| Header | Timestamp | CAN ID | Data Length | Data |
| 0xca | 4 Bytes | 2 Bytes | 1 Byte | 0 - 8 Bytes |
\----------------------------------------------------------------------------------------/

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

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

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

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

This will throw a window onto the screen.

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

set multiplot
unset multiplot

before the first plot and after the last plot.

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

######## Type your configuration here ########
canid = 8
infile = 'MiniMonLOG.csv'
outfile = "ploop.png"
minimon = 1
##############################################

# Touch this only if you know, what you are doing!

#this line prepares the logfiles
#note: theres a difference between data logged on the car and data logged from MiniMon
if(minimon) i_string = sprintf("< gawk -F\\; '{ gsub(/\\\"|:|\\.|[:blank:]/,\"\", $1); gsub(/\\\"|:|\\.|[:blank:]/,\"\",$2); s2 = strtonum(sprintf(\"0x%s\",$2)); gsub(/\\\"|:|\\.|[[:blank:]]/,\"\",$5); s3 = strtonum(sprintf(\"0x%s\",$5)); printf \"%s\\n\",$1,s2,s3 }' %s | sort | grep \";%d;\"", "%s", "%s", "%s;%s;%s", infile, canid); else i_string = sprintf("< grep ';%d;' '%s'", canid, infile)
# The above code has to be in a single line!

#initializing output
set terminal png large size 1280,1024
set output outfile
set grid
set xlabel 'Value'
set ylabel 'Time'
set title 'Messages sent via CAN'
unset key
set datafile separator ';'
#and plot data, prepared some lines above
plot [:] [:] i_string using 1:3 w lines

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

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

==Actorboard==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2011-06-14T12:33:59Z

Donald: /* Sensorboard Steering */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

===Connectors to external Sensors===

As you can see on the picture, the Sensorboards Steering and Throttle both have 3 Connectors. One is for attaching the measured PWM signal, the other two are reserved for the Rotation Sensors. The Pinout is as follows:
# PWM Connector:
## Pin 1 --> PWM Input, digital levels
## Pin 2 --> Ground
# Sensor Connector:
## Pin 1 --> Ground
## Pin 2 --> (infrared) LED Power Supply, connect to the Anode and Cathode to ground
## Pin 3 --> Photo transistor Collector, connect Emitter to ground

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

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

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

{| 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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 <tt>/dev/mmcblk0p1</tt> is your MMC/SD card device's primary partition,

> mkfs.vfat -F 16 /dev/mmcblk0p1

would create a valid FAT 16 partition.

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

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

* Log file format
** The log file has a binary format, containing a dump of all CAN messages including a timestamp for each. For each CAN message, the following data fragment is written:

/----------------------------------------------------------\
| Header | Timestamp | CAN ID | Data Length | Data |
| 0xca | 4 Bytes | 2 Bytes | 1 Byte | 0 - 8 Bytes |
\----------------------------------------------------------------------------------------/

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

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

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

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

This will throw a window onto the screen.

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

set multiplot
unset multiplot

before the first plot and after the last plot.

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

######## Type your configuration here ########
canid = 8
infile = 'MiniMonLOG.csv'
outfile = "ploop.png"
minimon = 1
##############################################

# Touch this only if you know, what you are doing!

#this line prepares the logfiles
#note: theres a difference between data logged on the car and data logged from MiniMon
if(minimon) i_string = sprintf("< gawk -F\\; '{ gsub(/\\\"|:|\\.|[:blank:]/,\"\", $1); gsub(/\\\"|:|\\.|[:blank:]/,\"\",$2); s2 = strtonum(sprintf(\"0x%s\",$2)); gsub(/\\\"|:|\\.|[[:blank:]]/,\"\",$5); s3 = strtonum(sprintf(\"0x%s\",$5)); printf \"%s\\n\",$1,s2,s3 }' %s | sort | grep \";%d;\"", "%s", "%s", "%s;%s;%s", infile, canid); else i_string = sprintf("< grep ';%d;' '%s'", canid, infile)
# The above code has to be in a single line!

#initializing output
set terminal png large size 1280,1024
set output outfile
set grid
set xlabel 'Value'
set ylabel 'Time'
set title 'Messages sent via CAN'
unset key
set datafile separator ';'
#and plot data, prepared some lines above
plot [:] [:] i_string using 1:3 w lines

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

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

==Actorboard==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

Adding Resources to the Concept Car

2010-08-17T11:16:14Z

Donald: /* Board Dimensions */

== Regarding Upgrades of the ConceptCar ==

[[image:ECU_stack.jpg|thumb|right|300px|The ConceptCar's ECU mount stack]]
The Concept Car has a modular architecture allowing the addition of resources in a simple way. In order to integrate a new ECU into the ConceptCar, these things are important:
#It is attached to the [[CAN_Bus|CAN bus]], but does not disturb the regular operation of the car. This means that no already used CAN IDs may be overwritten and that the bus load has to be low enough.
#It fits the form factor of the ECU stacks on the ConceptCar, so it can be easily and properly mounted.
#It does not interfere with the [[Power_Supply|ConceptCar's power train]], especially does not short circuit the galvanic isolation.
Apart from that, new ECUs may interfere with whichever sensor or actor equipment should be mounted to the car.

This page illustrates the demands regarding the form factor of the small boards so they can fit into the ECU stacks. There they are well mounted and protected against physical damage by the massive metal box next to them.

 

==Board Dimensions==

[[image:StackableBoardLayout.png|frame|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|frame|right|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 in the list below
* A green power on LED (<tt>CHIP-LED0805</tt>) that is directly attached to the power supply is recommended.
* If any additional LEDs are required, they should be placed at the lower border, like the CAN LEDs 200mil away from it or like in the list below.
* 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>.

'''Component placement:'''

Reset Switch: 550x275;
C 100n: 865x 415;
R 10k: 865x335;

LEDS:
Power: Resistor (220 Ohms): 865x255;
LED: 65x175

LEDs with Resistors from left to rigt:
R: 1075x25;
LED: 1075x175;
R: 1230x255;
LED: 1230x175;
R: 1550x255;
R: 1800x255;
R: 2025x255;
R: 2225x255;

Diode BAS85: 2375x2745

Diode Minimelf: 2440x2430, angle 270°

Coil: 2215x2655, angle: 270°

MAX1837: 2365x2630, angle: 90°

Capacitor: 2285x2435

Capacitor: 2595x2435, angle 270°

AT90CAN128: 1825x840, angle 270° (not forced)

CAN: 1475x2150

JTAG: 2450x800

ISP: 2450x1610

ISP is mandatory, but JTAG can be omitted.

'''AT90CAN128 Pin Connections'''

'''Port A:'''

Pin0:

Pin1:

Pin2:

Pin3:

Pin4:

Pin5:

Pin6: CAN_STATUS0

Pin7: CAN_STATUS1

'''Port B:'''

Pin0:

Pin1: SCK

Pin2:

Pin3:

Pin4:

Pin5:

Pin6:

Pin7:

'''Port C:'''

Pin0:

Pin1: LED_OK

Pin2: LED_PWM

Pin3: LED_

Pin4: LED_

Pin5:

Pin6:

Pin7:

'''Port D:'''

Pin0:

Pin1:

Pin2:

Pin3:

Pin4:

Pin5: TXCAN

Pin6: RXCAN

Pin7:

'''Port E:'''

Pin0: PDI

Pin1: PDO

Pin2:

Pin3:

Pin4:

Pin5:

Pin6:

Pin7:

'''Port F:'''

Pin0:

Pin1:

Pin2:

Pin3:

Pin4: TCK

Pin5: TMS

Pin6: TDO

Pin7: TDI

ECUs implementing Sensorboards and Actorboard

2010-08-17T11:15:25Z

Donald: /* 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==

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

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

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

{| 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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 <tt>/dev/mmcblk0p1</tt> is your MMC/SD card device's primary partition,

> mkfs.vfat -F 16 /dev/mmcblk0p1

would create a valid FAT 16 partition.

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

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

* Log file format
** The log file has a binary format, containing a dump of all CAN messages including a timestamp for each. For each CAN message, the following data fragment is written:

/----------------------------------------------------------\
| Header | Timestamp | CAN ID | Data Length | Data |
| 0xca | 4 Bytes | 2 Bytes | 1 Byte | 0 - 8 Bytes |
\----------------------------------------------------------------------------------------/

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

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

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

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

This will throw a window onto the screen.

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

set multiplot
unset multiplot

before the first plot and after the last plot.

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

######## Type your configuration here ########
canid = 8
infile = 'MiniMonLOG.csv'
outfile = "ploop.png"
minimon = 1
##############################################

# Touch this only if you know, what you are doing!

#this line prepares the logfiles
#note: theres a difference between data logged on the car and data logged from MiniMon
if(minimon) i_string = sprintf("< gawk -F\\; '{ gsub(/\\\"|:|\\.|[:blank:]/,\"\", $1); gsub(/\\\"|:|\\.|[:blank:]/,\"\",$2); s2 = strtonum(sprintf(\"0x%s\",$2)); gsub(/\\\"|:|\\.|[[:blank:]]/,\"\",$5); s3 = strtonum(sprintf(\"0x%s\",$5)); printf \"%s\\n\",$1,s2,s3 }' %s | sort | grep \";%d;\"", "%s", "%s", "%s;%s;%s", infile, canid); else i_string = sprintf("< grep ';%d;' '%s'", canid, infile)
# The above code has to be in a single line!

#initializing output
set terminal png large size 1280,1024
set output outfile
set grid
set xlabel 'Value'
set ylabel 'Time'
set title 'Messages sent via CAN'
unset key
set datafile separator ';'
#and plot data, prepared some lines above
plot [:] [:] i_string using 1:3 w lines

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

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

==Actorboard==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T11:14:43Z

Donald: /* 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==

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

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

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

{| 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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 <tt>/dev/mmcblk0</tt> is your MMC/SD card device's primary partition,

> mkfs.vfat -F 16 /dev/mmcblk0p1

would create a valid FAT 16 partition.

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

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

* Log file format
** The log file has a binary format, containing a dump of all CAN messages including a timestamp for each. For each CAN message, the following data fragment is written:

/----------------------------------------------------------\
| Header | Timestamp | CAN ID | Data Length | Data |
| 0xca | 4 Bytes | 2 Bytes | 1 Byte | 0 - 8 Bytes |
\----------------------------------------------------------------------------------------/

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

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

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

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

This will throw a window onto the screen.

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

set multiplot
unset multiplot

before the first plot and after the last plot.

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

######## Type your configuration here ########
canid = 8
infile = 'MiniMonLOG.csv'
outfile = "ploop.png"
minimon = 1
##############################################

# Touch this only if you know, what you are doing!

#this line prepares the logfiles
#note: theres a difference between data logged on the car and data logged from MiniMon
if(minimon) i_string = sprintf("< gawk -F\\; '{ gsub(/\\\"|:|\\.|[:blank:]/,\"\", $1); gsub(/\\\"|:|\\.|[:blank:]/,\"\",$2); s2 = strtonum(sprintf(\"0x%s\",$2)); gsub(/\\\"|:|\\.|[[:blank:]]/,\"\",$5); s3 = strtonum(sprintf(\"0x%s\",$5)); printf \"%s\\n\",$1,s2,s3 }' %s | sort | grep \";%d;\"", "%s", "%s", "%s;%s;%s", infile, canid); else i_string = sprintf("< grep ';%d;' '%s'", canid, infile)
# The above code has to be in a single line!

#initializing output
set terminal png large size 1280,1024
set output outfile
set grid
set xlabel 'Value'
set ylabel 'Time'
set title 'Messages sent via CAN'
unset key
set datafile separator ';'
#and plot data, prepared some lines above
plot [:] [:] i_string using 1:3 w lines

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

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

==Actorboard==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T08:03:58Z

Donald: /* LCD Display */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

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

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

{| 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

Main Page

2010-08-17T07:50:47Z

Donald: /* 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|The Fraunhofer IESE ConceptCar]]

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]]
**2.4 - Runtime Platforms
***[[FreeRTOS CortexM3 HowTo|2.4.1 - FreeRTOS CortexM3 HowTo]]

*[[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]

Sensors

2010-08-17T07:49:59Z

Donald: /* Distance Sensors */

The monitoring of the environment is implemented in the Concept Car using different sensors. In the following, all the sensors are described.

==Wheel speed sensors==

The rotation speed of the wheels is measured with simple optical sensors, where 26 black stripes in the inside of the wheel are passing a photo sensor. The Figure 1.5 shows the marks inside of the wheel.

[[image:CCarWheel.JPG|thumb|200px|Figure 1.5. Black Stripes Marks inside the Concept Car Wheel]]

A photo diode (CNY 70) detects the passing of the stripes, and from the interval since the last stripe has passed the wheel speed is derived. The resolution of the timers that measure the interval between two stripes is 0.25µs. Every 50ms the wheel speed of all four sensors is written to the CAN-Bus. Depending on the current wheel speed, one of the following conditions holds:

*1. The wheel speed is so low that no black stripe has passed within the last 50ms (may happen if speed is lower than 276.92°/s or 0.29m/s): The absence of a black stripe passing is communicated nevertheless
*2. During 50ms exactly one black stripe has passed. In this case the wheel speed is derived from this single value.
*3. During 50ms multiple stripes pass. In this case the average value is taken.

Let be the average interval length between two stripes with the resolution of 0.25µs. In the cases (2) and (3) the wheel speed can be calculated by Equation 1.1.

[[image:Equation2_1.JPG|thumb|200px|Equation 1.1]]

The sensory data from the wheel speed sensors is to be considered as extremely noisy, and should not be used by any system without applying adequate filtering algorithms, as described in [[Bibliography|[Mit09]]].

==Distance Sensors==

[[image:SRF02_sensor.jpg|thumb|left|100px|SRF02 distance sensor]]
On the front side of the car there are two ultrasonic distance sensors. They are triggered in alternating order every 65ms to measure the distance to the next obstacle in front of the car. Their range is 15cm to 6m, with a resolution of 1cm. For further details consult the documentation, accessible under [[Bibliography|[RHW09]]].

 

==Acceleration Sensors==

The acceleration of the Concept Car is measured with the ADIS16006 sensors. The dual-axis accelerometer ADIS16006 is capable of measuring -5g to +5g at a resolution of 1,9mg at 60Hz measurement rate. The maximum measurement range is ±8g. It has a built-in temperature sensor to mask out the temperature drift of the measurement results. For further details consult the documentation [[Bibliography|[Ana07]]].

==Rotation Sensor==

The vehicle rotation along the yaw axis is measured using a rotation sensor of the type ADIS16100. The dynamic range of the yaw rate sensor ADIS16100 is 300°/s at a resolution of 0.244°/s. This sensor also provides temperature information for separating out the temperature drift. Further documentation can be found under [[Bibliography|[Ana09]]].

==Radio Receiver Decoder==

The Radio Receiver outputs a pulse width modulation (PWM) signal. The PWM signal from the radio receiver’s channels must be decoded to be usable inside the system. Therefore the length of the pulses (duty cycle is 5% to 10%) is measured and normalized, with 5% being -100 to 10% being +100. The resolution is 0.01%. Radio receiver signals are sent over the CAN-Bus whenever a PWM-pulse with a valid duty cycle has been measured, so under typical driving conditions every 20ms for each channel.

File:SRF02 sensor.jpg

2010-08-17T07:49:41Z

Donald:

Sensors

2010-08-17T07:49:30Z

Donald: /* Distance Sensors */

The monitoring of the environment is implemented in the Concept Car using different sensors. In the following, all the sensors are described.

==Wheel speed sensors==

The rotation speed of the wheels is measured with simple optical sensors, where 26 black stripes in the inside of the wheel are passing a photo sensor. The Figure 1.5 shows the marks inside of the wheel.

[[image:CCarWheel.JPG|thumb|200px|Figure 1.5. Black Stripes Marks inside the Concept Car Wheel]]

A photo diode (CNY 70) detects the passing of the stripes, and from the interval since the last stripe has passed the wheel speed is derived. The resolution of the timers that measure the interval between two stripes is 0.25µs. Every 50ms the wheel speed of all four sensors is written to the CAN-Bus. Depending on the current wheel speed, one of the following conditions holds:

*1. The wheel speed is so low that no black stripe has passed within the last 50ms (may happen if speed is lower than 276.92°/s or 0.29m/s): The absence of a black stripe passing is communicated nevertheless
*2. During 50ms exactly one black stripe has passed. In this case the wheel speed is derived from this single value.
*3. During 50ms multiple stripes pass. In this case the average value is taken.

Let be the average interval length between two stripes with the resolution of 0.25µs. In the cases (2) and (3) the wheel speed can be calculated by Equation 1.1.

[[image:Equation2_1.JPG|thumb|200px|Equation 1.1]]

The sensory data from the wheel speed sensors is to be considered as extremely noisy, and should not be used by any system without applying adequate filtering algorithms, as described in [[Bibliography|[Mit09]]].

==Distance Sensors==

[[image:SRF02_sensor.jpg|thumb|left|100px|SRF02 distance sensor]]
On the front side of the car there are two ultrasonic distance sensors. They are triggered in alternating order every 65ms to measure the distance to the next obstacle in front of the car. Their range is 15cm to 6m, with a resolution of 1cm. For further details consult the documentation, accessible under [[Bibliography|[RHW09]]].

==Acceleration Sensors==

The acceleration of the Concept Car is measured with the ADIS16006 sensors. The dual-axis accelerometer ADIS16006 is capable of measuring -5g to +5g at a resolution of 1,9mg at 60Hz measurement rate. The maximum measurement range is ±8g. It has a built-in temperature sensor to mask out the temperature drift of the measurement results. For further details consult the documentation [[Bibliography|[Ana07]]].

==Rotation Sensor==

The vehicle rotation along the yaw axis is measured using a rotation sensor of the type ADIS16100. The dynamic range of the yaw rate sensor ADIS16100 is 300°/s at a resolution of 0.244°/s. This sensor also provides temperature information for separating out the temperature drift. Further documentation can be found under [[Bibliography|[Ana09]]].

==Radio Receiver Decoder==

The Radio Receiver outputs a pulse width modulation (PWM) signal. The PWM signal from the radio receiver’s channels must be decoded to be usable inside the system. Therefore the length of the pulses (duty cycle is 5% to 10%) is measured and normalized, with 5% being -100 to 10% being +100. The resolution is 0.01%. Radio receiver signals are sent over the CAN-Bus whenever a PWM-pulse with a valid duty cycle has been measured, so under typical driving conditions every 20ms for each channel.

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:48:08Z

Donald: /* Sensorboard Acceleration and Datalogging */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:47:41Z

Donald: /* LCD Display */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display status views" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:47:22Z

Donald: /* LCD Display */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display" widths="160px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:47:14Z

Donald: /* LCD Display */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display" widths="180px" heights="100px" perrow="5">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:46:59Z

Donald: /* LCD Display */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display" widths="100px" heights="100px" perrow="6">
image:LCD_Display_GYRO_Raw.jpg
image:LCD_Display_GYRO_Absolute.jpg
image:LCD_Display_Accel.jpg
image:LCD_Display_CANLoad.jpg
image:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:46:48Z

Donald: /* LCD Display */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display" widths="100px" heights="100px" perrow="6">
image:LCD_Display_GYRO_Raw.jpg
File:LCD_Display_GYRO_Absolute.jpg
File:LCD_Display_Accel.jpg
File:LCD_Display_CANLoad.jpg
File:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:46:39Z

Donald: /* Sensorboard Acceleration and Datalogging */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display" widths="100px" heights="100px" perrow="6">
File:LCD_Display_GYRO_Raw.jpg
File:LCD_Display_GYRO_Absolute.jpg
File:LCD_Display_Accel.jpg
File:LCD_Display_CANLoad.jpg
File:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

File:LCD Display Remote.jpg

2010-08-17T07:46:23Z

Donald:

File:LCD Display CANLoad.jpg

2010-08-17T07:46:04Z

Donald:

File:LCD Display Accel.jpg

2010-08-17T07:45:39Z

Donald:

File:LCD Display GYRO Absolute.jpg

2010-08-17T07:45:16Z

Donald:

File:LCD Display GYRO Raw.jpg

2010-08-17T07:44:50Z

Donald:

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:43:53Z

Donald: /* LCD Display */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display" widths="100px" heights="100px" perrow="6">
image:LCD_Display_GYRO_Raw.jpg
File:LCD_Display_GYRO_Absolute.jpg
File:LCD_Display_Accel.jpg
File:LCD_Display_CANLoad.jpg
File:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:43:33Z

Donald: /* Sensorboard Acceleration and Datalogging */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

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

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

 

===LCD Display===

<gallery caption="LCD Display" widths="100px" heights="100px" perrow="6">
File:LCD_Display_GYRO_Raw.jpg
File:LCD_Display_GYRO_Absolute.jpg
File:LCD_Display_Accel.jpg
File:LCD_Display_CANLoad.jpg
File:LCD_Display_Remote.jpg
</gallery>

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:38:34Z

Donald: /* Sensorboard Acceleration and Datalogging */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

This ECU controls the acceleration (longitudinal and lateral) and rotation (yaw rate) sensors over a SPI-Bus. It also measures the voltage of the battery that supplies the electrical components. [[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.

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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===

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

ECUs implementing Sensorboards and Actorboard

2010-08-17T07:38:16Z

Donald: /* Sensorboard Acceleration and Datalogging */

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

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FR and CANID_WHEELSPEED_RL]] as well as [[CAN_Bus#CANID_STEERING|CANID_STEERING]] for a description of this ECU's output signals.

===PWM Decoding and Signal Validity===

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

When steer by wire is enabled, these bad signals can be filtered, as the "normal" shape of an PWM signal is known: 20ms cycle length with 1ms to 2ms duty cycle. As these are not strict limits and a valid PWM signal may be a bit out of bounds, a valid PWM is assumed if
# its rising edge is 16ms - 18ms after the last rising edge and
# its duty cycle is 0.5ms - 2.5ms.
However, in the random noise, even pulses like these appear quite frequent, so for a better filtering, the signal is only assumed to be present if at least 3 consecutive valid PWM pulses have appeared.
The Sensorboards only transmit the measured PWM signal width if a valid signal is detected.

==Sensorboard Throttle==

[[image:sensorboard_steering_throttle_rev1.2.jpg|thumb|right|Sensorboard Throttle, Revision 1.2]]

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

See [[CAN_Bus#CANID_WHEELSPEED|CANID_WHEELSPEED_FL and CANID_WHEELSPEED_RR]] as well as [[CAN_Bus#CANID_THROTTLE|CANID_THROTTLE]] and [[CAN_Bus#CANID_BRAKE|CANID_BRAKEFL and CANID_BRAKEFR]] for a description of this ECU's output signals.

 

==Sensorboard Distance==

[[image:sensorboard_distance_rev1.2.jpg|thumb|right|Sensorboard Distance, Revision 1.2]]

This ECU accesses the [[media:SRF02_datasheet.pdf|SRF02 distance sensor]] over an serial UART Bus.

See [[CAN_Bus#CANID_DISTANCE|CANID_DISTANCE]] for more information about this ECU's output signals.

 

==Sensorboard Acceleration and Datalogging==

[[image:sensorboard_inertial_rev1.3.jpg|thumb|right|Sensorboard Acceleration, Gyro, Datalogging, Revision 1.3]]

This ECU controls the acceleration (longitudinal and lateral) and rotation (yaw rate) sensors over a SPI-Bus. It also measures the voltage of the battery that supplies the electrical components. [[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.

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

* If DIP switch 1 is "on", the display shows the current longitudinal acceleration (acc_x).
* Else if DIP switch 2 is "on", the display shows the current lateral acceleration (acc_y).
* Else if DIP switch 3 is "on", the display shows the current yaw rate.
* Else if DIP switch 4 is "on", the display shows the current supply voltage.
* Else if DIP switch 5 is "on", the display shows the filename that the data is logged to (if SD card is present) and the total number of bytes that have been written to this file so far.
* 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====

[[image:sensorboard_inertial_sd_slot.jpg|thumb|left|The SD Card Holder]]

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

;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==

[[image:actorboard_rev1.2.jpg|thumb|right|Actorboard, Revision 1.2]]
The ActorBoard's task is the creation of the PWM signals to drive the actuators. It receives the CAN messages and generates the respective PWM signals for controlling the ConceptCar’s actuators. It has four channels, each capable of generating an independent PWM signal:
# Steering (servo)
# Throttle (brushless motor controller)
# Brake Front Left (servo)
# Brake Front Right (servo)

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

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

Adding Resources to the Concept Car

2010-08-17T07:37:02Z

Donald: /* Regarding Upgrades of the ConceptCar */

== Regarding Upgrades of the ConceptCar ==

[[image:ECU_stack.jpg|thumb|right|300px|The ConceptCar's ECU mount stack]]
The Concept Car has a modular architecture allowing the addition of resources in a simple way. In order to integrate a new ECU into the ConceptCar, these things are important:
#It is attached to the [[CAN_Bus|CAN bus]], but does not disturb the regular operation of the car. This means that no already used CAN IDs may be overwritten and that the bus load has to be low enough.
#It fits the form factor of the ECU stacks on the ConceptCar, so it can be easily and properly mounted.
#It does not interfere with the [[Power_Supply|ConceptCar's power train]], especially does not short circuit the galvanic isolation.
Apart from that, new ECUs may interfere with whichever sensor or actor equipment should be mounted to the car.

This page illustrates the demands regarding the form factor of the small boards so they can fit into the ECU stacks. There they are well mounted and protected against physical damage by the massive metal box next to them.

 

==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|frame|right|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 in the list below
* A green power on LED (<tt>CHIP-LED0805</tt>) that is directly attached to the power supply is recommended.
* If any additional LEDs are required, they should be placed at the lower border, like the CAN LEDs 200mil away from it or like in the list below.
* 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>.

'''Component placement:'''

Reset Switch: 550x275;
C 100n: 865x 415;
R 10k: 865x335;

LEDS:
Power: Resistor (220 Ohms): 865x255;
LED: 65x175

LEDs with Resistors from left to rigt:
R: 1075x25;
LED: 1075x175;
R: 1230x255;
LED: 1230x175;
R: 1550x255;
R: 1800x255;
R: 2025x255;
R: 2225x255;

Diode BAS85: 2375x2745

Diode Minimelf: 2440x2430, angle 270°

Coil: 2215x2655, angle: 270°

MAX1837: 2365x2630, angle: 90°

Capacitor: 2285x2435

Capacitor: 2595x2435, angle 270°

AT90CAN128: 1825x840, angle 270° (not forced)

CAN: 1475x2150

JTAG: 2450x800

ISP: 2450x1610

ISP is mandatory, but JTAG can be omitted.

'''AT90CAN128 Pin Connections'''

'''Port A:'''

Pin0:

Pin1:

Pin2:

Pin3:

Pin4:

Pin5:

Pin6: CAN_STATUS0

Pin7: CAN_STATUS1

'''Port B:'''

Pin0:

Pin1: SCK

Pin2:

Pin3:

Pin4:

Pin5:

Pin6:

Pin7:

'''Port C:'''

Pin0:

Pin1: LED_OK

Pin2: LED_PWM

Pin3: LED_

Pin4: LED_

Pin5:

Pin6:

Pin7:

'''Port D:'''

Pin0:

Pin1:

Pin2:

Pin3:

Pin4:

Pin5: TXCAN

Pin6: RXCAN

Pin7:

'''Port E:'''

Pin0: PDI

Pin1: PDO

Pin2:

Pin3:

Pin4:

Pin5:

Pin6:

Pin7:

'''Port F:'''

Pin0:

Pin1:

Pin2:

Pin3:

Pin4: TCK

Pin5: TMS

Pin6: TDO

Pin7: TDI

File:ECU stack.jpg

2010-08-17T07:36:18Z

Donald: uploaded a new version of "Image:ECU stack.jpg"

File:ECU stack.jpg

2010-08-17T07:34:21Z

Donald: uploaded a new version of "Image:ECU stack.jpg"

File:SAL7-LA2.jpg

2010-08-17T07:32:52Z

Donald: uploaded a new version of "Image:SAL7-LA2.jpg"

Mechanical System

2010-08-17T07:32:01Z

Donald: /* Engine */

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|frame|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The battery can be cut off from the engine controller with an emergency switch (200A)
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Motor_control_and_panic_switch.jpg|thumb|right|400px|The engine control and the emergency switch]]

[[image:Figure2_2.JPG|frame|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1" cellpadding="5" cellspacing="0"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! POWER JAZZ 63V !! Characteristics (in English)
|-
| 18-45 || Cell count (NiCd/NiMH)
|-
| 5-15 || Cell count (LiPo)
|-
| 13-63 || Operating Voltage (V)
|-
| 120 || Contin. current (A) (2,4Ah battery)
|-
| 200 || Max. current (A) (15sec)
|-
| 84 || Size (mm) length
|-
| 51 || width
|-
| 35 || height
|-
| 220 || Weight (g) with cables
|-
| 4/6 || Cable-cross-section (mm²)
|-
| / || BEC
|-
| x || Auto Programming Mode
|-
| x || ProcCARD ability
|-
| x || Automatic Power Consumption APC
|-
| x || EMF brake can be disabled
|-
| / || Proportional brake
|-
| x || Reverse polarity protection
|-
| x || Short circuit protection
|-
| x || False start protection
|-
| x || Current limiting
|-
| x || Overtemp. protection
|-
| x || Undervoltage cutoff
|-
| x || -"- can be disabled
|-
| x || Slow down instead of cutoff*
|-
| x || Active free wheeling circuit
|-
| 8-32 || PWM frequency (kHz)
|-
| 1.9 || Total copper thickness
|-
| x || Reverse rotation direction
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

Mechanical System

2010-08-17T07:31:40Z

Donald: /* Engine */

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|frame|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The battery can be cut off from the engine controller with an emergency switch (200A)
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Motor_control_and_panic_switch.jpg|thumb|right|250px|The engine control and the emergency switch]]

[[image:Figure2_2.JPG|frame|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1" cellpadding="5" cellspacing="0"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! POWER JAZZ 63V !! Characteristics (in English)
|-
| 18-45 || Cell count (NiCd/NiMH)
|-
| 5-15 || Cell count (LiPo)
|-
| 13-63 || Operating Voltage (V)
|-
| 120 || Contin. current (A) (2,4Ah battery)
|-
| 200 || Max. current (A) (15sec)
|-
| 84 || Size (mm) length
|-
| 51 || width
|-
| 35 || height
|-
| 220 || Weight (g) with cables
|-
| 4/6 || Cable-cross-section (mm²)
|-
| / || BEC
|-
| x || Auto Programming Mode
|-
| x || ProcCARD ability
|-
| x || Automatic Power Consumption APC
|-
| x || EMF brake can be disabled
|-
| / || Proportional brake
|-
| x || Reverse polarity protection
|-
| x || Short circuit protection
|-
| x || False start protection
|-
| x || Current limiting
|-
| x || Overtemp. protection
|-
| x || Undervoltage cutoff
|-
| x || -"- can be disabled
|-
| x || Slow down instead of cutoff*
|-
| x || Active free wheeling circuit
|-
| 8-32 || PWM frequency (kHz)
|-
| 1.9 || Total copper thickness
|-
| x || Reverse rotation direction
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

File:Motor control and panic switch.jpg

2010-08-17T07:30:35Z

Donald:

Mechanical System

2010-08-17T07:30:23Z

Donald: /* Engine */

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|frame|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The battery can be cut off from the engine controller with an emergency switch (200A)
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Motor_control_and_panic_switch.jpg|thumb|right|250px|The engine control and the emergency switch]]

[[image:Figure2_2.JPG|frame|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! POWER JAZZ 63V !! Characteristics (in English)
|-
| 18-45 || Cell count (NiCd/NiMH)
|-
| 5-15 || Cell count (LiPo)
|-
| 13-63 || Operating Voltage (V)
|-
| 120 || Contin. current (A) (2,4Ah battery)
|-
| 200 || Max. current (A) (15sec)
|-
| 84 || Size (mm) length
|-
| 51 || width
|-
| 35 || height
|-
| 220 || Weight (g) with cables
|-
| 4/6 || Cable-cross-section (mm²)
|-
| / || BEC
|-
| x || Auto Programming Mode
|-
| x || ProcCARD ability
|-
| x || Automatic Power Consumption APC
|-
| x || EMF brake can be disabled
|-
| / || Proportional brake
|-
| x || Reverse polarity protection
|-
| x || Short circuit protection
|-
| x || False start protection
|-
| x || Current limiting
|-
| x || Overtemp. protection
|-
| x || Undervoltage cutoff
|-
| x || -"- can be disabled
|-
| x || Slow down instead of cutoff*
|-
| x || Active free wheeling circuit
|-
| 8-32 || PWM frequency (kHz)
|-
| 1.9 || Total copper thickness
|-
| x || Reverse rotation direction
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

Mechanical System

2010-08-17T07:29:03Z

Donald: /* Engine */

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|frame|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The battery can be cut off from the engine controller with an emergency switch (200A)
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Motor_control_and_panic_switch|thumb|right|250px|The engine control and the emergency switch]]

[[image:Figure2_2.JPG|frame|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! POWER JAZZ 63V !! Characteristics (in English)
|-
| 18-45 || Cell count (NiCd/NiMH)
|-
| 5-15 || Cell count (LiPo)
|-
| 13-63 || Operating Voltage (V)
|-
| 120 || Contin. current (A) (2,4Ah battery)
|-
| 200 || Max. current (A) (15sec)
|-
| 84 || Size (mm) length
|-
| 51 || width
|-
| 35 || height
|-
| 220 || Weight (g) with cables
|-
| 4/6 || Cable-cross-section (mm²)
|-
| / || BEC
|-
| x || Auto Programming Mode
|-
| x || ProcCARD ability
|-
| x || Automatic Power Consumption APC
|-
| x || EMF brake can be disabled
|-
| / || Proportional brake
|-
| x || Reverse polarity protection
|-
| x || Short circuit protection
|-
| x || False start protection
|-
| x || Current limiting
|-
| x || Overtemp. protection
|-
| x || Undervoltage cutoff
|-
| x || -"- can be disabled
|-
| x || Slow down instead of cutoff*
|-
| x || Active free wheeling circuit
|-
| 8-32 || PWM frequency (kHz)
|-
| 1.9 || Total copper thickness
|-
| x || Reverse rotation direction
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

Mechanical System

2010-08-17T07:26:44Z

Donald: /* Engine */

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|frame|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Figure2_2.JPG|frame|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! POWER JAZZ 63V !! Characteristics (in English)
|-
| 18-45 || Cell count (NiCd/NiMH)
|-
| 5-15 || Cell count (LiPo)
|-
| 13-63 || Operating Voltage (V)
|-
| 120 || Contin. current (A) (2,4Ah battery)
|-
| 200 || Max. current (A) (15sec)
|-
| 84 || Size (mm) length
|-
| 51 || width
|-
| 35 || height
|-
| 220 || Weight (g) with cables
|-
| 4/6 || Cable-cross-section (mm²)
|-
| / || BEC
|-
| x || Auto Programming Mode
|-
| x || ProcCARD ability
|-
| x || Automatic Power Consumption APC
|-
| x || EMF brake can be disabled
|-
| / || Proportional brake
|-
| x || Reverse polarity protection
|-
| x || Short circuit protection
|-
| x || False start protection
|-
| x || Current limiting
|-
| x || Overtemp. protection
|-
| x || Undervoltage cutoff
|-
| x || -"- can be disabled
|-
| x || Slow down instead of cutoff*
|-
| x || Active free wheeling circuit
|-
| 8-32 || PWM frequency (kHz)
|-
| 1.9 || Total copper thickness
|-
| x || Reverse rotation direction
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

Mechanical System

2010-08-17T07:24:02Z

Donald: /* Engine */

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|frame|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Figure2_2.JPG|frame|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! Characteristics (in German) !! POWER JAZZ 63V !! Characteristics (in English)
|-
| Zellenzahl (NiCd/NiMH) || 18-45 || Cell count (NiCd/NiMH)
|-
| Zellenzahl (LiPo) || 5-15 || Cell count (LiPo)
|-
| Spannungsbereich (V) || 13-63 || Operating Voltage (V)
|-
| Dauerstrom (A) (2,4AH Akku) || 120 || Contin. current (A) (2,4Ah battery)
|-
| max. Strom (A) (15sec) || 200 || Max. current (A) (15sec)
|-
| Maße (mm) Länge || 84 || Size (mm) length
|-
| Breite || 51 || width
|-
| Höhe || 35 || height
|-
| Gewicht (g) ohne Kabel || - || Weight (g) without cables
|-
| Gewicht (g) mit Kabel || 220 || Weight (g) with cables
|-
| Kabelquerschnitt (mm²) || 4/6 || Cable-cross-section (mm²)
|-
| BEC || / || BEC
|-
| BEC Belastbarkeit max. (A) || / || BEC current max. (A)
|-
| BEC Kurzschlußfest || / || BEC short circuit protection
|-
| Auto-Programmier-Modus || x || Auto Programming Mode
|-
| Modusprogrammierung || / || Mode programming
|-
| ProgCARD fähig || x || ProcCARD ability
|-
| Heli Drehzahlregelung || x || Automatic Power Consumption APC
|-
| EMK-Bremse abschaltbar || x || EMF brake can be disabled
|-
| proportionale Bremse || / || Proportional brake
|-
| Verpolschutz || x || Reverse polarity protection
|-
| Kurzschlußschutz || x || Short circuit protection
|-
| Anlaufschutz || x || False start protection
|-
| Strombegrenzung || x || Current limiting
|-
| Übertemperaturschutz || x || Overtemp. protection
|-
| Unterspannungsabschaltung || x || Undervoltage cutoff
|-
| -"- abschaltbar || x || -"- can be disabled
|-
| Abschaltspann./Zelle variabel* || x || Slow down instead of cutoff*
|-
| Abregelung statt Abschaltung* || x || Slow down instead of cutoff*
|-
| aktiver Freilauf || x || Active free wheeling circuit
|-
| LED Statusanzeige || / || -
|-
| Taktfrequenz (kHz) || 8-32 || PWM frequency (kHz)
|-
| Gesamte Kupferstärke (mm) || 1.9 || Total copper thickness
|-
| Drehrichtungsumpolung || x || Reverse rotation direction
|-
| Bestellnummer || 4991 || Order number
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

Mechanical System

2010-08-17T07:23:46Z

Donald: /* Engine */

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|frame|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Figure2_2.JPG|thumb|500px|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! Characteristics (in German) !! POWER JAZZ 63V !! Characteristics (in English)
|-
| Zellenzahl (NiCd/NiMH) || 18-45 || Cell count (NiCd/NiMH)
|-
| Zellenzahl (LiPo) || 5-15 || Cell count (LiPo)
|-
| Spannungsbereich (V) || 13-63 || Operating Voltage (V)
|-
| Dauerstrom (A) (2,4AH Akku) || 120 || Contin. current (A) (2,4Ah battery)
|-
| max. Strom (A) (15sec) || 200 || Max. current (A) (15sec)
|-
| Maße (mm) Länge || 84 || Size (mm) length
|-
| Breite || 51 || width
|-
| Höhe || 35 || height
|-
| Gewicht (g) ohne Kabel || - || Weight (g) without cables
|-
| Gewicht (g) mit Kabel || 220 || Weight (g) with cables
|-
| Kabelquerschnitt (mm²) || 4/6 || Cable-cross-section (mm²)
|-
| BEC || / || BEC
|-
| BEC Belastbarkeit max. (A) || / || BEC current max. (A)
|-
| BEC Kurzschlußfest || / || BEC short circuit protection
|-
| Auto-Programmier-Modus || x || Auto Programming Mode
|-
| Modusprogrammierung || / || Mode programming
|-
| ProgCARD fähig || x || ProcCARD ability
|-
| Heli Drehzahlregelung || x || Automatic Power Consumption APC
|-
| EMK-Bremse abschaltbar || x || EMF brake can be disabled
|-
| proportionale Bremse || / || Proportional brake
|-
| Verpolschutz || x || Reverse polarity protection
|-
| Kurzschlußschutz || x || Short circuit protection
|-
| Anlaufschutz || x || False start protection
|-
| Strombegrenzung || x || Current limiting
|-
| Übertemperaturschutz || x || Overtemp. protection
|-
| Unterspannungsabschaltung || x || Undervoltage cutoff
|-
| -"- abschaltbar || x || -"- can be disabled
|-
| Abschaltspann./Zelle variabel* || x || Slow down instead of cutoff*
|-
| Abregelung statt Abschaltung* || x || Slow down instead of cutoff*
|-
| aktiver Freilauf || x || Active free wheeling circuit
|-
| LED Statusanzeige || / || -
|-
| Taktfrequenz (kHz) || 8-32 || PWM frequency (kHz)
|-
| Gesamte Kupferstärke (mm) || 1.9 || Total copper thickness
|-
| Drehrichtungsumpolung || x || Reverse rotation direction
|-
| Bestellnummer || 4991 || Order number
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

Mechanical System

2010-08-17T07:23:25Z

Donald:

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|400px|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|thumb|500px|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Figure2_2.JPG|thumb|500px|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! Characteristics (in German) !! POWER JAZZ 63V !! Characteristics (in English)
|-
| Zellenzahl (NiCd/NiMH) || 18-45 || Cell count (NiCd/NiMH)
|-
| Zellenzahl (LiPo) || 5-15 || Cell count (LiPo)
|-
| Spannungsbereich (V) || 13-63 || Operating Voltage (V)
|-
| Dauerstrom (A) (2,4AH Akku) || 120 || Contin. current (A) (2,4Ah battery)
|-
| max. Strom (A) (15sec) || 200 || Max. current (A) (15sec)
|-
| Maße (mm) Länge || 84 || Size (mm) length
|-
| Breite || 51 || width
|-
| Höhe || 35 || height
|-
| Gewicht (g) ohne Kabel || - || Weight (g) without cables
|-
| Gewicht (g) mit Kabel || 220 || Weight (g) with cables
|-
| Kabelquerschnitt (mm²) || 4/6 || Cable-cross-section (mm²)
|-
| BEC || / || BEC
|-
| BEC Belastbarkeit max. (A) || / || BEC current max. (A)
|-
| BEC Kurzschlußfest || / || BEC short circuit protection
|-
| Auto-Programmier-Modus || x || Auto Programming Mode
|-
| Modusprogrammierung || / || Mode programming
|-
| ProgCARD fähig || x || ProcCARD ability
|-
| Heli Drehzahlregelung || x || Automatic Power Consumption APC
|-
| EMK-Bremse abschaltbar || x || EMF brake can be disabled
|-
| proportionale Bremse || / || Proportional brake
|-
| Verpolschutz || x || Reverse polarity protection
|-
| Kurzschlußschutz || x || Short circuit protection
|-
| Anlaufschutz || x || False start protection
|-
| Strombegrenzung || x || Current limiting
|-
| Übertemperaturschutz || x || Overtemp. protection
|-
| Unterspannungsabschaltung || x || Undervoltage cutoff
|-
| -"- abschaltbar || x || -"- can be disabled
|-
| Abschaltspann./Zelle variabel* || x || Slow down instead of cutoff*
|-
| Abregelung statt Abschaltung* || x || Slow down instead of cutoff*
|-
| aktiver Freilauf || x || Active free wheeling circuit
|-
| LED Statusanzeige || / || -
|-
| Taktfrequenz (kHz) || 8-32 || PWM frequency (kHz)
|-
| Gesamte Kupferstärke (mm) || 1.9 || Total copper thickness
|-
| Drehrichtungsumpolung || x || Reverse rotation direction
|-
| Bestellnummer || 4991 || Order number
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.

File:ConceptCar total view open.jpg

2010-08-17T07:23:07Z

Donald:

Mechanical System

2010-08-17T07:22:55Z

Donald:

__FORCETOC__

[[image:ConceptCar_total_view_open.jpg|thumb|right|The Fraunhofer IESE ConceptCar]]

The base platform of the Concept Car is a RC Car Model CE-5 from Carson Modellbau. This platform has the following parameters:

* Scale is 1:5
* Dimensions (l*w*h) are 80cm * 40cm * 23 cm
* Weight is ~ 8.4kg
* Top speed is ~60km/h
* Rubber wheels, 12cm in diameter
* Gear reduction from motor shaft to rear wheels is 20:44 * 20:77 (2 transmissions)
* Differential gear

==Engine==

The Concept Car engine is based on an air-cooled sensorless brushless electrical motor, which is presented in Figure 1.1.

[[image:Figure2_1.JPG|thumb|500px|Figure 1.1. Basic Description of the Concept Car Engine]]

Each part of the engine presented in Figure 1.1 is described in the following:

* The motor is a 1930/9 from Lehner Motoren and its characteristics are shown in Figure 1.2 [[Bibliography|[LM09]]].
* The engine control is a Power JAZZ from Kontronik. Its characteristics are presented in Table 1.1 [[Bibliography|[Kon09]]].
* The power is supplied by an accumulator with a nominal voltage of ~21V and the ability to sustain a permanent discharge current of at least 80A. The actual type and internal construction of the accumulator is irrelevant, as long as these specifications are met. Currently a 5S1 LiPo accumulator is used.
* The 5-6V supply voltage of the steering servo (max. 3A) is generated by a high-efficiency step-down voltage converter.

[[image:Figure2_2.JPG|thumb|500px|Figure 1.2. Motor Characteristics]]

Due to its sensorless nature, the engine tends to stutter when the car is pulling off.

{| border="1"
|+ '''Table 1.1: Kontronik Power JAZZ characteristics'''
! Characteristics (in German) !! POWER JAZZ 63V !! Characteristics (in English)
|-
| Zellenzahl (NiCd/NiMH) || 18-45 || Cell count (NiCd/NiMH)
|-
| Zellenzahl (LiPo) || 5-15 || Cell count (LiPo)
|-
| Spannungsbereich (V) || 13-63 || Operating Voltage (V)
|-
| Dauerstrom (A) (2,4AH Akku) || 120 || Contin. current (A) (2,4Ah battery)
|-
| max. Strom (A) (15sec) || 200 || Max. current (A) (15sec)
|-
| Maße (mm) Länge || 84 || Size (mm) length
|-
| Breite || 51 || width
|-
| Höhe || 35 || height
|-
| Gewicht (g) ohne Kabel || - || Weight (g) without cables
|-
| Gewicht (g) mit Kabel || 220 || Weight (g) with cables
|-
| Kabelquerschnitt (mm²) || 4/6 || Cable-cross-section (mm²)
|-
| BEC || / || BEC
|-
| BEC Belastbarkeit max. (A) || / || BEC current max. (A)
|-
| BEC Kurzschlußfest || / || BEC short circuit protection
|-
| Auto-Programmier-Modus || x || Auto Programming Mode
|-
| Modusprogrammierung || / || Mode programming
|-
| ProgCARD fähig || x || ProcCARD ability
|-
| Heli Drehzahlregelung || x || Automatic Power Consumption APC
|-
| EMK-Bremse abschaltbar || x || EMF brake can be disabled
|-
| proportionale Bremse || / || Proportional brake
|-
| Verpolschutz || x || Reverse polarity protection
|-
| Kurzschlußschutz || x || Short circuit protection
|-
| Anlaufschutz || x || False start protection
|-
| Strombegrenzung || x || Current limiting
|-
| Übertemperaturschutz || x || Overtemp. protection
|-
| Unterspannungsabschaltung || x || Undervoltage cutoff
|-
| -"- abschaltbar || x || -"- can be disabled
|-
| Abschaltspann./Zelle variabel* || x || Slow down instead of cutoff*
|-
| Abregelung statt Abschaltung* || x || Slow down instead of cutoff*
|-
| aktiver Freilauf || x || Active free wheeling circuit
|-
| LED Statusanzeige || / || -
|-
| Taktfrequenz (kHz) || 8-32 || PWM frequency (kHz)
|-
| Gesamte Kupferstärke (mm) || 1.9 || Total copper thickness
|-
| Drehrichtungsumpolung || x || Reverse rotation direction
|-
| Bestellnummer || 4991 || Order number
|}

==Radio Control==
The ConceptCar is remotely operated via a standard 2 channel 27MHz radio transmitter system. The channels are used for throttle and steering data. The radio receiver generates a 50Hz PWM signal with 5% to 10% duty cycle.

==Steering System==
The steering system has simple mechanics; a servo motor sets the steering angle. Within a range of ±30° the steering angle is set to (pulse – 1.5ms) * 1° / 0.018ms, where “pulse” denotes the length of a PWM pulse at a PWM frequency of 50Hz.

==Brakes==
[[image:hydraulic_brakes.jpg|thumb|right|The ConceptCar's hydraulic brakes]]
The ConceptCar features a set of hydraulic brakes on the front wheels. At the current state, they can not be triggered separately, but the electrical system is already prepared for that.