Академический Документы
Профессиональный Документы
Культура Документы
Mattia Martinelli
Acknowledgments.
This project has been carried out at CERN (European Organization for Nuclear Research) in
collaboration with a partner company: TeraBee1.
Mattia Martinelli
Geneva, the 27th of August 2015
1
http://www.terabee.com/
2
Train Inspection Monorail (explained in this document).
This page was intentionally left blank.
TABLE OF CONTENTS
Introduction 3
3 Firmware
1. Specifications ................................................................................................................................ 15
1.1 Brief description .................................................................................................................... 15
1.2 Distance check ...................................................................................................................... 15
1.3 Data integrity check .............................................................................................................. 16
1.4 System check......................................................................................................................... 16
1.5 Upper level interface ............................................................................................................ 16
1
1.6 Output flags........................................................................................................................... 16
2. Simplified structure....................................................................................................................... 17
3. Firmware versions ......................................................................................................................... 18
3.1 Version 1 ............................................................................................................................... 18
3.2 Version 1.1 ............................................................................................................................ 18
3.3 Version 1.2 ............................................................................................................................ 18
2.4 Version 1 NO UART ............................................................................................................... 19
2.5 Version 2.0 ............................................................................................................................ 19
3. Firmware development................................................................................................................. 20
4. Firmware test ................................................................................................................................ 21
4.1 Description ............................................................................................................................ 21
4.2 Test results ............................................................................................................................ 22
4.3 Conclusions ........................................................................................................................... 23
2
INTRODUCTION
The European Organization for Nuclear Research (CERN) is the largest particle physics
laboratory in the world. The organization, established in 1954 and based in Geneva,
Switzerland, is the result of a cooperation of several states, both European and non-
European.
CERN provides particle accelerators and other infrastructure for high energy physics
research. Moreover also a strong industrial research is performed at CERN. Knowledge
transfer is a key factor of the organization and everyday many companies are involved in
a tight collaboration.
The largest facility at CERN is called the Large Hadron Collider (LHC), a 27 km circular
particle accelerator which runs 100 meters under the French and the Swiss countryside.
It is the longest and most powerful particle accelerator in the world. The LHC needs regular
maintenance and unfortunately its dimensions do not make the operations easy. Other
problems concern the presence of radiation and harmful gas, exposing the personal to
dangerous risks. Thus, an automatic inspection system was developed: the Train
Inspection Monorail (TIM).
TIM is a remotely-controlled monorail train placed on the ceiling of the LHC tunnel. It is
able to take several measurements with a mechanical arm and send them automatically
to a control station.
When people are operating in the tunnel, TIM can only perform a few measurements since
the mechanical arm cannot be deployed for security reason.
The purpose of the project is to allow TIM to operate in every circumstances, especially in
the case of emergency in the LHC tunnel. In doing so, TIM will allow a human-robot
cooperation and the train will be able to carry out all the measurements even in the
presence of people. Moreover, thanks to the work of this project, tasks like reconnaissance
in case of emergency could be performed.
The LHC tunnel is equipped with a remotely-controlled monorail train able to carry out
Radio-Protection (RP) survey and visual inspections. This train is composed of five wagons.
Among them the RP wagon has a retractable arm for RP measurements, which can be
deployed while the train is moving.
1.1 Description
A remote controlled inspection vehicle was developed at CERN for the LHC tunnel.
This equipment called TIM is able to perform radiation, temperature and oxygen
measurements, as well as visual inspections with HD and infrared cameras. It is
battery powered and additional payload can be added on demand.
Motor wagon
RP wagon
RP arm deployed
First four
wagons of TIM
The RP wagon is equipped with a retractable arm fitted with radiation sensors
mounted at its end. In normal traveling mode this arm is retracted in the wagon.
Whenever required the arm can be deployed to measure the radiation levels at
different heights near the equipment. The train can be moving along the LHC
tunnel during this operation (see Figure 2). In fully deployed configuration, the
arm can reach a maximum length of 1.7 m. The train being suspended at an
average height of 2.1m above the tunnels floor, the fully deployed arm can reach
down a minimum height of 40 cm above the floor. Therefore, there is the risk that
it could collide with objects that could be left in the tunnel (bike cycle, ladder,
Alarm Threshold
Safe detection
distance
Deployed
RP arm
Floor
2.1 Description
The TeraRanger one sensor (Figure 4) is produced by Terabee Company. It is
based on the Time-of-Flight (ToF) principle where the device measures the time
between the emission of the signal and its return home after being reflected by
an object. It uses infrared light and the TeraRanger can provide a reading speed
up to 1 kHz.
3.1 Arrangement
As a first approach the sensors were mounted inside the RP wagon at the bottom
and facing the floor in order to detect objects below the wagon.
= . tan
With H = 200cm (the distance between the sensor and the maximum
measurement distance) and = 2 (FOV angle divided by 2).
H = 200cm
The detection surface can be deduced from the previous equation as being
14x14cm. At a 2m distance from the train, the 30cm-wide wagon can almost be
covered by 2 TR1 (see Figure 6). The advantage of the solution is that it reduces
the number of sensors required. It also avoids potential cross-talk between the
sensors, thus ensuring no interaction between them. However, blind areas remain
if the sensors are positioned as suggested in Figure 6. Consequently,
objects can potentially enter the safety volume without being detected and hit the
RP arm.
30cm
Blind area
Minimum full
200cm detection
distance
Threshold
detection
distance
28cm
30cm
200cm
Safety Minimum full
detection
volume
distance
Safety volume Safety volume
Threshold
detection
distance
28cm
Positioning the sensors closer one to the other allows adjusting the height of the
safety volume. The closer they are, the higher the volume will be. This also means
than their Field of View overlaps and it may cause cross-talk between the sensors.
According to the datasheet, the TR1 do not suffer from this effect.
Traveling direction
Deployed Threshold
RP arm detection
distance
Floor
1. Specifications
TeraHub has the following specifications:
Up to 8 multiplexed TR1
OSD functionality
Interface1: USB
Interface3: CAN
TIM controller
Up to 8 Up to 8
TeraHub TeraHub TR1
TR1
TR1 TR1
One issue to address is the positioning of the redundant sensors. Due to their
size, two sensors cannot monitor exactly the same volume. Consequently, the
sensors may not trigger at the same time, or only one may trigger because the
second sensor does not see the obstacle at all. In this case the redundancy is not
efficient.
An online test was performed while the component was powered. This consisted
of applying a positive voltage on port A and checking that it is correctly shifted on
1. Apply all 1 on the IOs to verify that the voltage is correctly shifted
Each TeraHub board was tested to ensure the correct soldering of the voltage
shifters.
The main task of the firmware is to read all the distance sensors and compare their values
to a fixed threshold. Therefore, TeraHub has to notify an alarm signal in the case one
sensor returns a value under the threshold, meaning that an object was found inside the
security volume.
As default, there are eight TR1 sensors connected to TeraHub. In the present project the
TIM controller is composed of PLC modules and TeraHub has to interface with them only
through digital IOs. Further explanations are in the next chapter.
1. Specifications
Distance check
End
Alarm? Yes
Call wait
For n = 1 to 8
Distance check
Alarm? Yes
Call wait
Update system
paramaters
The core part of the firmware is directly implemented in the main function, where
an endless loop reads continuously the distance values from the sensors. As the
program starts, an initialization phase takes place where all the TR1 sensors are
tested and set in the default operating mode. In this phase the default settings
are defined by firmware and the users are not allowed to change them. A second
After the initialization, the system puts itself in a pending state, waiting for a start
signal from the upper system. The signal can be either a digital input or specific
message on the serial connection, depending on the version.
In the case of an object being found under the given threshold or a critical error
occurs, the system stops itself again, waiting to be re-armed from the upper level.
3. Firmware versions
Several versions of the firmware were developed.
3.1 Version 1
The first version is the software framework of the firmware. In this version the
standard library for the communication TeraHub TeraRanger was developed, as
well as the main structure of the firmware. The following versions add or remove
features but dont change this main skeleton. In this version, a simple serial
interface (UART) to send and to receive basic data from TeraHub was developed,
just as a test.
To interact with TeraHub a full GUI piece of software for Windows was developed
as well (further information in the next chapter).
4.1 Description
To test TeraHub a special carriage was used. The sensors were fixed over the
carriage, all aiming at a fixed target. The carriage, moving back and forth,
simulated the presence of objects at different distances. The goal of the test was
to ensure a response from TeraHub when it moved beyond the distance threshold.
In order to the test the reliability hundreds of cycles were made.
Since the TR1 sensors require an optimal calibration we also checked their
reported distances.
450000
400000
350000
300000
250000
Measured threshold
200000
Real Threshold
150000
100000
50000
0
507
645
783
921
139
185
231
277
323
369
415
461
553
599
691
737
829
875
967
1
47
93
4.3 Conclusions
The program never failed in the obstacle detection. However the sensors needed
a better calibration, since the measured values detached from the real ones. In
the end the problem was solved with a software adjustment.
1. PC interface
1.1 Description
This interface was thought mainly to test the functionalities of TeraHub. It
provides data communication with the board, allowing the user run- time control
of the system.
Figure 17 - PC adapter
The board shown above, designed at CERN and provided by an external company,
converts UART signals in RS232 signals (and vice-versa) through the MAX3232
chip. It can work with a supply voltage of maximum 24 V.
Two working modes are available: automatic and manual. In the first mode all the
sensors are read automatically and when an event occurs (such as an alarm or a
warning), the program automatically displays a message. It is also possible to
modify the distance and the frequency thresholds run-time. The second mode can
be used for testing the sensors; TeraHub is stopped and the user can either read
each single TeraHub, or retrieve the measured distance or get general
information.
When an alarm occurs, TeraHub stops reading the sensors, awaiting an action
from the user. To restart TeraHub again it is necessary to click the resume button;
it is also possible to read every single sensor and to disable some TeraHubs.
A found object is not the only event that can trigger an alarm. Different system
errors may occur in TeraHub and the program can supply details about their
origin.
Too many error events occurred (for example a TR1 is not working
correctly or several communication errors occurred between TeraHub and
the sensors).
When TeraHub fails in keeping the number of reading cycles over the threshold,
an alarm is triggered. A reading cycle is performed when TeraHub reads all the
distance sensors in sequence, the reading frequency is the number of reading
cycles performed in one second. This threshold can be adjusted by modifying the
Min frequency threshold textbox.
4.6 Description
The PLC interface is, basically, the simplified version of the PC interface. In this
version no serial communication is available; the communication is performed
only through the digital IOs of the board. It is neither possible to modify any
parameter of the board nor possible to receive data from it.
As in the previous interface, the board was designed at CERN. The board performs
two operations at the same time: with 2 relays it steps up the voltage of TeraHub
from 3.3 V to 24 V and with 2 voltage dividers it steps down the voltage of the
PLC from 24 V to 3.3 V.
One Restart input: when a pulse is sent through this input, TeraHub is
restarted. This input is used to restart TeraHub in case an object was
detected.
Unlike the PC version, it is not possible to change the distance and the frequency
thresholds run-time. It is therefore necessary to reflash the firmware to perform
setting modifications.
3. TIM interface
4.9 Description
The TIM controller is composed of Siemens PCL modules. Therefore the interface
implemented is the one used for the PLCs. The train is controlled through a
software interface developed in LabView.
TeraHub
control
The monitor of the input/output of TeraHub is placed into the program. Some
dedicated buttons perform actions directly on the input of TeraHub while the two
outputs are ANDED to be displayed as a light.
TeraHub will be installed in the next maintenance stop, planned for December 2015. A
single TeraHub board with a strip of eight TR1 sensors will be placed in front of the RP
wagon, connected to the PLC controller.
In a future application additional tools will be installed on TIM, therefore several TeraHub
will be placed to create a larger and a user defined safety volume. The boards will be
connected together in a CAN-bus3 network, therefore data communication will be possible
between the PLC controller and the boards.
A further application is to use the TR1 sensors not only to create the safety volume around
the wagons, but also to take distance measurements.
3
Controller Area Network bus, a communication protocol.