@cbay , you could actually test two leptons by disabling i2c port for one (or both) of them. Lepton starts up streaming data by default via SPI, so you can get frames from it without any communication.

In order to do that, you would need to run two instances of voxl-lepton-server and the second instance would have to be modified to read from a different config file and to not kill the existing voxl-lepton-server process (and probably name itself differently, so that the first server does not kill the second during start-up).

If this all works, then in order to actually test two leptons with i2c communication (which we use the set the FFC mode depending on the flight mode and also reset the sensor if it gets into a weird state while streaming), the lepton server functionality would probably need to be added to a C++ class so that multiple instances could be run from the same process. The reason is that there needs to be a single point where the i2c switcher is set to one or the other lepton, right before communicating to one of the leptons (without the other server / thread creating a race condition and trying to do communicate right at the same time)..

I'd have to think about the fastest way of doing this, but at least you should be able to test two leptons with second not using i2c with very minimal changes.

Here is the source code for the voxl-lepton-server in case you did not already find it: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-lepton-server/-/blob/master/src/

Alex

@Alex-Kushleyev Could you please share the pinouts of the serial console port. I am not able to find it anywhere.

@greg_s
Hi there, your extrinsics are good: same as a factory Starling. Now, if you altered the voxl-camera-server.conf (e.g. enabled a flip of a camera stream when it wasn't) or physically changed a camera mount point then the extrinsics would need to be adjusted. Let assume that's not the case.

From your vvhub trajectory output, it appears your setpoints command the vehicle to move forward (X) and to the right (Y) > 1m while dropping altitude (Z) 0.8m --recall mapper runs in FRD (aka body) space where Z up is negative. Also you do pass through the take off origin (0,0,0). If that's not what you wanted, then we have a "requested trajectory" drawing problem in the portal tool or mapper's found invalid regions/obstacle and could not draw the "requested trajectory".

In the former case @ApoorvThapliyal mentions the un-intuitiveness of the portal tool that you already understand.

In the latter case, upon "request trajectory" submission, voxl-mapper will analyze the map to see if there are obstacles and alter the trajectory to fly around potential obstacles. You can alter in voxl-mapper.conf:

rrt_min_distance (try 0.125) esdf_inner_sphere_radius (try 0.15)
if you seeing mapper create trajectories going around 'ghost' objects. This should allow RRT generated trajectories to get closer to objects.

In checking precision, you'll need to take the trajectory output (e.g. the setpoints in the *commanding: XYZ* messages) and compared it against VIO position to determine tracking error. You have 2 ways to get that data:

option 1 is record you vvhub traj output as above and record the output of voxl-inspect-vins -n then plot compare the tracking error.

option 2 is running voxl-vision-hub --debug_offboard --debug_odometry which you'll need to seperate the traj messages from the vio (T_body_wrt_local) messages, then you ca plot the tracking error.

The goal is we want the vio position to follow the commanded trajectory: (it's doing what is told to do). That will narrow down where your concerns are w.r.t what module has a problem.

Hopefully that gets you on the right track, just post any outputs you gather that continue to show tracking error.

@Alex-Kushleyev Found the reason why it was skipping. In /px4-firmware/src/lib/parameters/CMakeLists.txt there is a line that skips all modules that match 'pwm_out'. I was able to disable that for PCA9685. Once I disabled the module.yaml file being skipped it worked. No need for the .c file (which makes sense, that is just the old way to do the .yaml)

Another question.. did this work for you before or is this the first time trying to calibrate at half resolution? if you request the full resolution, do you get the non-zoomed image? i know it will be slow to display in voxl-portal, but you could still check.

If you enable EIS with default camera calibration (no intrinsics cal file). does EIS and zoom work as expected? note that your version of voxl-portal may not have the browser support for zooming, but the config file zoom should still work. If you want to use the latest voxl-portal for EIS, please use this branch : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-portal/-/tree/eis-integration . however the initial zoom of the image coming from the camera server is not dependent on the version of voxl-portal.

Alex

@bendraper I just tried it and it is working now:

modalai@modalai:~/development/modalai/voxl-vision-hub (dev)$ voxl-docker -i voxl-cross launching image: voxl-cross with the following command: docker run --rm -it --net=host --privileged -w /home/modalai --volume=/dev/bus/usb:/dev/bus/usb -e LOCAL_USER_ID=0 -e LOCAL_USER_NAME=root -e LOCAL_GID=0 -v /home/modalai/development/modalai/voxl-vision-hub:/home/root:rw -w /home/root voxl-cross /bin/bash -l voxl-cross(4.4):~(dev)(1.9.21)$ ./clean.sh voxl-cross(4.4):~(dev)(1.9.21)$ ./install_build_deps.sh qrb5165 dev using qrb5165 dev debian repo Ign:1 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ InRelease Ign:2 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ Release Get:3 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ Packages [76.8 kB] Fetched 76.8 kB in 1s (122 kB/s) Reading package lists... Done INSTALLING: libmodal-json libmodal-pipe librc-math libmodal-cv voxl-mpa-tools voxl-mavlink Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: libmodal-cv:arm64 libmodal-json:arm64 libmodal-pipe:arm64 librc-math:arm64 voxl-mavlink:arm64 voxl-mpa-tools:arm64 0 upgraded, 6 newly installed, 0 to remove and 2 not upgraded. Need to get 5026 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ librc-math 1.4.6-202510091209 [180 kB] Get:2 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ libmodal-cv 0.6.0-202510141028 [3887 kB] Get:3 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ libmodal-json 0.4.8-202510091202 [52.5 kB] Get:4 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ libmodal-pipe 2.14.10-202601210836 [151 kB] Get:5 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ voxl-mavlink 0.1.6-202511141246 [650 kB] Get:6 http://voxl-packages.modalai.com ./dists/qrb5165/dev/binary-arm64/ voxl-mpa-tools 1.5.6-202601201423 [106 kB] Fetched 5026 kB in 1s (6805 kB/s) debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 79, <STDIN> line 6.) debconf: falling back to frontend: Readline Selecting previously unselected package librc-math:arm64. (Reading database ... 35164 files and directories currently installed.) Preparing to unpack .../0-librc-math_1.4.6-202510091209_arm64.deb ... Unpacking librc-math:arm64 (1.4.6-202510091209) ... Selecting previously unselected package libmodal-cv:arm64. Preparing to unpack .../1-libmodal-cv_0.6.0-202510141028_arm64.deb ... Unpacking libmodal-cv:arm64 (0.6.0-202510141028) ... Selecting previously unselected package libmodal-json:arm64. Preparing to unpack .../2-libmodal-json_0.4.8-202510091202_arm64.deb ... Unpacking libmodal-json:arm64 (0.4.8-202510091202) ... Selecting previously unselected package libmodal-pipe:arm64. Preparing to unpack .../3-libmodal-pipe_2.14.10-202601210836_arm64.deb ... Unpacking libmodal-pipe:arm64 (2.14.10-202601210836) ... Selecting previously unselected package voxl-mavlink:arm64. Preparing to unpack .../4-voxl-mavlink_0.1.6-202511141246_arm64.deb ... Unpacking voxl-mavlink:arm64 (0.1.6-202511141246) ... Selecting previously unselected package voxl-mpa-tools:arm64. Preparing to unpack .../5-voxl-mpa-tools_1.5.6-202601201423_arm64.deb ... Unpacking voxl-mpa-tools:arm64 (1.5.6-202601201423) ... Setting up voxl-mavlink:arm64 (0.1.6-202511141246) ... Setting up libmodal-json:arm64 (0.4.8-202510091202) ... Setting up librc-math:arm64 (1.4.6-202510091209) ... Setting up libmodal-pipe:arm64 (2.14.10-202601210836) ... Setting up libmodal-cv:arm64 (0.6.0-202510141028) ... Setting up voxl-mpa-tools:arm64 (1.5.6-202601201423) ... Processing triggers for libc-bin (2.39-0ubuntu8.5) ... Done installing dependencies voxl-cross(4.4):~(dev)(1.9.21)$ ./build.sh qrb5165 Found voxl-cross version: 4.4 -- --------------------------------------------------------- -- Using voxl-cross 64-bit toolchain for QRB5165 ubun1 18.04 -- C Compiler : /usr/bin/aarch64-linux-gnu-gcc-7 -- C++ Compiler: /usr/bin/aarch64-linux-gnu-g++-7 -- Sysroot : /opt/sysroots/qrb5165_1 -- C flags : -isystem=/usr/lib/gcc/aarch64-linux-gnu/7/include -isystem=/usr/local/include -isystem=/usr/lib/gcc/aarch64-linux-gnu/7/include-fixed -isystem=/usr/include/aarch64-linux-gnu -isystem=/usr/include -idirafter /usr/include -march=armv8.2-a -- CXX flags : -isystem=/usr/include/c++/7 -isystem=/usr/include/aarch64-linux-gnu/c++/7 -isystem=/usr/include/c++/7/backward -isystem=/usr/lib/gcc/aarch64-linux-gnu/7/include -isystem=/usr/local/include -isystem=/usr/lib/gcc/aarch64-linux-gnu/7/include-fixed -isystem=/usr/include/aarch64-linux-gnu -isystem=/usr/include -idirafter /usr/include -march=armv8.2-a -- Link Flags : -B/opt/sysroots/qrb5165_1/usr/lib/ -L/opt/sysroots/qrb5165_1/usr/lib/gcc/aarch64-linux-gnu/7 -L/opt/sysroots/qrb5165_1/usr/lib/aarch64-linux-gnu -L/opt/sysroots/qrb5165_1/usr/lib -L/opt/sysroots/qrb5165_1/lib/aarch64-linux-gnu -L/opt/sysroots/qrb5165_1/usr/lib/aarch64-linux-gnu -L/opt/sysroots/qrb5165_1/lib -L/usr/lib64 -L/usr/lib -- The C compiler identification is GNU 7.3.0 -- The CXX compiler identification is GNU 7.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc-7 - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/aarch64-linux-gnu-g++-7 - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done (0.3s) -- Generating done (0.0s) -- Build files have been written to: /home/root/build [ 6%] Building C object utils/CMakeFiles/voxl-inspect-vfc.dir/voxl-inspect-vfc.c.o [ 6%] Building C object utils/CMakeFiles/voxl-calibrate-px4-horizon.dir/voxl-calibrate-px4-horizon.c.o [ 12%] Building C object src/CMakeFiles/voxl-vision-hub.dir/control_input.c.o [ 12%] Building C object src/CMakeFiles/voxl-vision-hub.dir/fixed_pose_input.c.o [ 18%] Building C object src/CMakeFiles/voxl-vision-hub.dir/geometry.c.o [ 18%] Building C object src/CMakeFiles/voxl-vision-hub.dir/autopilot_monitor.c.o [ 24%] Building C object src/CMakeFiles/voxl-vision-hub.dir/config_file.c.o [ 24%] Building C object src/CMakeFiles/voxl-vision-hub.dir/horizon_cal.c.o [ 30%] Building C object src/CMakeFiles/voxl-vision-hub.dir/main.c.o [ 36%] Building C object src/CMakeFiles/voxl-vision-hub.dir/mavlink_io.c.o [ 36%] Building C object src/CMakeFiles/voxl-vision-hub.dir/imu_manager.c.o [ 27%] Building C object src/CMakeFiles/voxl-vision-hub.dir/horizon_cal_file.c.o [ 39%] Building C object src/CMakeFiles/voxl-vision-hub.dir/mavlink_for_ros.c.o [ 42%] Building C object src/CMakeFiles/voxl-vision-hub.dir/offboard_backtrack.c.o [ 45%] Building C object src/CMakeFiles/voxl-vision-hub.dir/obs_pc_filter.c.o [ 48%] Building C object src/CMakeFiles/voxl-vision-hub.dir/misc.c.o [ 51%] Building C object src/CMakeFiles/voxl-vision-hub.dir/offboard_figure_eight.c.o [ 54%] Building C object src/CMakeFiles/voxl-vision-hub.dir/offboard_follow_tag.c.o [ 57%] Building C object src/CMakeFiles/voxl-vision-hub.dir/offboard_mode.c.o [ 60%] Linking C executable voxl-calibrate-px4-horizon [ 60%] Built target voxl-calibrate-px4-horizon [ 63%] Building C object src/CMakeFiles/voxl-vision-hub.dir/offboard_trajectory.c.o [ 66%] Linking C executable voxl-inspect-vfc [ 66%] Built target voxl-inspect-vfc [ 69%] Building C object src/CMakeFiles/voxl-vision-hub.dir/offboard_vfc.c.o [ 72%] Building C object src/CMakeFiles/voxl-vision-hub.dir/offboard_wps.c.o [ 75%] Building C object src/CMakeFiles/voxl-vision-hub.dir/pose_filter.c.o [ 78%] Building C object src/CMakeFiles/voxl-vision-hub.dir/state_manager.c.o [ 81%] Building C object src/CMakeFiles/voxl-vision-hub.dir/tag_manager.c.o [ 84%] Building CXX object src/CMakeFiles/voxl-vision-hub.dir/trajectory_monitor.cpp.o [ 87%] Building C object src/CMakeFiles/voxl-vision-hub.dir/transform_ringbuf.c.o [ 90%] Building C object src/CMakeFiles/voxl-vision-hub.dir/vio_manager.c.o [ 93%] Building C object src/CMakeFiles/voxl-vision-hub.dir/voa_manager.c.o [ 96%] Building C object src/CMakeFiles/voxl-vision-hub.dir/voxl_vfc_config.c.o [100%] Linking CXX executable voxl-vision-hub [100%] Built target voxl-vision-hub

@Nitin-Varma-Vegesna Please update your SDK to the latest... Minimum SDK required does not mean best performance.

Also, please follow this post for posting guidelines: https://forum.modalai.com/topic/2670/please-read-support-request-format-for-best-results

Finally, please provide a screenshot of your voxl-inspect-cpu output...

@colombe-ai I'm not sure how much we're going to be able to help to get this going but I'd start with that magnetometer. Put an oscilloscope in the lines and see if you see any activity.

@zauberflote1

alright, thanks for your help!

Hi @jon ,

OK got it. Actually, we already do have a passthrough mode that can accept raw data coming from linux (via voxl io server) and forward it to the UART connection for voxl2_io board, for reference, code is here : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/voxl2_io/voxl2_io.cpp#L270

Let me figure out (remember) how to use it, I will update you soon.

Alex

Hey @yunwool
Just to be clear, consider only your first drone, if you run export ROS_DOMAIN_ID=1, then run ros2 topic list, you aren't seeing any topics right?

After you set the ROS_DOMAIN_ID of a drone to 1, to get the PX4 topics to show up, on QGC > Analyze Tools > MAVLink Console, run the following commands:

param set XRCE_DDS_DOM_ID 1 param save

Then power cycle the drone, give it like 15s after boot up, then the topics should come up directly when running ros2 topic list on that drone.

@lhermosillo It was 15 with/without the GPS.

@Richa . thanks for the details, got it it.

I will need to test the master / slave mode. Is your plan to have one IMX664 generate the sync signal (master) and the other(s) IMX664 being slaves? or all slaves?

I should be able to give it a quick test this week. The change would involve setting several additional registers in the camera configuration, which would mean a change in the sensormodule driver for the camera. we can figure this out after i verify the functionality.

Alex

@Jetson-Nano ,

We have not tried QVIO with Boson, it may work (but we can't really support that). The boson output is usually a bit fuzzy, so i am not sure how the feature detection will work, but it may be ok. Disabling FFC will definitely resolve the gaps in the frame feed, but disabling the FFC will also affect the Boson image quality, which may degrade over time.

If you wanted to use any USB (thermal) camera with VIO, you would just have to use voxl-uvc-server to publish the images to mpa, so that voxl-qvio-server can subscribe to them. The only issue is that the uvc interface does not provide accurate timestamp of the camera, but it may be ok just to use the time of arrival of the frame. QVIO does estimate the time offset between the IMU and camera, so as long as the timestamp is consistently captured, it should be ok..

Alex

@Morten-Nissov ,

Is it just the specific camera (tracking) not working in a specific port? what if you connect TOF or IMX214 camera there?

For your configuration using the M0135 interposer, kernel variant 2.0.0 is the correct one to use. Using kernel 2.0.2 will result in some cameras not working due to different pins used for camera reset (which get properly routed in M0188 and M0195 camera adapter boards for the coax cameras).

So i would suggest using the correct kernel 2.0.0, then test one camera at a time and see if you can narrow it down to a camera or port not working.

Alex

Hi @shawn_ricardo
Yes, any I2C port on an expansion board has 2.2K pullups to the voltage on Pin 1 of that connector.

The Linux Kernel user guide has info on which QUPS are enabled or not in which system image.
3356687b-6e2d-4443-9a15-6e9aa07566d1-image.png
and specifically this helps:
https://docs.modalai.com/voxl2-qups/
Note not all QUPs have actually been enabled in the system, but with the sets of ports we have enabled, we never had any customer claim of a shortage:

@Moderator Thanks for the quick response!

Which helper would you recommend for outdoor flight configuration with GPS? I see there are several available for different variations.

An added detail: we need good relative altitude measurements at low altitudes for our custom precision landing solution.

@jbhines929 Hi JB, sorry you are running into issues.

One quick thought, is to update the Orqa goggles firmware - https://orqafpv.com/downloads . There were issues at one point, but we have been updating them in the factory recently before shipping

To further isolate, can you plug a different display into the VRX DisplayPort output? Or, try to connect ADB to the VRX? that would let us know if it's a Goggles or VRX issue. (sounds like goggles if they are clicking)

You can always submit an RMA here: https://modalai.com/rma

@Alex-Kushleyev This was what I got when opening the file in SolidWorks:
a3f8d672-9ddc-465e-85c5-f40e6203ce29-image.png

I found a symlink mismatch in the file tree... pushing M073 PCB board with M0172 connector.

Anyway, it is solved now:

8f13ae56-bfcd-4829-8bd1-e238097e9bb0-image.png

Thank you.

Regards,
Jacob

@Vinny Thanks for the info,

Just to be clear, I am not looking for the PCB design schematics, just a symbol per board showing all the inputs and outputs to the board as a whole which then could be used in a system wiring diagram. If not I can just go ahead and make them myself, as all the info for it is on your docs