@rdjarvis , I received the M0138 ESC that you sent back (reported that you were unable to communicate with the ESC).

The issue was that the baud rate in ESC params was set to 2.5Mbit instead of 250K by accident, so our auto-scan in ESC tools could not detect the ESC (and VOXL2 DSP does not support 2.5Mbit).

We will fix this in future ESC firmware to prevent accidental setting of unsupported baud rates. Sorry about that.

Alex

@Chase-Riley Okay, thanks for the update. I'll have to add an option to ignore the protocol byte check in the Spektrum driver then.

@Chad-Sweet @Adrian-Hidalgo @James-Strawson
Everything is working now! THANK YOU so much for all your help!!!

@Eric-Katzfey Got it working about 50% of the time. It seems like most of the time it is just the uvc server trying to connect. I am going to see if I can create a service file around it. Maybe restarting on fail will get it to work with a bit of delay in between.

A bandaid for the issue, but at least it will work

@Aaky The Microhard board does not expose an apps processor UART but you could use a USB to UART adapter to connect to the Gimbal via one of the USB ports.

@Ajay-Bidyarthy

Only the inference time should be affected by your choice of hardware. The other two should be the same regardless of your choice.

Thomas

@Aaky You'll have to use a nightly build of the SDK, here's a link to the latest one: https://storage.googleapis.com/platform-nightlies/voxl2/voxl2_SDK_nightly_20241208.tar.gz

Keep in mind that these builds are untested so we can't promise any functionality

@Darshit-Desai

Yeah, for reference almost all of the voxl-tflite-server code and documentation was written by a former employee so I don't always have the source of ground truth for things. I think there may be some logic in there that deals with reshaping the output tensors but I'm not fully sure. Same thing with the --half argument, I think we advise it but if you can get your model to work without quantization that's awesome. Glad to see it's working!! The results look good 🙂

Keep me posted on how I can help,

Thomas Patton

@tom thanks

@Alex-Kushleyev Awesome!! Thanks!

@Captain-7th Please check the new forum post where you ask all these questions again.

@Alexander-Saunders Looks better now. What does the dsp_hitl start command look like now? Seems like it is setup for VIO only.

@Aaky Should be fine. I fly with actual RC in HITL all the time.

hey not sure if this is an @tom or @modaltb inquiry, but when following the steps for the kernel build guide, stuff is off with the drone. It boots up and I can adb fine, but there are issues with the wifi, similar to another post Tom helped me with two weeks ago, but for definitely not the same hardware-related reason. The wifi adaptable does not turn on and when you run voxl-wifi the mac address is undefined. I remember stepping through those scripts while troubleshooting the hardware issues and recall that script queries to find its mac address, which must be returning something invalid.

I have tested this with both of my drones. I can very easily flash them back with https://docs.modalai.com/sentinel-factory-reset/ and they operate as expected. While my desire is to edit part of the usb driver scripts, the kernel I am attempting to put on the drone is the unchanged version following the steps here https://docs.modalai.com/voxl2-kernel-build-guide/. The only deviation from the guide is that the guide is written for SDK 1.1.3. I have put 1.3.0 on both of my drones, and from my understanding the docker scripts pull the default branch of each repo which has the same commit tags as 1.7.8. I have included the output of dmesg for both the 1.3.0 image available from the downloads page, and the results when following the custom kernel build steps.

https://drive.google.com/drive/folders/14L5gLbAOfF2OcSW2rHFTI4VIoREkTCFJ?usp=sharing

Hi there, looks like there's some confusion with what mode is being tested. Here's some clarification. PX4 has 2 approaches to handling obstacle distance data:
a. Obstacle Avoidance(OA) feature which stops the aircraft if object detection occurs from the voxl-voa service. This requires CP_* parameters set that you can compare with your drone listed here based on your application.

b. Collision Prevention(CP) feature, which not only includes OA, but also rerouting capability in all autonomous modes (position, alt, mission, offboard) and leverages the same voxl-voa service. This requires not only the CP_* parameters but also requires COM_OBS_AVOID = enable.

If your application requires (a), you can leave com_obs_avoid = disable and OA should work out of the box as is. If your application requires (b), then we have discovered a software bug in the VOA service. And the main reason you get the "collision module not ready", no arm possible. It has been corrected [code here] and binaries will be available in our gitlab daily builds shortly.

switch to wifi station mode - https://docs.modalai.com/wifi-setup/
It fixed for me

@Kris The intention with the Logitech camera was to use it with voxl-uvc-streamer as Tom pointed out. That way you have a complete working setup and then you can start changing one thing at a time to get to what you want. If you want to switch to a different camera then you can see the differences in the new camera from the Logitech camera and try to debug that way. If you want to add a record feature with GStreamer then you can fork our voxl-streamer code and add the functionality into that. If you want to do it with a gst-launch-1.0 command line pipeline then you are farther away from anything we currently support and it's going to be hard for us to offer much help. I do think that what you are trying to do should be possible.

@stevedan No, we have not encountered that. But can you open this up in a new thread so that it has an appropriate title? Thanks!

@Matt-Turi Ok nice i've send an email to you

@wilkinsaf No, took out usb0 entry and it still didnt set the correct ip