Skip to content

Lidar Mapping (PoC) »

Issue List

Last update: 2022-05-07

  • 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#


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


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.


  • 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#


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

NRF24 TX failed


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

NRF24 did miss one byte


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

    Refer to vuquangtrong/RF24/commit/0ce98c

    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) ℞
        tr.len = sizeof(tx);
        tr.speed_hz = _spi_speed; //RF24_SPI_SPEED;
        tr.delay_usecs = 0;
        tr.bits_per_word = RF24_SPIDEV_BITS;
        tr.cs_change = 1;
        tr.cs_change = 0;

NRF24 can read properly

3. Jetson is halt during boot#


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


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 !!!


  1. 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:


    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
  2. 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#


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


  • Check performance of system to handle multi-threads

5. Mapping timestamp is hard to match#


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


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.


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

6. IMU Timestamp is wrong#


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

IMU output rate 200 Hz

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.

IMU input rate is unstable


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.


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#


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


  • Fuse Accelerator and Gyroscope data before sending to synchronize timestamp

8. Jetson NX board does not fit ROS system#


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


Back to top