RobotOS, the ZED-camera, and the Jetson

Hi all,

We are currently working on a project where we are trying to build an autonomous robot - or rather, create additional features for an already existing robot.

The aim is to implement autonomous driving using either the ZED-camera or a posititioning sytem (or a combination of both), as well as making the robot wave to people it encounters using facial recognition. The robot already has code allowing it to detect faces, although it was implemented using a Kinect instead.

However, we have encountered tons of problems with our ZED. Basically, since the robot already has a bunch of features it doesn’t have that much space left on the primary memory, so we bought an SSD for extra storage. For the facial recognition we need to use OpenCV, which already was installed. But the ZED camera needs OpenCV with OpenGL (ie. compile from source). Since compiling from source takes a lot more space than the precompiled version, we thought we’d install it on the SSD. But it seems like the Jetson, the ZED, or a combination of them doesn’t really support this as we constantly get “Couldn’t find OpenCV” and other assorted errors when we try to run the demo on the ZED homepage.

Has anyone encountered a similar problem to ours? Would it be better if we make the SSD the boot drive and just reinstall everything?

Thanks!

You could test a different rootfs without flashing. During boot “/boot/extlinux/extlinux.conf” is used as a U-Boot configuration up until hand off to the Linux kernel. The APPEND key/value pair in a default install has “root=/dev/mmcblk0p1” to name mounting eMMC as the root partition. You could add a second entry which is an edit of the primary entry, but have “root=/dev/sda1” to name the SATA drive as the root partition.

You need a serial console set up to pick alternative boot entries. Without that if something went wrong you might need flash to fix it. Serial console info can be found here:
http://elinux.org/Jetson/TX1_Serial_Console

There are a number of ways to put a working rootfs on the SATA drive. One example assuming running from a host and using “/dev/sdb” (a second drive slot) as the example drive name on the host:

<b>sudo -s</b>
# ...partition /dev/sdb, e.g., with gdisk or gparted...first partition is the new rootfs.
mkfs.ext4 /dev/sdb1
mount /dev/sdb1 /mnt
cd /mnt
tar xjvf /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2
cd /where/ever/driver/package/is/Linux_for_Tegra
./apply_binaries.sh -r /mnt
# shutdown and remove the SATA drive, put it on the Jetson.

Supposing your alternate entry on extlinux.conf is given LABEL “testing” (to differentiate from “primary”) and MENU LABEL is also called “testing” (serial console prints MENU LABEL value), then you can use serial console to interrupt U-Boot when it shows the boot labels by hitting any key, backspacing to remove the key you interrupted with, and picking the entry number. With those two entries it will look like this:

1. primary
2. testing

…you’d hit the “2” key and it’d boot to SATA.

Note that you can also clone the root partition and use this via dd or rsync onto a SATA drive partitioned similar to the one illustrated above from scratch. To clone a loopback mountable exact image of the existing rootfs see:
https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149

Understand that the “/boot/extlinux/extlinux.conf” is used for boot configuration from a normally flashed Jetson’s eMMC. What the “root=” kernel parameter points to is the partition used after boot, and the “/boot” partition of that “after boot” does not care about extlinux.conf because that stage is done. If the root= mounts the SATA drive then the “/boot” you see on the running system is from SATA and that “/boot” is ignored…the eMMC “/boot” is still the version of “/boot” U-Boot cares about.

Hi. I also use ZED on TX1. For extension of the available place I use a SD card on 64 Gb. I copied the project from memory of MMC using the article http://www.jetsonhacks.com/2017/01/26/run-jetson-tx1-sd-card/. SD works a little more slowly, than MMC, but quickly enough for my project.