ModalAI Forum

Alex Kushleyev

The ipk is available here now : http://voxl-packages.modalai.com/stable/voxl-hal3-tof-cam-ros_0.0.5.ipk - you should be able to use the launch file to choose between two modes (5=short range and 9=long range) and fps, which are listed in the launch file.

Alex Kushleyev

Hi

If you are looking for more low level functionality and a bit easier to experiment with, you may want to check out https://gitlab.com/voxl-public/utilities/voxl-rtsp/-/tree/dev . This tool is good for testing or running simple scenarios. This tool accepts some commands (like exposure control) via command line, so you could add a simple feature to save an image upon a command line input. Please see README to see how the exposure control input works and code for how it's implemented.

Please make sure that voxl-camera-server is disabled when you run voxl-rtsp.

If you still would like to go through the voxl-camera-server approach, we may need some more input from respective devs :).

I hope this helps..

Alex

Alex Kushleyev

It looks like your machine does not have QEMU support or is missing ARM support on your host machine. Please try instructions here : https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/ (which also show you how to run ARM64 docker images on x86)

Alex Kushleyev

Hi Ryan,

Does the micrortps agent need to open a standard UART port, such as /dev/ttySx or /dev/ttyUSBx or similar? how hard is it to extend the micrortps client to use libvoxl_io functionality to access the serial port via libvoxl_io instead of standard serial port libraries? You would need to use this header https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/master/lib/include/voxl_io.h and link against libvoxl_io.

If changing micrortps code is not an option, then some sort of bridge could work. I have done similar things before using pseudo terminals (pty/tty pairs). Basically the bridge could be the master and would read/write using ptyXY and micrortps would be the client and read/write using ttyXY. However, i don't think pseudo terminals are available on VOXL.

https://stackoverflow.com/questions/52187/virtual-serial-port-for-linux this discusses the pseudo terminal as well another solution using socat. Now, socat is not available on VOXL either, but if you use docker, it can be installed in a small container using apt-get install socat.

Let me check if we can easily add the socat and pseudo terminals to the VOXL system image..

It seems perhaps the most robust solution (for now) would be extending micrortps to work with libvolx_io serial ports..

Alex

Alex Kushleyev

.. or if you wanted to continue using voxl-camera-server for 4K, just modify the server to save yuv frames on-demand and convert to jpeg later, as we discussed above..

Alex Kushleyev

I am not sure how to resolve the authentication issue, but you can always use docker save myimage:latest | gzip > myimage_latest.tar.gz to a tar file, then docker load on another machine and push to docker hub.

Also, by the way, you can build your docker image for VOXL on a regular linux machine. Qemu allows you to emulate arm and arm64 architectures and Docker supports this. This is how the voxl-emulator runs on x86-64: So, basically you can build your docker image on a x86-64 host and then push it to docker hub or copy directly to VOXL.

I know that does not answer your question, but hopefully there is a workaround here..

Alex

Alex Kushleyev

I double checked with other devs on the team and the jpeg snapshot feature in voxl-camera-server is still in development. I don't have a good ETA for the feature.

However, perhaps we can go back to evaluating voxl-rtsp for your application. If you disable hires camera in voxl-camera-server, you should be able to use voxl-rtsp with hires camera after voxl-camera-server has started for other cameras.

