CAN is a robust and widely spread data bus standard which is among other applications also used in almost all modern vehicles for communication between the various controllers in it.
The ANavS Multi-Sensor RTK Module (MSRTK Module) comes with a CAN Interface that allows the user to input wheel odometry values and/or to access the solution data over that interface. When equipped, the Interface can be accessed by the DE-9 connector on the module. The pin assignment is in accordance with CiA® 303-1 and also given below:
[https://commons.wikimedia.org/wiki/File:Numbered_DE9_Diagram.svg, All Rights Released]
Pin | Pin assignment |
1 | Not connected |
2 | CAN-L |
3 | GND |
4 | Not connected |
5 | GND |
6 | Not connected |
7 | CAN-H |
8 | Not connected |
9 | Not connected |
The CAN Interface can be fully configured in the ANavS Wizard, where the whole configuration is done in the second step of the initialization process. The CAN-settings are divided in three categories: the bus settings and the two functions odometry input (CAN-Input) and solution output (CAN-Output). Every section has three buttons to get, set and restore the configurations of the corresponding section. By pressing the GET configuration button the configurations currently stored in the configuration file of the MSRTK module is loaded for this section. By pressing SET configuration, the configurations from this section are written in the configuration file and executed in the system. By pressing RESTORE configuration, the default configurations provided by ANavS gets restored. The configuration process is now explained in more detail:
CAN Bus settings:
In this section, all physical settings of the CAN Interface are configured. These are:
Odometry input via CAN:
The ANavS sensor fusion can handle different forms of vehicle odometry. Up to 5 variables can therefore be defined. These are either one, two or four independent wheel speeds, and the steering angle or another heading information of the vehicle in the vehicle frame. The algorithms inside of the sensor fusion software calculate from the different inputs the current velocity and heading information in the body frame of the vehicle for the positioning algorithm.
To adjust the CAN-Interface to your specific messages, see the following guide: Dynamic Decoder – How To
Solution output via CAN:
The CAN Interface can be used to output the solution from the sensor fusion software. The CAN Interface sends for each solution variable a unique message containing the value. The CAN address corresponds to the ID of the variable. The variables are bundled in groups which can be activated or deactivated by checking the corresponding boxes. As standard, each packet has a unique ID which is also shown in the table below. To change the IDs of the CAN messages (e.g. to avoid collisions with the information of other devices on the bus), there is the possibility to add an offset to all messages. Â To use the solution output via CAN, the bus must be configured in the normal mode and the output has to be enabled (see also section Bus settings).
ID | Format | Name | Unit | Description |
1 | uint16 | resCode | – | Result code bitfield, which keeps the system status and information. |
2 | uint16 | week | – | Week number of the current epoch. |
3 | double | tow | s | Time of Week of the current epoch. |
4 | uint16 | weekInit | – | Week number of the epoch when the system was started. |
5 | double | towInit | s | Time of Week of the epoch when the system was started. |
7 | double | lat | deg | Latitude. |
8 | double | lon | deg | Longitude. |
9 | double | height | m | Height |
10 | double | ECEF-X | m | X-position in ECEF-coordinate frame |
11 | double | ECEF-Y | m | Y-position in ECEF-coordinate frame |
12 | double | ECEF-Z | m | Z-position in ECEF-coordinate frame |
13 – 15 | 3*double | b | m | Baseline in NED frame spanned by the position given by lat, lon and height, and by the position of the reference station. |
16 – 18 | 3*double | bStdDev | m | Standard deviation of the baseline. |
19 – 21 | 3*double | vel | m/s | Velocity in NED frame. |
22 – 24 | 3*double | velStdDev | m/s | Standard deviation of the velocity. |
25 – 27 | 3*double | acc | m/s² | Acceleration in body frame. |
28 – 30 | 3*double | accStdDev | m/s² | Standard deviation of the acceleration. |
31 – 33 | 3*double | att | deg | Attitude/Euler angles (heading, pitch, roll). |
34 – 36 | 3*double | attStdDev | deg | Standard deviation of the attitude. |
39 – 43 | 5*double | timing-Info | s | CPU-Load of used sensors. The sum (green line in the GUI) of elapsed time should not over 1 second (–> to slow processor). First double: Elapsed time GNSS; Second double: Elapsed time IMU; Third double: Elapsed time Baro; Fourth double: Elapsed time Odometry; Fifth double: Reserved |
46 | double | latency-info | s | Overall end-to-end positioning latency |
49 | double | gnssReception | – | Scalar, which indicates the GNSS signal reception. The value is between 0 and 20, where 20 is the best, i.e. very good conditions. |
50 | uint8 | numSats | – | Number of satellites. |