@SKA , thank you for providing all the information. We are doing more testing and will get back to you. So far cannot reproduce.

Alex

@Nikos-Mavr You're welcome! And can you please start a new forum post for this new issue? Thanks!

@DronAlan
Hi there, the configuration & extrinsics files look fine (just switch offboard mode from figure_eight back to trajectory mode. Since you confirmed figure 8 and position mode are working fine and reflect true ground truth in voxl portal, next is to dive a bit deep into the processes:

Just to confirm: are you using a loaded saved map? Orientation can be different in a loaded maps based on how it was saved. Going forward in debugging this I would create the map while flying, then test plan-to-point to ensure it is working properly.

Before take off, if you ssh onto the drone and run voxl-vision-hub --debug_offboard and rerun the mapping test (point 1m in front of the drone hovering), and you don't need to map the entire room, just get the general area. In the ssh session, monitor the output from voxl-vision-hub. Take off and fly forward and backward in position mode, with some slight yaw motions to generate a decent map in voxl portal (recall we're generating a map in flight then plan to fly to a point, not using a old-saved map). Then switch into trajectory mode. In the ssh session, you should get a Received trajectory has duration message printed. Goto voxl-portal and plan-a-point. Then execute go-to-point. In the ssh session you should get a Received insert command. printed out on the terminal. And it will show the drone's forward commands, i..e set points, to your planned point. I expect the commanding: XYZ values to increase in the positive X direction. Please post the output of the ssh session here.

If the drone moves in the backwards direction as you've been seeing but the commanding XYZs are moving forward, we have found our problem (PX4 issue such that I'll need your params file). If the drone moves forward with commanding XYZs are moving forward then it's how your older maps are being saved and we can go from there.

@cguzikowski , sorry for the delay.

Long term, our plan is to add snapshot functionality directly into misp (just like you were getting snapshots from the ISP). That is not too difficult to achieve, may be a few weeks away.

Also let me ask you this: would you want to save the raw bayer and get that from voxl2 and convert to jpg / png offline? That would give you maximum control over quality / processing algorithm. Alternatively, de-bayering can be done on voxl2 and saved as lossy or lossless image?

We do have tools to convert bayer -> yuv -> jpeg but not yet in a standalone app.

You you can do for now is the following:

set misp output resolution equal to the raw resolution this will enable misp to publish the de-bayered yuv to the image pipe then you can use voxl-record-raw-image to save the yuv. Alternatively, you can test a WIP version of this tool which can save yuv as jpeg : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/merge_requests/37 ideally this logging would be done within camera server to reduce overhead for sending these huge images over the pipe. But the approach i described should work for now.

I will be able to test this again mid next week, meanwhile please let me know if you run into the saving issue. I will double check the issue with snapshot resolution being too large. How large was the isp snapshot that you tested before and had artifacts?

Alex

@RyanH , from the spin log above, i can only tell that the motor attempts to spin up but re-starts after the open-loop sinusoidal spinup is done and the ESC detects that the motor is not spinning.

You should try to clear the debris by spinning the motor by hand first (or use compressed air) and then use the test script to spin for longer periods of time without propeller (changing speeds, etc).

