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

At first, I would not try changing any code that runs on the DSP - just using the functions already exposed in voxl_io.h. So you would write an application that would get data from UDP and send to the serial port using voxl_uart_write. Then read any data using voxl_uart_read and send it out via UDP. Does that make sense?

Hi, you can use the following commands.

1. In first terminal, run voxl-rtsp which will connect to camera and create the fifo and wait for the client to open the fifo

voxl-rtsp -m /dev/my_fifo -f h264
voxl-rtsp version 1.0.4
Enabling output fifo /dev/my_fifo
Setting output format to: h264
Connected
Started camera 0
Created session
Video track created
Updated camera parameters
AE Mode: 1, Exposure: 0us, Gain: 0us, AWB Mode: 1
rtsp://<your_voxl_ip_address>:8900/live
Camera Output FIFO starting: /dev/my_fifo .. will block until client is ready
** process will proceed when you start reading the fifo **

2. then in second terminal (This opens the fifo and sends the raw data from the fifo into a file):

cat /dev/my_fifo > raw_video.h264

3. press control-c in 1st terminal to stop the process, the cat process will also exit since the fifo will be closed.

Note that using voxl-rtsp you can use -f to specify which format to use for data output, include h264 (Defualt), h265, or even yuv or raw formats.

You can also just dump the video to a file without fifo, using voxl-rtsp -o <filename>. From voxl-rtsp -h :

-o <filename> Save video to filename (No save to file by default). If extension of the file is .mp4, then video will be written in MP4 container, otherwise raw

So if you wanted to just use voxl-rtsp without a fifo to save raw yuv (no mp4 container) to file, then just use voxl-rtsp -f h264 (or h265) -o my_video.h264 (or .h265)

Did that answer your question?

@ryan_meagher , see responses..

• yes, that is an issue.. libvoxl_io library needs to run on the VOXL host operating system because it calls into some device-specific hardware libraries to talk to the DSP. Hmm. It does seem like some sort of a bridge is needed.. Since microRTPS supports UDP, perhaps the next thing to try is writing a simple app that uses libvoxl_io on the host OS and exposes the data via UDP (read/write)?

• I don't actually think this is a limitation (128 bytes), it just has not been tested. I am pretty sure you can send more than 128 bytes at a time and receive as well, as long as you allocate a big enough buffer for receiving (see https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/master/lib/apps/voxl-uart-loopback.c for allocation example)

hi @ryan_meagher , yes it looks like you need to implement a custom version of UART_node class, with init, read, write, and a few other functions, which can be just wrappers for libvoxl_io calls. I think this is the best solution in this case and hopefully does not take too much time. Some options are not available, like poll_ms, flow_control, but i think it should be just fine to not implement those.

Let me know if you have any particular questions regarding using uart with libvoxl_io or anything else.

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

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.

Hello Lynn,

The error with rc: -2 happens at the very beginning until there are frames available for publishing (slight delay between the start of application and when camera frames start coming in).

Since there was no other error after that, it seems the camera ros node should be working fine after the initial warnings. Can you please try to view the images or even simpler : rostopic echo /stereo/left/image_raw/header

Hi Bobby,

I did some more testing and it seems i can get the IMX377 camera to produce green-ish shades under some lighting conditions. I believe that this is due to AWB somehow incorrectly detecting the scene / lighting type. Let me play with this, I think the solution can be to force a particular scene type so that AWB does not try to guess.

In my tests, I pointed the camera at a light gray wall and depending on the angle, it would show up as gray or sometimes a bit green-ish.

I will follow up soon..

Alex

Is the filter inside the lens holder or in the lens itself? I think different lenses might be tested here.

Nice, some progress..

I do see the colors being off in the image. The indoor image (IMX377) with the color wheel looks too "warm".

Did you try using voxl-rtsp to record the video? please try, just to double check that you get the same results. Since you are using a ros node, which converts from YUV format to RGB (before encoding as a video), it is possible that the format conversion is not accurate. voxl-rtsp will record the video natively using the built-in hardware video encoder.

Also, just to double check, are you using a lens with IR cut filter? If there is no IR cut filter, the image sensor can get saturated with ambient IR light across all colors (not necessarily equally).