An inclinometer is a sensor for measuring angles of slope (or tilt), elevation or inclination of a machine, for example a crane, or of a vehicle or any other item. It generates an artificial horizon and measures angular tilt with respect to this horizon. Such a sensor measures both inclines (positive slopes, as seen by an observer looking upwards) and declines (negative slopes, as seen by an observer looking downward). So to say, the inclinometer is an electronic water scale for sensing alignments to the horizontal line. The tasks for inclino­meters are manifold, ranging from accident prevention at cranes, excavators, and floor conveyors up to level sensing and machine control.
For use in construction machines, trucks, off-highway vehicles, or in control systems for platform leveling, or boom angle indicators those sensors are connected to a CAN network. The increasing acceptance of CANopen caused the manufacturers to implement this higher-layer protocol and the standardized CiA 410 device profile for inclinometers. This profile specifies some configuration parameters and the PDO mapping for 16-bit and 32-bit measurements. The table shows some inclinometers compliant to the CiA 410 profile, it is not claimed that the list is complete.
Important specifications to consider when searching for inclinometers are the tilt angle range and number of axes (which are usually, but not always, orthogonal). Common sensor technologies for inclinometers are accelerometer, liquid capacitive, electrolytic, gas bubble in liquid, and pendulum. Important is the packaging and the achieved protection class. In some of the outdoor applications IP65-rated may be sufficient, while others require an IP67-rated housing. These higher rated devices do not provide external switches for node-ID or CAN bit-rate assignments. They need to support the Layer Setting Services (LSS) as specified in CiA 305. Automatic bit-rate detection is an alternative for setting the transmission speed. Configuring node-ID or bit-rate by means of SDO may cause serious problems, if the store and restore parameter function is supported.

Single- anddual-axes sensors

There are single- and dual-axes inclinometers available. If the sensor is designed to measure inclination angles in two directions X and Y in the range of ±90º, a second one can be mounted vertically, in order to measure ±180º (0° to 360º) range. Normally, there are two identical functional blocks, sensor X and sensor Y, presenting angular data from two orthogonal sensing directions of the inclinometer. The sensor measures angles between the sensing directions and the ground plane. It is mounted horizontally, with the sensing direction vectors being in parallel with the ground plane. When a sensing direction vector points up, out of the ground plane, the inclination angle is considered to be positive, and when the sensing direction vector points down, into the ground plane, it is negative.
The vertically mounted sensor functional block provides the single axis functionality. It is available only when the inclinometer is mounted vertically, orthogonally to the ground plane. In this position, if kept vertically, the sensor can measure an inclination angle in one direction in the whole ±180° range. The sensing direction of the vertically mounted sensor is the same as the Y sensing direction of the regularly (horizontally) mounted sensor. When the X sensing direction points up and the Y sensing direction points to the right, and is in parallel with the ground plane, the inclination angle is zero. ...

Bernd Riedel (Selectron)

CAN and CANopen became hidden standards on trains. CAN-based devices has been used in several thousands quantities and in many different train applications. One of the recent applications is described in this article.
In 2008 SBB (Sch wei­zerische Bundesbahn, Swiss Federal Railways) has ordered a fleet of a new generation of the double-deck train “Dosto”. As contractor of 50 plus 24 consists (type A: two power cars, four coaches; type B: two power cars, two coaches) Stadler Rail in Switzerland was chosen. The train operator was S-Bahn Zürich in Switzerland. Roll out of the first consist was the third of June in 2010. Putting in public operation is planned in 2011.
The train manufacturer has chosen train communication and monitoring systems from the Swiss company Selectron Systems. The concept of consists allows to couple two power cars and from two up to six coaches. This leads to a maximum of eight units per consist. At a maximum four consists can be inaugurated to one train. The maximal train length is 600 m. The train control system has to couple and operate in the new SBB „Dosto“ just as well as in the established SBB train type “Flirt”.

System concept