voxl-rtsp supports outputting jpegs. You can first confirm that you can access hires camera jpegs with voxl-rtsp (I don't think it can do 4K30 jpegs, but lower resolution/frame rate should work). That should work and then you could add an input to trigger voxl-rtsp to actually save a jpeg upon request (instead of every frame). This can be done similarly how exposure/gain commands are accepted by voxl-rtsp via a named pipe.

Hopefully this can work for you..

Alex Kushleyev

You can try docker save myimage:latest | gzip > <path_to_sd_card>/myimage_latest.tar.gz . <path_to_sd_card> should be /mnt/sdcard.

Note that SD card will be quite a bit slower than built-in EMMC, you might want to do some testing to find a fast and reliable SD card.

From personal experience the following SD cards have worked well and fast:

Lexar Professional 1066x
Kingston 64GB microSDXC Canvas Go Plus

However there are plenty of SD cards to choose from, you may want to run some SD card tests before you use it for something important. There are some fake SD cards out there which result in corrupt data.

Also, if you wanted Docker to use SD card for storing all images, check this article : https://docs.modalai.com/docker-on-voxl/#move-docker-image-from-data-to-mntsdcard

Alex Kushleyev

Hello Matthew,

When you execute voxl-gpio write, it configures the desired pin to OUTPUT mode and sets the desired state (0=low or 1=high). When you execute voxl-gpio read, the pin is configured as INPUT with a pull-up, so any previous pin state is no longer applicable. If nothing is connected to the pin while it is configured as INPUT, it will read 1 due to the pull-up.

If you would like to test the pin read and write functionality, you could set up a loop back connection, where you connect two pins together and you write one pin and read another.

I hope this helps

Alex

Alex Kushleyev

Hello,

There were a few issues with the uart loopback example:

the test buffer size was not handled properly (if test size is larger than HelloWorld strin
the sleep time was not enough to allow the transfer to happen (the write function is non-blocking, it seems)

I have made some fixes here:
https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/dev/lib/apps/voxl-uart-loopback.c

Now the behavior is as shown below.. please try it.

./voxl-uart-loopback -d 7 -b 9600 -s 20
INITIALIZING
Sending 20 bytes:
0123456789:;<=>?@ABC
Transfer should take ~20833us, sleeping for 25833us (+5000us overhead)
Reading back data...
Received 20 bytes:
0123456789:;<=>?@ABC
closing uart bus
PASS

./voxl-uart-loopback -d 7 -b 9600 -s 500
INITIALIZING
Sending 500 bytes:
0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJ
Transfer should take ~520833us, sleeping for 525833us (+5000us overhead)
Reading back data...
Received 500 bytes:
0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJ
closing uart bus
PASS

Alex Kushleyev

Hello Matthew,

When you execute voxl-gpio write, it configures the desired pin to OUTPUT mode and sets the desired state (0=low or 1=high). When you execute voxl-gpio read, the pin is configured as INPUT with a pull-up, so any previous pin state is no longer applicable. If nothing is connected to the pin while it is configured as INPUT, it will read 1 due to the pull-up.

If you would like to test the pin read and write functionality, you could set up a loop back connection, where you connect two pins together and you write one pin and read another.

I hope this helps

Alex

Alex Kushleyev

Hello,

There were a few issues with the uart loopback example:

the test buffer size was not handled properly (if test size is larger than HelloWorld strin
the sleep time was not enough to allow the transfer to happen (the write function is non-blocking, it seems)

I have made some fixes here:
https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/dev/lib/apps/voxl-uart-loopback.c

Now the behavior is as shown below.. please try it.

./voxl-uart-loopback -d 7 -b 9600 -s 20
INITIALIZING
Sending 20 bytes:
0123456789:;<=>?@ABC
Transfer should take ~20833us, sleeping for 25833us (+5000us overhead)
Reading back data...
Received 20 bytes:
0123456789:;<=>?@ABC
closing uart bus
PASS

./voxl-uart-loopback -d 7 -b 9600 -s 500
INITIALIZING
Sending 500 bytes:
0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJ
Transfer should take ~520833us, sleeping for 525833us (+5000us overhead)
Reading back data...
Received 500 bytes:
0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJ
closing uart bus
PASS

Alex Kushleyev

systemd is available on VOXL, so you could go ahead and try using the service file and script you wrote. Did you try it? However, you need to make sure that the Docker service is running, so your service file should require the Docker service also running. Docker is started by systemd as well.

Alex Kushleyev

It looks like your machine does not have QEMU support or is missing ARM support on your host machine. Please try instructions here : https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/ (which also show you how to run ARM64 docker images on x86)

Alex Kushleyev

Actually, I don't think it's possible because two identical PMD sensors will have the same I2C ids and communication will interfere. All cameras, with the exception of right stereo (if stereo flex is used) are communicating on the same (primary) i2c bus. The right stereo camera uses the secondary i2c bus. If it were possible to change the I2C id of the PMD sensor, then it could work, but I am not sure if that's an option.

Alex Kushleyev

Oh, also, just to mention.. You should be able to run voxl-rtsp at the same time as the camera server, however:

disable voxl-camera-server from accessing the particular camera (4K in your case)
start voxl-rtsp after you start the camera server (if you start camera server after voxl-rtsp, it will disrupt voxl-rtsp session during initialization)

Should work, I believe..

Alex Kushleyev

If you would like to use voxl-camera-server, then voxl-streamer is the way to go https://docs.modalai.com/voxl-streamer/ . Please check it out and let us know if you have any questions. the combination of the camera server and voxl-streamer will generate an rtsp stream with h264 encoding. Also, you should be able to separate the h264 stream from rtsp encapsulation in voxl-streamer if you need to.

Alex

Alex Kushleyev

Hello Rolando,

It will not be possible to fully use four ov7251 cameras at the same time due to i2c address conflict. the downward camera can coexist with the stereo pair because

one of the stereo cameras is actually on a different i2c bus
ov7251 camera has two i2c addresses, so with some software configuration it works. However, having 3 ov7251 cameras on i2c bus cannot be done without a conflict.

In a condition of i2c conflict between cameras, what will happen is..

system will be able to detect each camera at boot time because probing happens while other cameras are powered off
you should be able to fully use the conflicting cameras one at a time (not concurrently)
if you use the conflicting cameras concurrently, commands sent to one camera will go out to both cameras, for example exposure and gain control. nothing will physically break, but this is currently not a supported use case.
there will also be a short glitch after you started the first conflicting camera and when you are starting the second conflicting camera, since the first one will also get re-initialized with the commands intended for the second camera

in your case, the ov7251 plugged into J2 was not detected because the camera configuration xml file is not configured to query this camera on J2 connector. If you wanted to enable it, you need to back up and edit the following file : /system/etc/camera/camera_config.xml and add an entry that looks like below (then reboot). The slave address 0xC0 is one of the two possible slave addresses for this camera. The other one is 0xE0 and is already used by the camera plugged into J4 (downward facing).

So are you using one of the stereo cameras + stereo flex + extension cable? if you are using the stereo flex with one camera, make sure to use the left port on the flex because the right port is connected to the secondary i2c bus, accessible only in stereo configuration. Also, multiple stereo pairs are not supported on VOXL and stereo can only be used in J3.

With the below config addition, you should be able to detect all 4 ov7251 cameras and successfully use the following configurations without confilicts:

J2 + J4 (hires slot + tracking slot)
J3 + J4 (stereo slot + tracking slot)
if you want to use J2 + J3 (hires + tracking slot), change the I2C id to 0xE0, but then it's the same thing as current stereo + tracking.

Now, in this configuration you should also be able to run all 4 cameras together but depending on the i2c ID of the camera in slot 0, it will conflict either with left stereo or tracking camera. I would not mess with stereo, so you could set i2c id of slot 0 to the same as in slot 2 (hires and tracking). then there is is still an issue of exposure/gain controls between the two cameras fighting with each other (both cameras will receive both exposure/gain updates).

In order to prevent two cameras from fighting exposure/gain settings the only way to do it is to prevent one of the camera drivers from sending out exposure/gain updates at all. Then both cameras will have the same exposure/gain computed based on one camera's image. This would require a little bit of work on the camera driver side but it's possible (though not supported now).

Anyway, this is just a long explanation of what you could try and what you will see.

<!-- ov7251 tracking camera in camera slot 0 -->
  <CameraModuleConfig>
    <CameraId>0</CameraId>
    <SensorName>ov7251</SensorName>
    <SensorSlaveAddress>0xC0</SensorSlaveAddress>
    <ChromatixName>ov7251_chromatix</ChromatixName>
    <ModesSupported>1</ModesSupported>
    <Position>FRONT</Position>
    <MountAngle>360</MountAngle>
    <CSIInfo>
      <CSIDCore>0</CSIDCore>
      <LaneMask>0x1F</LaneMask>
      <LaneAssign>0x4320</LaneAssign>
      <ComboMode>0</ComboMode>
    </CSIInfo>
    <LensInfo>
      <FocalLength>4.73</FocalLength>
      <FNumber>2.2</FNumber>
      <TotalFocusDistance>1.9</TotalFocusDistance>
      <HorizontalViewAngle>64.1</HorizontalViewAngle>
      <VerticalViewAngle>51.6</VerticalViewAngle>
      <MinFocusDistance>0.1</MinFocusDistance>
    </LensInfo>
  </CameraModuleConfig>

Alex Kushleyev

It looks like you are using a snav_params file which was used for a different (older) board with a different IMU (mpu9250). In your case, both IMUs are detected as newer icm20948 and you are trying to set accel/gyro low pass filter settings which are not supported by this IMU. You can choose the setting that is close to what you need from available options:

SNAV_IMU_MPU_DRIVER (/dev/spi-10): attempting to detect sensor (try #2)
SNAV_IMU_MPU_DRIVER (/dev/spi-10): initializing MPU6050/MPU6500/MPU9250/ICM20602/ICM20948 I2C/SPI driver
SNAV_IMU_MPU_DRIVER (/dev/spi-10): WHOAMI register 117 is 0x40
SNAV_IMU_MPU_DRIVER (/dev/spi-10): (expected 0x68->mpu6050, 0x70->mpu6500, 0x71->mpu9250, 0x12->icm20602, 0x47>icm42688)
SNAV_IMU_MPU_DRIVER (/dev/spi-10): mpu6050, mpu9250, icm20602 not detected.. trying icm20948
SNAV_IMU_MPU_DRIVER (/dev/spi-10): WHOAMI register is 0xEA (expected 0xEA for icm20948)
SNAV_IMU_MPU_DRIVER (/dev/spi-10): ICM20948 detected!
SNAV_IMU_MPU_DRIVER (/dev/spi-10): available accel hw lpf (hz) : 6,12,24,50,111,246,473,1209
SNAV_IMU_MPU_DRIVER (/dev/spi-10): available gyro  hw lpf (hz) : 6,12,24,51,120,152,197,361,12106
SNAV_IMU_MPU_DRIVER (/dev/spi-10): requested accel and gyro lpf = 184.000000 184.000000
SNAV_IMU_MPU_DRIVER (/dev/spi-10): requested unsupported accel hw lpf 184.000000
mpu_driver_core.cpp mpu_config_icm20948() failed, returned: -1

You could change your device_driver_params to something like this:

<device_drivers_params>
    <param name="imu0_hw_accel_lpf_hz"     value="50"/>
    <param name="imu0_hw_gyro_lpf_hz"      value="120"/>
    <param name="imu1_hw_accel_lpf_hz"     value="50"/>
    <param name="imu1_hw_gyro_lpf_hz"      value="120"/>
</device_drivers_params>

You probably don't want such high bandwidth as 184, as the data could be noisy, depending on the vibration characteristics of your drone.

Alex Kushleyev

Sounds good.. Just keep in mind that saving a 4K image to a text file will be much slower and will take more space than just saving the raw binary data to a file. Parsing a binary file should be as easy or easier than text.. It's up to you though

Alex Kushleyev

@Alex Kushleyev

Best posts made by Alex Kushleyev

Latest posts made by Alex Kushleyev