@SKA ,

Does this happen right away after you start voxl-camera-server ?

What raw "preview" resolution / fps are you requesting in camera server config?

Also, can you post output of dmesg (everything after you start voxl-camera-server)

Alex

@SKA , that result / buffer error (i think) is showing up because the camera pipeline selects incorrect camera mode / resolution, perhaps you missed one of the steps in EIS instructions, either using the correct camera drivers or updating the override txt file.

Also, the latest docs for EIS are here, the old .md file is probably outdated : https://docs.modalai.com/camera-video/electronic-image-stabilization/

Alex

Hi @Rowan-Dempster ,

Please take a look at this example (you can build and run it too) : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/add-new-image-tools/tools/voxl-image-repub.cpp

This app can accept a regular image (RAW8 or YUV) and either re-publish it unchanged or crop and publish the result. Sometimes this is useful for quickly cropping an image that is fed into a different application that expects a smaller image or different aspect ratio.

The app shows how to subscribe and handle ion buffer streams.

Usage:

voxl2:/$ voxl-image-repub                          
ERROR: Pipe name not specified

    
    Re-publish cropped camera frames (RAW8 or YUV)
    
    Options are:
    -x, --crop-offset-x    crop offset in horizontal dimension
    -y, --crop-offset-y    crop offset in vertical dimension
    -w, --crop-size-x      crop size in horizontal dimension (width)
    -h, --crop-size-y      crop size in vertical dimension (height)
    -o, --output-name      output pipe name
    -u, --usage            print this help message
    
    The cropped image will be centered if the crop offsets are not provided. 
    
    typical usage:
    /# voxl-image-repub tracking --crop-size-x 256 --crop-size-y 256
    /# voxl-image-repub tracking --crop-size-x 256 --crop-size-y 256 --crop-offset-x 128 --crop-offset-y 128

example re-publishing ion buffer image as regular image (which you can view in voxl-portal ) :

voxl-image-repub tracking_front_misp_norm_ion -o test

(you can see which ion pipes are available by running voxl-list-pipes | grep _ion)

Please note that without the previous fix that i posted above, the client process that receives and uncached ION buffer will incur extra CPU load while accessing this buffer. For example, the same voxl-image-repub client uses 1.7% cpu while republishing the normalized image (cached ion buffer), while using 7.3% cpu republishing an image from an uncached ION buffer. (cpu usage % using one of the smaller cores).

Please try and let me know if you have any questions.

I know this cached / uncached buffering may be a bit confusing, but i will document this a bit more to help explain it a little better.

Alex

@remill said in Different package version from voxl-cross and Voxl2:

1.0.27

Perhaps you can build the desired version of libusb from source and install it? We have used this approach for a variety of other "third party" libraries. Examples are here: https://gitlab.com/voxl-public/voxl-sdk/third-party?page=1

@SKA, you should be able to update libmodal-pipe to latest package in the dev package repository : http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64//

@alan123 , yes, the 12-pin connector on VOXL2 (J19) was designed such that the first 6 pins are compatible with a lot of existing GPS recevier modules. Please double check the pins and you should use a 12-pin connector to plug into VOXL2 (may need to re-pin your cable).

Alex

Hi @mark ,

Thank you for the update. We will keep investigating the underlying issue that was a result of that questionable camera.

Meanwhile, if you think that the camera is defective and has no damage, you can fill out an RMA request and send it back for an exchange. I cant really comment on what could be causing this on the camera itself (it would be interesting to try it), but the camera is not serviceable by the user.

https://www.modalai.com/pages/rma

Alex

Hi @Rowan-Dempster ,

I started a new branch where I will be working on some performance optimizations in the camera server.

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/tree/perf-optimizations

In my initial testing, setting cpu to perf and when running one or two instances of the following:

voxl-inspect-cam tracking_front_misp_norm tracking_down_misp_norm

i was seeing:

1 instance (2 inspected streams) : 42% CPU (of one core)
2 instances (4 inspected streams): 58% CPU (of one core)

with the changes i just committed, i am seeing:

1 instance: 31% cpu
2 instances : 36% cpu

If you would like you can test camera server from this branch and see if you can reproduce the results.

notes:

• the internal buffers were switched from uncached to cached and proper buffer management was added to ensure that data written by GPU is properly accessed by CPU
• with these changes, if you use the _encoded stream from the tracking camera, it will work, but in dmesg you will see messages related to qbuf cache ops failed -- this is still under investigation and will be fixed soon.

Meanwhile, I will work on an a simple example that shows the usage of ION buffers, I will try to share it a bit later today.

Alex

@박지현 Unfortunately, for Ardupilot, our ESCs are only supported with UART interface when using the VOXL 2 / VOXL 2 mini as the flight controller. When using Flight Core v2 that is not supported.