@Steve-Turner voxl-build allows you to build the kernel only which you can then flash on top of an existing system. Qualcomm licenses are required in order to build a full system image.

@Huynh-Gremsy No, there is no way to do that. There is no display output

@hmlow Glad it worked! For future reference, the imx214_flip driver should be available internally from SDK 1.1 (system image 1.7) onwards. Rather than downloading from the above links, after SDK 1.1 is released the procedure will be as follows:

rm /usr/lib/camera/com.qti.sensormodule.imx214_3.bin cp /usr/share/modalai/chi-cdk/imx214-flip/com.qti.sensormodule.imx214_flip_3.bin /usr/lib/camera

@tom Thank you so much. It is done.

@tom I had the same idea, so I directly installed Mavproxy and related packages on VOXL2, and successfully resolved the issue with the serial library. However, when running the service, I still couldn't import the Python files related to Mavproxy. Even adding the paths of those Python files to the environment variables didn't solve the problem.

@19bpl At the very least you need to be able to ping the QGC computer from VOXL2 and VOXL2 from the QGC computer before attempting anything else.

@Kashish-Garg-0 It's possible your board has a QSM8250 (M0054-2) instead of a QRB5165 (M0054-1), see here for the diffs: https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2

If that is the case then you will have to QDL using a different build, which you can download from downloads.modalai.com, look for M0054-2 Starling QDL Image 1.7.4 2024-02-09-1.7.4-M0054-2.zip under the "All" category

@Vinny Thanks for the help on this I really appreciate it. I'll take a look.

@Peter-Milani , I see. this looks like a generic implementation of OpenCL for ARM from 3rd party (not Qualcomm), and i think it also overwrites the proprietary opencl libraries, disabling the GPU opencl support. However, you could make two separate docker images, one for each use case (cpu and gpu)

Alex

@Zachary-Lowell-0

Hello! I was able to reinstall 1.3.5 and that somehow fixed it! I am not going to question it lol.

Now I'm trying to find out how to install voxl-mapper and I can't find documentation for it. I am flying the drone inside a test lab. Today when I was flying it around the room, the drone was not mapping anything. The 2D/3D map was blank when I went to plan a point. I think it's blank because I am missing voxl-mapper especially since I have camera-server, vision hub, voxl-px4 and qvio enabled/running. All I have seen is that I have to change "offboard_mode": "trajectory", in order to plan a point on the map and have the drone fly to it.

Is there any documentation on getting voxl-mapper and planning a point?

@garret Here's the source code for our branch of Gazebo: https://github.com/modalai/PX4-SITL_gazebo-classic/tree/voxl-dev

@emarcphera Huh, interesting. Okay, thanks for posting the update!

@Alex-Kushleyev sure thing. As per your suggestion, I modified voxl-lepton-server by moving all the Lepton camera-specific logic into a C++ class and added locks to any I2C operations to prevent race conditions. I then just created 2 instances of the LeptonCamera class I made which parse and publish the camera feeds to their own pipes which I can view in voxl-portal.

I didn't need to disable any I2C interface for the second Lepton. I'm not too sure what you were referring to by that.

In regards to the horizontal line artifacts, those don't seems to consistently appear and I don't know what causes it. I'll investigate it further.

My next steps are to get the Leptons working with voxl-open-vins-server. One question I had was that our VOXL 2 Mini appears to be running a service called voxl-lepton-tracker however I cannot find the source code for this anywhere on the voxl public GitLab. Was it removed or hidden?

@Aldo-Castro-Freire thanks for the feedback, do you mind sharing the openVPN Client and Server versions you ended up using that worked?

We've tested using server v2.4.8, voxl-vpn (v2.1.3 inside that), and OpenVPN Connect ver 3.2.2 on Adroid.

Sounds good, thanks!

I reran the calibration outdoors with gps signal and far from any metal. I also raised the drone to be ~3-4' from the metal turntable below it. This improved the calibration quite a bit and the drone is not drifting as much as before. However, there still seems to be more drift in the VIO than there was when I first received the drone. I still don't have the PWM_MIN parameter that the docs say I should check for the assure the PX4 parameters loaded properly. I see that this parameter is in the custom2.params file, but the note in the document says it turns off the gps.

Can you please explain the steps you go through during your calibration process? Should I also be loading this custom2.params file? If so, does that mean that gps is not used when in VIO (no sensor fusion etc)?

Solution: sometimes when just binding the RC controller, the inputs aren't shown. Make sure to restart drone after rebinding. Additionally, I've found different controllers have different lever/switch inputs, so its good to use QGC to look for the responsive switches and assign the ones you want accordingly

@Daniel-Ryu

I figured. We just wanted to double check that this was the case. Thank you!

last question :
I could not see the point cloud with stereo , but since I need it to indoor solution, I will use tof anyway.

I using the drone without any GPS module (don't need it)
but I could not to change from manual to mission nor off board.

when I change the gps to rc transmitter (first option) I was able to get move to mission
but only left stick worked (up down rotate) the second stick won't work (forward and rotation)

is there a way to move to mission without gps module?

Please see email thread in progress, if possible let's use one channel for communications.