On the vehicle bus level, one train is composed of two power cars and four (two) coaches. CANopen is used as a vehicle bus in cars and also in coaches. In every power car the CANopen network structure is redundant, whereas in coaches it is not redundant. The two power cars are connected via the train bus CAN-Powerline with a train bus coupler (TBC). This is also required for multi-traction. The whole train bus system is redundant. Some dedicated signals such as door control or emergency brake are connected directly i.e. not via a bus system. On the consist network – used for consist inauguration and diagnostic data – cars and coaches communicate via Ethernet. A separate network regarding passenger information system, video supervision and operating control system is implemented. This network is specified by SBB and not described in this article. It is based on Ethernet and is connected to the Ethernet consist network (ECN). A multifunction vehicle bus (MVB) for the European train control system, speed measurement, automatic train protection and public address equipment is integrated into the train communication network (TCN) via a CAN-to-MVB gateway. Safety critical signals are supervised by a separate supervision control unit (SCU) or implemented with safety relay technology. All incorporated networks are interconnected by means of gateways.
Power car networks
Vehicle busses CANopen 1 and 2 are designed redundant and interconnect the vehicle control units (VCU), I/O devices and every control units of the sub-system. A VCU represents the “heart” of the train. Two VCUs are in use, one as ”strong” master and the other as a ”weak” one. Depending on which driver’s desk the train will be started up, VCU 1 becomes the ”strong” or ”weak” master (VCU 2 vice versa). This monitoring concept improves the train availability.
Other sub-systems such as speed measurement, current converter and door control are also connected to the vehicle bus. In case that one vehicle bus fails, traction power will be reduced to 75 % but essential functions such as drive and break still remain.

The Robochair project develops a mobile robotics open platform for wheelchair-based robots. It has been developed as add-on module for commercial wheelchairs. Its design is modular and based on open interfaces for easy extension, robust and low-cost enough to be affordable to most of the people with disabilities.
Environment sensing and information processing are done by means of low-cost sensors and small form factor single board computer (SBC). The coupling between environment constraints (detected obstacles and target to reach) and wheelchair’s power module is implemented by using CANopen networks.
The Robochair system is developed around the Player robotics framework and implements all the devices needed to be Player-compatible. This way, third-party Player developers’ source code could be run in Robochair. In addition, and from hardware developer’s point of view, Robochair defines a low-level communication interface based on CANopen, that allows the interoperability and exchangeability among third-party robotics devices.
As shown in Figure 1, the distributed control system has a main device for global control and configuration tasks. The other devices perform only local tasks, so the minimum necessary data will be sent to the main module. This way, the manner each local task is solved is transparent to the main module, and consequently to any high-level application running in it. When a device is connected to the system, the main module detects its features and checks what kind of services it offers to the system. Robochair uses Can festival, which is an open source implementation of the CiA 301 CANopen application layer.
The sensor selection is a critical task and defines how the system could sense the environment. There are several types of sensors used to perceive the surroundings of the robot; ultrasonic, infrared and laser range finders are the most popular. There are a lot of different models with a variable list of features and cost from a huge variety of manufactures. Among the low-cost ones, SRF08 ultrasonic range finders by Devantech and GP2D12 infrared range finders by Sharp were selected due to their price/features relation. Several others were analyzed and ruled out by some undesirable features. Laser range finders were also ruled out due to their high cost.
A force feedback joystick has been selected as input/output method. Force feedback or haptic refers to a technology, which interfaces the user via the sense of touch by applying forces, vibrations and motions to the user. This mechanical stimulation is used, for example, to create virtual objects, which allow the user feel their shape. In the other hand, and regarding to wheelchairs, it could also be used to inform the user about the system status in a no intrusive manner. The second device selected was a touch LCD screen in order to provide the user with graphical information. Some soft button and a virtual joystick were developed to control the navigation of the wheelchair.

Software components

The high-level software interfaces defined by Robochair are based in the Player framework and are called Player interfaces. Player extensively uses the software interface concept. Different drivers, that control different devices with the same functionality (or almost), must provide the same Player interface. Player defines several interfaces for the control of well-known robotics devices. As shown in the figure, Robochair uses 2‑dimensional position, sonar, infrared (IR), and power Player interfaces for the remaining devices. The 2D-position interface is used to move the robot and to retrieve its pose (the robot position and orientation according to a given reference system). Sonar and IR interfaces are used to receive distance reading from ultrasonic and infrared sensor, respectively. The power interface is used to read the battery status and the remaining capacity. For their specification refer to Player documentation....