-
Notifications
You must be signed in to change notification settings - Fork 2
Robotic Total Stations (RTS)
In mobile robotics, it may be important to have reference data in order to compare and validate the results obtained by an algorithm. This comparison is important for assessing the location of a mobile platform. Indeed, sensors such as Global Position System (GPS) have an inaccuracy which can be several meters and cannot be a reliable source to accurately evaluate a location algorithm. Algorithms such as Iterative Closest Point (ICP) are more accurate, but have long-term biases which distort location.
To overcome this problem of inaccuracy measurements, some trades such topographers or surveyors use devices called theodolite. A theodolite is a geodetic instrument supplemented by an optical instrument, which makes it possible to measure angles in both horizontal and vertical planes in order to determine a direction. These devices can also measure the distance of a target from them. Their angular accuracy is less than one thousandth of a degree, and the accuracy of the distance measurement is of the order of a millimeter.
As a result, it is possible to obtain a very accurate survey of any target objects. By placing different targets on a mobile robot, we could then get its full reference pose. These baseline data can then be used to assess ICP accuracy and quantify its bias over time.
The theodolite we use is a Trimble Total Station S7.
A digital tablet is attached to the theodolite. This tablet has a windows OS with Trimble Access software that allows communicating commands to the theodolite. The theodolite can take into account different means of communication: Bluetooth, Radio and USB. Bluetooth mode can be direct (computer to theodolite via Trimble Access). This Bluetooth mode can also be used for indirect communicationto the theodolite. In this case, a Trimble TDL 2.4 relay should be used to link the computer to the theodolite. The computer must connect to this relay via Bluetooth, and via the Trimble Access application. Afterwards, the relay will communicate by radio with the theodolite, which allows to control it remotely (up to about 600 meters). The last mode of communication is via USB. This is the one we will use mainly afterwards.
In order to perform measurements, the theodolite needs a target. These targets can be of different types. The most common is the reflective foil target.
These targets are provided with the theodolite and can be placed on any object. However the theodolite can only measure one target at a time. Theodolite makes no distinction between these different reflective targets. Thus, if it detects a new target near another target, it can change the target to be measured automatically. The performance is lower with this type of target (reduced distance and precision). This is why we prefer to use them to calibrate theodolite over short distances, rather than to use them for distant measurements.
The target that we will most often used to track our robotic platform is a 360° prism.
This prism has many assets. First, it is possible to ask a theodolite to lock onto it. Theodolite will not change target during measurement. The prism contains a unique digital signature that guarantees this lock. This makes it possible to place several prisms on the same robotic platform while guaranteeing the correct measurement. In addition, the performance of the measurements is increased. It is possible to follow the prism over longer distances with increased precision. Finally, it can be fixed securely to a platform via a screw. The prism works with a battery that activates its electronic signature. It is possible to set the number of this signature (ranging from 1 to 8) to differentiate it from other prisms. This target is quite heavy and expensive. When used, it should be taken care of and used safely to avoid damage. A paper leaflet is provided with the equipment, illustrating its use and the precautions to be taken.
Communication of data to a robotic platform becomes difficult with the equipment supplied with the theodolite. The USB or Bluetooth is not suitable, while the relay is only usable under the Trimble Access application that works on Windows exclusively. We decided to use another communication module to solve this problem. It is a Lora antenna communication module on a printed circuit board that can be configured to transmit data over long ranges. This module will be installed on a Raspeberry Pi 3B+ board, which will receive the theodolite data via USB. The robotic platform will also be equipped with a Raspberry Pi 3B+ and a Lora module to communicate with the theodolite, which will allow us to save the data at distance.
The computer currently used to interface with the theodolite is a Raspberry Pi 3 model B+ running Ubuntu Mate 18.04.2. Using another computer and operating system should theoretically work, as long as the OS is a Linux distribution and as long as the computer has a 32-bit ARM based processor. The only computers that have been tested are Raspberry Pi 3 model B/B+ and the only OS’s that have been tested are Ubuntu Mate 18.04.2 and Raspbian 9.11 Stretch.
The credentials for logging in the computer are the following:
• User: pi • Password: you know what
The configuration of the theodolite can be done in two different ways. The easiest and fastest to implement is using the Trimble Access application. This application is only available on Windows, but allows using all the functionalities of the theodolite quite quickly. The second way is to use C++ code libraries that allow communicating with the theodolite. These libraries can be used under Linux, but do not contain all the possible features under Trimble Access.
The company Cansel has provided us a pre-completed libraries of C++ code to use some of the theodolite features on Linux. This repository is built upon a project that was intended to be used as a Telnet server for interfacing with a Trimble TotalStation robotic theodolite. Its main program was modified heavily by removing the telnet server functionality and replacing it with a sequence of simple commands that are sent to the theodolite. This was done in order to test and explore what type of interfacing could be done with the theodolites we have at the lab, which are 3 Trimble TotalStation S7. In other words, the main program now consists of a small sequence of commands that are sent to the theodolite before terminating.
In the theodolite node ROS package, these libraries are in the lib directory. The .h header files that use its libraries are in the include directory. To use these precompiled libraries, .cpp and .h files were created in the src directory. These files are from an SDK provided by Trimble. We will detail this in future subsections. The functions defined in these files will be explained, mainly those we used to obtain the data of the theodolite. The two main classes that we will use are Observationlistener and Ssiinstrument, present in the src directory.
The Trimble TotalStation SSeries supports many types of communication channels, such as Bluetooth, radio, serial, USB, WiFi, etc. However, we were not able to connect the Raspberry Pi to the TotalStation S7 via Bluetooth or WiFi. The lab has in its possession three Trimble TDL2.4 data link radios, which connect to a computer via Bluetooth and connect to a theodolite via 2.4 GHz radio channel. They could prove useful for long-distance communication between the Raspberry Pi and the theodolite, but we have not been able yet to connect them to a Raspberry Pi and use them. They currently only work with the tablet controller of the theodolite.
This repo currently only supports communication between the Raspberry Pi and the theodolite via a USB and TCP connection. The theodolite shows up in Linux as a USB device with idProduct: 0101, idVendor: 099e and Trimble as manufacturers. A udev rule was created in Ubuntu Mate in order to give users access to the theodolite USB connection. Any user in the group users can run the program and communicate with the device. The TCP connection that was already implemented has not been used or tested. Since the SDK was made to be used on Windows, the default classes for instantiating a communication channel with the theodolite don’t work on Linux. The SDK supports custom communication type, as long as you define a custom communication class which inherits from ICommunicator and implements the methods defined in the ICommunicator interface. The classes USBCommunicator and TCPCommunicator are two implementations of this interface. They are used in the SsiInstrument class in the Connect method.
Those explanation were written by Maxime Vaidis on the 10th of June 2020, for more details on the ROS node functionalities check the pdf version.
- Warthog Teach and Repeat (ROS1)
- Warthog Teach and Repeat (ROS2)
- Time Synchronization
- Deployment of Robotic Total Stations (RTS)
- Deployment of the backpack GPS
- Warthog Emlid GPS
- Atlans-C INS
- How to use a CB Radio when going in the forest
- IP forwarding
- Emlid Data Postprocessing (PPK)
- Lessons Learned
- Robots' 3D Models
- Order Management
- Fast track Master → PhD
- Intellectual Property
- Repository Guidelines
- TF Cheatsheet
- Montmorency Forest Wintertime Dataset
- RTS-GT Dataset 2023
- Deschenes2021 Dataset
- TIGS Dataset
- DRIVE Datasets
- BorealHDR
- TimberSeg 1.0
- DARPA Subterranean Challenge - Urban Dataset
- How to upload a dataset to VALERIA
- ROS1 Bridge
- Migrating a repository to ROS2 (Humble)
- ROS2 and rosbags
- MCAP rosbags
- DDS Configuration (work in progress)
- Using a USB Microphone with ROS2
- ROS2 in VSCode
- ROS2 Troubleshooting