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.
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
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
.. 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..
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
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..
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:
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
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.
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)
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.
Oh, also, just to mention.. You should be able to run voxl-rtsp at the same time as the camera server, however:
Should work, I believe..
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
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
In a condition of i2c conflict between cameras, what will happen is..
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:
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>
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.
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 
I am sorry, I meant run snav_inspector -d to see the debug messages coming from SNAV. Apologies!
Alex
Hello Rui,
After installing SNAV IPK, did you do anything else with SNAV before running snav_calibration_manager?
Installing the ipk does not autostart SNAV, if I remember correctly. So you might be trying to run calibration manager without snav itself running. SNAV ipk install does put the service files for systemd into /etc/systemd/system (i think), but if you want snav to auto start, you need to run systemctl enable snav. However, enabling snav, does not start it right that moment (until during next boot). if you just want to start snav, use systemctl start snav or you can just run start snav.
Before starting snav, you need to make sure that snav_params.xml is in place in /usr/lib/rfsa/adsp/ - usually it is either a symlink to a standard configuration or a custom file.
Then to check if snav is running after starting, i strongly suggest running snav_calibration_manager -d to see what debugging / error messages it prints. If IMU static calibration needs to be performed (which is the case before first flight), you will see a message saying that, at which point you could run snav_calibration_manager -s
I also usually disable the snav vio app and drone controller (latter is pretty much obsolete) like so:
systemctl disable snav_dronecontroller
systemctl disable snav_vio_app
When I know snav itself is working fine, you can make sure VIO params are set correctly and then enable/run snav_vio_app as well. If you know that vio app params are already correct, then you don't need to disable it.