You could use a spin step command to automate increasing and decreasing spin speed (without rpm control, since it's not needed):

./voxl-esc-spin-step.py --id 0 --step-delay 2.5 --step-frequency 1 --power 20 --step-amplitude 30

Alex

@Alex-Kushleyev Thanks so much, we have the resistors on the way, will let you know how this goes.

Once this has been done, I would assume we would have no issues getting all of the cameras working with OpenVins

@Dan-Jennings I'm also guessing that the driver may not be detecting the hardware so is not able to get the data for the battery_status. Have you tried swapping some other hardware to see if the problem is associated with a particular unit?

@Aniruddha
On QGC, do the Parameters ever fully load? The reason I am asking is because if the connection to the GCS is not fast enough or strong enough for QGC to fully download the parameters then the other tabs like sensors and actuators in QGC will not appear. Which is why you are having an issue doing the level horizon from QGC. I know that QGC is seeing the video feed meaning you are connected, is the Green bar going across the full length of the fly view bar on QGC?

@boron , thank you for performing the test. Were you also to check if the 5V output (that normally goes to VOXL2) has 5V on it?

The capacitor that you circled in RED definitely appears to be damaged. This is a bypass capacitor on VBATT that is right next to the Mosfet Driver. It is possible that the capacitor was faulty and burned out, however since there is no short circuit or further overheating (based on the zero current draw from the power supply), the capacitor is probably not preventing the ESC MCUs from booting.

I suspect that there is another issue somewhere, but it would be good to know if the 5V rail is functional (i suspect that it is not). There is no on/off power switch on the ESC, so the main 5V regulator provides 5V from VBATT (which is used for VOXL2) and then another regulator that provides 3.3V (from 5.0V) for the four MCUs.

Alex

Thank you for the quick reply.
I will try doing as you instructed and post the results.

Thank you.
Kim

OK @Daehan-Won
Yeah, I'd try to run one first on it's own before the hub to rule that out.
Keep us posted.
Thanks!

@jameskuesel ,

For item 1, (a frame from hires recording with eis), you can do this already by just capturing the YUV from the hires_misp_color stream. you could do this using existing tool voxl-record-raw-image.

For item 2, the full frame can also be captured (using the same tool) but only in raw bayer format. This would be good for offline processing, if you wanted to get the maximum image quality, however this image would not have any processing applied from MISP.

Additionally, since MISP supports multiple outputs, as you already know, (misp channels), you could set up one channel to be a full frame image (which you normally dont stream), with EIS off.

So with correct voxl-camera-server.conf, you should be able to get all the streams you want

full frame hires recording low-res streaming

And grab YUVs from any of those streams. The last part would be then just encoding them to JPG (which could be done separately or part of voxl-record-raw-image, which we could add)

If you send me your voxl-camera-server.conf (or the part specific to the hires camera), i can update it to show you how you can get the three streams.

Alex

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads

Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.

I have uploaded the latest ar0144 drivers with fsin versions for all camera slots here : https://storage.googleapis.com/modalai_public/temp/ar0144/ar0144_drivers_20260402.zip

There are two additional files (inside the zip), which you should copy to /usr/lib/camera to make sure you have the latest updates:

com.qti.sensor.ar0144.so -- contains functions for exposure / gain control (we recently made some improvements to make gain control smoother) com.qti.tuned.default.bin -- fixed gain scaling so that min gain (1.0x analog gain) is equal to 100 in the HAL3 gain units, not 54 (and the max gain will be 29.6 = 29600 for AR0144) -- you can also double check this using voxl-camera-server -l and update the min/max gain settings in your voxl-camera-server.conf to make sure you are using the full range.

My colleague will follow up with a diagram for locations of the DNI resistors that need to be installed to enable sync signal for camera slots 1 and 3 (0402 0-ohm resistor)

Alex

@Daehan-Won You would need to add the support to PX4 since you are using the DSP I2C pins and only PX4 can access those while it is running. There is some useful developer documentation here: https://docs.modalai.com/voxl-px4-dev-build-guide/. Also visit the PX4 documentation as well. At a high level you'll need to fork our repo, make a branch off of voxl-dev, add the driver to the default.px4board file for voxl2-slpi, build the image, and add a start command into the startup script voxl-px4-start

@ndwe Whether you use a VOXL or Jetson as a companion computer shouldn't make any difference unless you want to use the VOXL SDK. The version you run is totally up to you. If our v1.14.0 based version works for you then use it. We do plan to transition to v1.17.x in the near future. I don't think the issues you are seeing are related to something specific in the flight core v2 hardware setup. I would think that if you swapped it out for some other brand you would see the same issue. I would ask on the PX4 forums to see if others have experienced the same issues.

Hi @irw
Can you please post High Res and clear photos of both sides of the VOXL 2?

@Piyush-Singh , can you please provide more details

how exactly all cameras are connected to VOXL2 mini (including interposers, flexes), etc. A diagram would help a lot which kernel variant are you running on your voxl2 mini (2.0.0 or 2.0.2).

Are all the other cameras working if you disable the TOF sensor in the camera server config?

Alex

@Alex-Kushleyev Awesome Thank you!

@Jesus-Cardenas It should now be updated!

Should be available on our new Downloads page: [https://modalai.filecloudonline.com](link url) , inside the Flat Builds Folder