CiA 462: CANopen device profile for item detection devices
The profile specifies the CANopen interface for devices that identify existence, dimension, orientation or movement of items in their environment e.g. optical camera (2D or 3D) or laser device. Implementing the profile, the item detection device manufacturer may supply diverse application fields using the same electronic CANopen interface implementation and just adapting the required application functionality. A system designer may choose between CANopen devices from different manufacturers implementing the same profile-compliant functionality. For development, analysis, and maintenance of the devices, off-the-shelf CANopen tools may be used.
An item detection device collects environmental data of a physical effect such as light, radar, ultrasonic sound etc. It collects the data once, event-driven, time-based or stream-oriented. After processing the collected information fulfilled via defined algorithms and controlled by calibration, by ROI (region of interest) definition, and by configuration data etc., a list of detected real-world items is created and delivered for post-processing by an attached control unit.
The specified FSA (finite state automaton) defines the behavior of an item detection device as a host controller expects it. Each state of the FSA specifies an internal and external behavior of the item detection device. After the start, configuration, and activation, an error-free device supports triggered and/or cyclic measurement methods. The device type parameter (index 1000h) indicates which functions the device supports. These are the 2D-mode (front-side detection), the so-called 2,5D-mode (front-side detection including distance to the detected item), or the 3D-mode (box-mode with enabled depth detection). The tracking ability is characterized by identification and recognition of an item over time and through space. It is relevant for the prediction of future position of an item (e.g. in the air traffic, it predicts the arrival of certain aircrafts) and for calculation of the arrival time of an item at a certain place (e.g. used in navigation systems/route guidance systems). Further, the measurement method (triggered and/or cyclic) is indicated by the device type parameter.
Only TPDOs (transmit process data objects) are used to send out item data or sensor output data. RPDOs are used to receive runtime data. Calibration data is communicated via SDOs. The profile pre-defines two RPDOs providing the item detection device control word (RPDO 1) as well as the analog and digital sensor parameters (RPDO 2). It is possible to define the TPDOs completely manufacturer-specific or to use a pre-defined TPDO communication type 1 or 2 mapping. Type 1 supports the tracking of detected items and mandatorily provides the detected item position and the FSA state of the item detection device (TPDO 1), item velocity (TPDO 2), as well as the digital and analog sensor results (TPDO 3). Type 2 mapping comprises four TPDOs. It mandatorily provides the item position and the size of the detected items expressed via three vectors.
The defined application objects include the maximum number of supported items, item-ID, quality, and item estimation. Furthermore, the position, velocity, and acceleration values with matching quality values are specified. Also given is the duration in the region of interest (ROI, there the item detection device does its measurement) and the duration in the field of view. The attributes of a detected item are provided by the very same sub-index of the related objects. A reader of the item information assembles the information of the same sub-index and provides all attributes of a certain item via one object (string). Further objects specify the resolution of the data, analog/digital sensor results, and parameters, as well as the quality of the latter. The 16 specified ROIs are controlled/verified (enabled/disabled) via the ROI control/status word. Via the detection mode setting it is possible to choose between the box-detection and the front-side detection mode. Finally the control and status word of the item detection device as well as the storage type of the detected items are specified.
A profile-compliant device supports a bit-rate of 500 kbit/s (and optionally others) and emergency messages (see CiA 301). For dynamic bit-rate assignment, automatic bit-rate detection (see CiA 801) has to be supported. Dynamic node-ID assignment (if required) is done via LSS (see CiA 305).
|CiA 301 version 4.2.0CANopen application layer and communication profile|
DescriptionThis specification specifies the CANopen application layer. This includes the data types, encoding rules and object dictionary objects as well as the CANopen communication services and protocols. In addition, this specification specifies the CANopen network management services and protocols. This specification specifies the CANopen communication profile, e.g. the physical layer, the predefined communication object identifier connection set, and the content of the Emergency, Timestamp, and Sync communication objects.
|CiA 305 version 3.0.0CANopen layer setting services (LSS) and protocols|
DescriptionThis document specifies the layer setting services (LSS) and protocols for CANopen. These services and protocols are used to inquire or to change the settings of three parameters of the physical layer, data link layer, and application layer on a CANopen device with LSS slave capability by a CANopen device with LSS master capability via the CAN network. The following parameters may be inquired or changed: Node-ID of the CANopen device, bit timing parameters of the physical layer (bit rate), LSS address compliant to the identity object (1018h).
|CiA 462 version 1.0.0CANopen device profile for item detection devices|
DescriptionThis profile specifies the CANopen interface for devices that identify existence, dimension, orientation, or movement of items in their environment (e.g. optical camera (2D or 3D), laser device). Often those devices are called vision sensors or object detection devices.
|CiA 801 version 1.0.0CANopen automatic bit-rate detection|
DescriptionThis technical report describes the recommended practice and gives application hints for implementing automatic bit-rate detection in CANopen devices. With the Layer Setting Services (LSS) it is possible to change the bit-rate in CANopen networks. However, this mechanism fails in certain situations. Some low-cost devices that do not support LSS at all could also benefit from the recommended automatic bit-rate detection method. This technical report discusses an approach for automatic bit-rate detection in CANopen networks. As introduction the possible solutions to detect an unknown bit-rate for CAN controllers (Software / Hardware) are presented. The technical report will focus on situations where automatic bit-rate detection fails (no traffic on the bus, error frames) and how to avoid these deadlocks.