@svempati said in No detections when running custom YOLOv8 model on voxl-tflite-server:

I just ran voxl-tflite-server directly from the command line instead of in the background via systemd - aka run voxl-tflite-server directly on the command line. I would recommend NOT quantizing your model as the directions in the train yolov8 do not recommend that.

Zach

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-tflite-server/-/blob/master/include/tensor_data.h

These are all the potential data types that voxl-tflite-server is expecting.

@svempati said in No detections when running custom YOLOv8 model on voxl-tflite-server:

"labels": "/usr/bin/dnn/yolov8_labels.txt",

So running your model we get the following errors via voxl-tflite-server:

Error in TensorData<float>: should not reach here
Error in TensorData<float>: should not reach here
Error in TensorData<float>: should not reach here
Error in TensorData<float>: should not reach here
Error in TensorData<float>: should not reach here
Error in TensorData<float>: should not reach here
Error in TensorData<float>: should not reach here
Error in TensorData<float>: should not reach here

Which means there is an issue in your model itself and most likely means you ran into an issue during the build process. Specifically this means that is a model issue, not a labels file issue. Your .tflite model has an output tensor with a different data type than what voxl-tflite-server expects

The code itself shows the error when you hit this case statement:

// Gets the uint8_t tensor data pointer
template <>
inline uint8_t *TensorData(TfLiteTensor *tensor, int batch_index)
{
int nelems = 1;

for (int i = 1; i < tensor->dims->size; i++)
{
    nelems *= tensor->dims->data[i];
}

switch (tensor->type)
{
case kTfLiteUInt8:
    return tensor->data.uint8 + nelems * batch_index;
default:
    fprintf(stderr, "Error in %s: should not reach here\n",
            __FUNCTION__);
}

return nullptr;

}

Which means the output tensor doesnt match the expected output in this header file. Please look into your model.

zach

@jonathankampia said in M0201 gimbal passthrough pinout:

M0201

https://forum.modalai.com/topic/4735/m0201-m0153-j2-pinout/3

Please refer to this post for the pniout guide on the m0201

Hello @svempati can you paste your yolov8_labels and tflite file and I can test it out on my end?

To confirm - you followed the instructions in this gitlab repository: https://gitlab.com/voxl-public/support/voxl-train-yolov8

Zach

@Nitin-Varma-Vegesna In /etc/modalai/voxl-px4.conf set GPS to NONE. Then set the PX4 parameters SYS_HAS_GPS, and SYS_HAS_MAG to 0. Set EKF2_MAG_TYPE to 5. Set EKF2_GPS_CTRL to 0. Then reboot and see if the preflight error is cleared.

@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