Posts made by Zachary Lowell 0

^^^ This is the next best option outside of ADB IMO - nice suggestion @Alex-Kushleyev

@qt said in PX4 -> QGC connection through USB for VOXL2:

name

@bendraper I kind of redid exactly what you described above and ran into very similar issue in the sense that it basically rocked my usb-c port. All this to say, I think we should choose a different route - is it possible instead to route the packets via adb over the USB-C port instead to basically get the same result? Point the software to the serial connection and leverage ADB to pull the packets that are forwarded? Basically creating our own sudo rndis connection almost.

Zach

Hi All - gonna spend a bit of time looking into this today so I can get some context on the problem.

Zach

@voxltester said in Microdds not working with Microhard modem:

Is there any one who is an expert on the microhard and network setting?

You will need to reach out to microhard for config setup on that front.

@Nitin-Varma-Vegesna said in Apriltag relocalization not relocalizing?:

@Nitin-Varma-Vegesna Is there any release that is known to work for April Tag Detection?

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-tag-detector

The dev branch is the most recent - I have to check with the engineering team on this as I am unsure the priority of april tag detection and positioning based off it. Will relay back

https://www.loom.com/share/bf52e252ab09444bb366f265a3f36dc5

Alright take a look at this loom please - it might help point you in the right direction in terms of training your model.

Zach

Let me try and train a custom model and run a loom on it in the next few days and get that over to you showing how I do it!

@voxltester said in Microdds not working with Microhard modem:

Do you have any ideas on how to resolve this?

There might be a dependency in the service file - I would recommend taking a look at the file in /etc/systemd/system/voxl-microdds-agent.service and see if there are any dependencies on having WLAN devices plugged in - I am under the impression there is not that dependency, but there is a conflict on which interface you want the dds to start on - so ideally you can add in which interface you wish to leverage into the service file.

Zach

@svempati I was able to use an open source training set and then leverage the docs to make my own custom yolov8 model capable of running on the voxl2 - do you want to provide to me the actual dataset and I can try creating the model and training it on a TPU?

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

WARNING: Unknown model type provided! Defaulting post-process to object detection.

@svempati I will try recreating this issue today and get back to you!

@Peter-Lingås-0 I do not have an answer for any global shutter cameras but what I can tell you is that the AR0144 camera can be used for anything as well not just VIO - the frames being piped out go into the software dedicated for OVINS but it can also be piped anywhere else due to the pub/sub architecutre, so you should have no problem piping that into your computer vision software either.

I would recommend doing a barometer calibration as well via voxl-calibrate-barometer that tends to solve a good chunk of the altitude issues.

@alan123 said in Using a GPS through SPI:

I'm currently attempting to use a GPS through the J10 SPI port on the VOXL 2. I plugged it in and ran voxl-inspect-gps but it doesn't seem to be connected. Do I have to change some software settings to get this to work?

@alan123 yes you need to change the port that the driver is pointed to. Currently on the voxl2 inside of /usr/bin/voxl-px4-start there is a line that is somewhere along the lines of qshell gps start XYZ and in there one of those args is the literaly bus on the voxl2 that the driver should be probing - if you wish to change to J10, you need to change one of those arguments to point to that endpoint.

@rnunna at this point I would recommend either creating a python or cpp script that leverages mavsdk to probe the logs and get it into the format you are desiring.

Zach

@jared-upshaw the voxl mini also runs the flight stack, so ensure if you are leveraging the flight core v2 and plan on using the voxl2 mini purely for onboard compute, that you disable voxl-px4 on the voxl2 mini as to not get conflicting mavlink messages (serially connect the two over a uart)

As for camera setup, please find the link to the documentaiton on which cameras work with the voxl2 mini and how to wire them up!

https://docs.modalai.com/voxl2-mini-image-sensors/

@Muqing-Cao you have voxl-open-vins-server and voxl-qvio-server running at the same time. Only one can be run - modalAI defaulted to open-vins as the main method for positioning - if you have both running, you are bound to run into conflicting errors.

@Nitin-Varma-Vegesna said in GPS for Starling2:

I got the compass sensor missing error for my Starling2, and I think it's an issue with the GPS. I want to buy a new GPS for the Starling2 ASAP, and I didn't see it on the products on the website. Is there a way for me to do that?

1 Reply Last reply a day ago Reply

@Nitin-Varma-Vegesna https://store.3dr.com/mini-gps-ublox-max-m10s/ <-- this is the gps that comes default with the starlings.

@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