Designing the data collector

To store the collected data without hickups, a small systems needs to be designed.

Both the Structure Core and Intel RealSense D435i will be attached to a robotic arm, the Hogeschool van Amsterdam’s ABB IRB 4600-60/2.05. Using my own laptop to stay within cable range of the sensors will not be sufficient, as the sensors will move fast (to see the influence of inertia), and over a rather long distance (the arm is 2.05 m long from the base to its end effector). The sensors do not support a bus type that is wired through the arm itself. That means that a system for data collection needs to be attached to the arm itself.

First I will make a rough estimate of the data collected per time unit from the sensors. Then I will list the technical requirements of a data collection system.

Raw data per second

Structure is more transparant on their website about the generated data per second than Intel. The Core caputes depth images with a resolution of 1280×800 px @ 60 Hz. Assuming each pixel is stored as a single byte, that means \(1280 \cdot 800 \cdot 60 = 61 440~kB/s\). The RGB camera captures images with a resolution 640×480 px at a maximum of 100 Hz. However, RGB and D cameras will be synchronized, so it sill be \(640 \cdot 480 \cdot 60 = 55 296~kB/s\). The IMU generates 6 doubles (sizeof(double) == 8) with max. 1000 Hz, so that is \(6 \cdot 8 \cdot 1000 = 48~kB/s\). Summed, the data collector would need to be able to record \(116.784~MB/s\), not accounting for any metadata such as timestamps.

The RealSense D435i could generate depth images of 1280×720 px @ 90 Hz ( \(82 944~kB/s\) ) and color images of 1920×1080 @ 30 Hz ( \(186 624~kB/s\) ). They give no indication on the IMU used, so I will, for this handwavy guesstimate of needed bandwith, the same value as for the Core ( \(48~kB/s\) ). That is a significant \(269.616~MB/s\) at most.

Metadata per frame

Metadata I am interested in, consists of the (double) timestamp ( \(8~B/frame\) ) and the type of the frame (one of four options). The frame type will most easily be stored as a char of 1 byte. That leaves us with \(9~B/frame\). In above examples, this would be \(9 \cdot (60 + 60 + 1000 + 1000) = 19.08~kB/s\) for the Core and \(9 \cdot (90 + 30 + 1000 + 1000) = 19.08~kB/s\) for the D435i. This increases their total data writing requirements to \(116.803~MB/s\) and \(269.635~MB/s\), respectively.

Technical specifications

Requirements for the data collector are as follows:

1. The system must be small and light. The system needs to be mounted on the arm, near the end effector. In that region is not much space to securely mount a larger, heavier system. Most probably this would mean a singl-board computer (SBC).
2. The system must have GPIO pins. This is to make sure it can have any external synchronization triggers that I might want to add later.
3. The system must have at least 1, and desirably 2 USB 3.0 or higher connectors. Each connector must be on a separate bus. The two buses is to exclude any possible bus overload because of the amount of data sent by both sensors.
4. The system must have a separate storage medium from its boot medium. This will ensure that the required data write speeds will be attained, and independently read or write to the storage medium.
5. The storage medium must be an SSD. Most SBCs only have connectors for SD or eMMC media. When SD is supported, it is often unclear if UHS-II (≤ 312 MB/s) or higher is supported. UHS-I (≤ 104 MB/s) is too slow. In ODROID’s speed comparison for the ODROID-XU4 of SD vs. eMMC writing and reading speeds, their eMMC v5.0 memory’s \(39.3~MB/s\) write speed is still much too slow. On the other hand, Samsung’s 970 EVO and 970 EVO Plus line SSDs seem fast enough in a speed test by Tweakers.net, even for 2 sensor data streams.

I have looked at several systems:

Only 3 considered systems fulfill all requirements. To make a further decision, I will make a parts list for the Pine64 RockPro64, UDOO X86 Ultra, UDOO X86 Advanced Plus, and Vamrs Rock960.

All these prices exclude an SSD, such as the Samsung 970 Evo Plus 250GB for €84.95 including shipping.

Pine RockPro64

Total: $176.89

UDOO X86

At the time, only the Advanced Plus is in stock. It is not indicated when the Ultra will be back in stock.

Total: $261.93

Vamrs Rock960

Total: $222.89, excluding power supply (12V @ 2A, approx. €15 to €30)

Preferred solution

My preferences goes out to the UDOO, as that board has an x86 architecture, which makes it easier to find compatible and pre-compiled packages, when compared with the other two ARMs.

The UDOO has 3 USB 3.0 connectors, but it is unclear how the host layout is organized. If this will be the ordered product, I will contact the developers for this information.

As a second option, I would go for the RockPro64. The device has some years of LTS to go (2023), and seems better documented than the Rock960. In this case, I might consider two collector systems, so that the sensors can collect data from the same run.