Lidar Mapping (PoC) »

Issue List

Last update: 2022-05-07

Table of Content

Overall progress

UB480 module is not stable
Jetson SPI port does not work properly
Jetson is halt during boot
Handle high speed data for GNGGA and OBSVMA at 20 Hz
Mapping timestamp is hard to match
IMU timestamp is wrong
IMU data for Accelerator and Gyroscope does not have same timestamp
Jetson NX board does not fit ROS system

1. UB480 module is not stable#

Problem

When powering UB480 board from Raspberry Pi 3.3 V pin, the board cannot work properly, it sometimes reboots unexpectedly.

Analysis

Measuring the voltage on 3.3 V pin shows that the voltage is dropped to 3.1 V, and the datasheet of Raspberry Pi shows that the maximum current on 3.3 V power rails is 800 mA, however UB480 needs up to 2 A at peak.

Solution

Use 5 V power line on Raspberry which is connected directly to the power adapter to provide a total current of 3 A. UB480 can work at max 5 V.

2. Jetson SPI port does not work properly#

Problem

RF24 can not send message even the same source code work normally in Raspberry Pi.

Analysis

Hook up a Logic Analyzer to SPI pin, it showed a byte was missed due to CSN pin was not pulled down!!!

Solution

Force change CSN pin on each byte in the SPI driver.

Refer to vuquangtrong/RF24/commit/0ce98c

utility/SPIDEV/spi.cpp

uint8_t SPI::transfer(uint8_t tx)
{
    struct spi_ioc_transfer tr;
    memset(&tr, 0, sizeof(tr));
    tr.tx_buf = (unsigned long) &tx;
    uint8_t rx;
    tr.rx_buf = (unsigned long) &rx;
    tr.len = sizeof(tx);
    tr.speed_hz = _spi_speed; //RF24_SPI_SPEED;
    tr.delay_usecs = 0;
    tr.bits_per_word = RF24_SPIDEV_BITS;
#ifdef JETSON_NANO_DEV_KIT
    tr.cs_change = 1;
#else
    tr.cs_change = 0;
#endif
    ...
}

3. Jetson is halt during boot#

Problem

System is halt when GNSS module is connected to Jetson board.

Analysis

Unplug RX pin of ttyS0 port, system can boot successfully. After checking, it turns out that the ttyS0 port of Jetson is configured as the System Console for U-Boot (bootloader), which looks for an input character to stop booting. GNSS module actually sends a message during it start up routine, causing U-Boot stop !!!

Solution

Disable system console in U-Boot

Follow the guide in Linux for Tegra - U-Boot Customization to download U-Boot source code.

Add a new line at the end of the file /config/p3450-0000_defconfig:
```
CONFIG_BOOTDELAY=-2
```
Recompile the U-Boot, then copy the new u-boot.bin to /bootloader/t210ref/p3450-0000.

Re-flash the LNX partition:
```
./flash -k LNX jetson-nano-devkit mmcblk0p1
```
Keep one boot entry only

In the file /boot/extlinux/exlinux.conf, if there are more than 1 active entry, U-Boot also pauses on any key in console to select a boot entry. Therefore, keep only one entry which has SPI-enabled DTB.

4. Handle high speed data for GNGGA and OBSVMA at 20 Hz#

Problem

When enable logging OBSVMA at 20 Hz, system can not handle data correctly, causing delay.

To-do

Check performance of system to handle multi-threads

5. Mapping timestamp is hard to match#

Problem

The mapping function still does not work correctly because many packages from Lidar/ GNSS/ and IMU do not have matching timestamp.

Analysis

Adding debug timestamp of IMU showing that DK-20789 board sends correct timestamp but Jetson board could not read at high speed leading to wrong timestamp in ROS message. Refer to below problem IMU timestamp is wrong.

Solution

Re-check the timestamp of all component: GNSS, IMU, and Lidar

6. IMU Timestamp is wrong#

Problem

The IMU output rate is set at 200 Hz (period is 5 ms). DK-20789 correctly sends out message:

But the reading rate is not correct: Sample are read at very fast speed (52 us) in a burst and then there is a big delay (80-100 ms) between bursts.

Analysis

The DFTI USB chip of DK-20789 has some delay on buffer, refer to Effect of USB buffer size and the Latency on Data Throughput.

Note from FTDI:

Therefore, if data is received at a rate of 3875 bytes per second (38.75 KBaud) or faster, then the data will be subject to delays based on the requested USB block length. If data is received at a slower rate, then there will be less than 62 bytes (64 including our 2 status bytes) available after 16 milliseconds. Therefore, a short packet will occur, thus terminating the USB request and passing the data back. At the limit condition of 38.75 KBaud it will take approximately 1.06 seconds between data buffers into the user’s application (assuming a 4 Kbyte USB block request buffer size).

To get around this you can either increase the latency timer or reduce the USB block request. Reducing the USB block request is the preferred method though a balance between the 2 may be sought for optimum system response.

Solution

Option 1: Change FTDI USB Buffer size

No document found yet!!!

Option 2: Re-assign timestamp in software

The mapping process need real-time data, therefore, delayed packages are invalid.

Option 3: Direct wire DK-20789 COM7 to Jetson Nano

Jetson only has 2 accessible physical UART ports (on J41 and J50). Consider to use USB for slower data input.

Connect IMU to UART on J41

7. IMU data for Accelerator and Gyroscope does not have same timestamp#

Problem

Accelerator and Gyroscope should be the same timestamp, but DK-20789 sends those data in 2 different packages.

Solution

Fuse Accelerator and Gyroscope data before sending to synchronize timestamp

8. Jetson NX board does not fit ROS system#

Problem

The Jetson NX board only has 16 GB eMMC, which is not enough to hold ROS system.

To-do

Rebuild Jetson OS to remove unnecessary packages
Flash to eMMC via Recovery Mode