ModalAI Forum

Adrian Hidalgo

Adrian Hidalgo

Thanks for providing that information. Was it just one battery that was faulty? If so, we will ship a replacement battery to you. Please provide your original order number so we can look up your information.

Adrian Hidalgo

Hello @colby-howell

Sorry to hear that the battery arrived dead. Let's work to fix that.
I'm guessing that the battery will no longer hold a charge since it was fully drained?

Rowan Dempster

Setup

Board: VOXL2 (M0054)
System image: 1.7.8-M0054-14.1a-perf, kernel 4.19.125
libqrb5165-io 0.5.0
Bus 3 controller: qcom,spi-geni, bound to the spi_geni platform driver, exposing a single chip select (spi3.0 → /dev/spidev3.0)

We are adding an ams TMF8829 time-of-flight ranging sensor to an existing VOXL2 design. For layout reasons it is wired to SPI3, the same bus as the onboard ICM-42688 IMU that voxl-imu-server services. The IMU runs at SPI_MODE_3 on the controller's native chip select; the TMF8829 runs at SPI_MODE_0 and is selected through a TLMM GPIO (117), with its enable line on GPIO 118.

The problem

SPI3 exposes exactly one native chip select, and it is wired to the IMU. The GENI controller asserts that native CS on every transfer it performs, so any transfer we issue for the TMF8829 also selects the IMU. Since the TMF8829 wire protocol begins each transaction with a write opcode (0x02), the IMU interprets TMF traffic as register writes addressed to itself. That is not merely a corrupted read — it can reconfigure the IMU mid-flight and take down a flight-critical data stream.

The standard Linux remedy is the SPI_NO_CS mode flag, suppressing the controller's chip select so our GPIO alone selects the target. The kernel rejects it on this platform. Issuing the ioctl directly on the descriptor returned by voxl_spi_get_fd(3):

spi_bus3: SPI_IOC_WR_MODE32 0x40 failed: Invalid argument

0x40 is SPI_MODE_0 | SPI_NO_CS. Both the legacy 8-bit SPI_IOC_WR_MODE and the 32-bit SPI_IOC_WR_MODE32 return EINVAL, which points to SPI_NO_CS not being advertised in the controller driver's mode_bits. Separately, voxl_spi_init() in libqrb5165-io validates its mode argument strictly against SPI_MODE_0..3 and rejects any extra flag bits, so the flag cannot be requested through the library either — but we bypassed that with direct ioctls on the raw fd and the kernel is the hard stop.

Our integration treats this as a safety gate: at startup it writes SPI_MODE_0 | SPI_NO_CS, reads it back, and if the readback fails it disables the TMF entirely and leaves IMU publication untouched rather than risk corrupting the IMU. That gate is what fires today, so the second sensor never comes up.

For completeness, the surrounding work is done and validated on hardware. We have a bus-3 arbiter that serializes access with a mutex, switches mode and clock per transaction, and restores SPI_MODE_3 with native CS on every success and error path. Matched 10-second A/B captures with the TMF path compiled in but gated off show no IMU regression: 1024 Hz in both conditions, 0.977 ms mean sample interval with no interval above 2 ms, and zero FIFO errors, logger drops, or mode-restore failures. The TMF8829 itself is known good and streams reliably at 15–18 MHz when it has a bus to itself. The only missing capability is per-device chip-select control on a shared bus 3.

Path 1 (preferred): declare bus 3 with `cs-gpios` and a second spidev child node

Rather than work around chip select in userspace, we would rather let the kernel own it, which is how Linux is designed to share an SPI bus. Concretely, on the SPI3 node: raise the chip-select count to 2, add cs-gpios with the native CS in slot 0 and &tlmm 117 in slot 1, and add a second spidev child at reg = <1>. The TMF8829 then appears as its own /dev/spidev3.1 with its own spi-max-frequency and mode.

With that in place the kernel handles chip-select assertion, clock, and mode switching per device. On our side we delete the manual GPIO chip-select toggling and the entire mode-restore arbiter, and the IMU is never exposed to TMF traffic at all — a substantially safer arrangement than anything we can build in userspace.

Questions on this path:

Does the spi_geni driver in the 1.7.8 kernel cooperate with the SPI core's generic cs-gpios handling, or does its own set_cs implementation bypass GPIO chip selects?
Is there a supported way for us to apply a devicetree overlay or a patched DTB to a VOXL2 system image, or does this have to come from ModalAI as an image change?
Are there known constraints on SPI3 specifically — reserved chip selects, pinmux conflicts on TLMM 117, or other consumers of that controller we should know about?

Path 2 (fallback): add `SPI_NO_CS` to the controller driver's supported mode bits

If the devicetree route isn't viable, the smaller change is to advertise SPI_NO_CS in the GENI SPI controller's mode_bits and honor it in the driver's chip-select path. Our existing arbiter code already works unmodified against that interface, so this would unblock us with no changes on our side, and it would also need voxl_spi_init() in libqrb5165-io to stop rejecting mode values with flag bits set (or we continue issuing raw ioctls on the fd from voxl_spi_get_fd()).

We consider this less idiomatic than Path 1 — chip select stays a userspace responsibility, with per-transaction GPIO toggling and mode restoration that has to be correct on every error path — and it still requires a custom kernel build. But it is a much narrower diff if that matters for your release process.

Question: is SPI_NO_CS omitted from mode_bits deliberately, for a hardware reason on the GENI controller, or simply because nothing has needed it yet?

What we're asking

Guidance on which of these two you'd support, and whether either can be delivered through an official system image rather than a fork we have to maintain. If neither is practical in the near term, our fallback is a hardware change moving the TMF8829 to its own SPI bus, and we'd appreciate confirmation that a shared bus 3 is simply not supported on this platform so we can commit to that redesign.

Happy to share the arbiter source, the A/B log captures, or a minimal reproducer that only issues the failing ioctl if that's useful.

zauberflote1

Please update your VINS to our master branch here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server

For epoch-synced cams, tracking AR0144, please use:
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server/-/tree/synced-timestamp?ref_type=heads

zauberflote1

@Noah-Heinen
Hello there,

Yes, we haven't officially supported this package for a while, and our development drones currently do not ship STEREO_RAW8 format by default.

However, even though there are no official plans for this repo, I made some changes that should solve the issue for now. This also expands to RAW8 images. Feel free to test it out, this repo will likely become community driven.

zauberflote1

Hello there,

@RoyAzriel said:

2d Lidar 50gram above the gps bridge
2 x light ilumination (front, down - we are flying and dark tunnels next to tracking cameras)
props guards the are seen by the tracking camera
we have added tof camera, moving from C28 to C29 ( currently its not working or wired in sw), we have changed the extrinsix.conf file in /etc/modalai accordingly.
all of those changes did not effect our filght and we had good flight with good vio during the flight

If the platform we are discussing has this added elements, it is a custom frame.

@RoyAzriel said:

we are exploting a tunnel for the first time.we use the poshold durung junction turns to hold in place during turbolance. my answer would be we can live with resets assuming we can accumulate the positions for mapping between the resets.

Yes, so that is a mapping/loop closure software responsibility, not VIO.

@RoyAzriel said:

how do we make sure what you are saying is right and we are passing estimates to px4 ?

Check your voxl-vision-hub.conf, if en_vio is set to true, it passes to PX4 as external vision estimates. Also rectified by:

@RoyAzriel said:

HGT_REF=3 //VIO
EKF2_EV_QMIN=16
EKF2_EV_CTRL=15

For now, our PX4 flavour doesn't handle VIO resets gracefully always. We currently have overcome this issue by using VFC. Hence, the reason I suggested that you should try to repeat the same maneuver under VFC position. If you have any questions on how to enable VFC, please feel free to ask.

@RoyAzriel said:

what should I expect ?

Likely more robust performance under resets at the potential cost of manually hover thrust, PID/PD tuning.

PS: I wanted to try reproducing your setup here with non-modded Starling2 Max, but I am unable to match your setup without logs

zauberflote1

@RoyAzriel Hello there,

This goes back a bit to my first question, but let's break it down systematically:

Do you need VIO estimates to be always continuos or reset jumps are okay?
If you need VIO during takeoff and your application is not robust to SFM resets (potential jump discontinuity), I recommend never using dynamic init and warm reset

Back to what you reported

"still sometimes it fails to converge. Can you recomend what is the best sequence one should do to get convergence in high precentage after power cycle ?"

Convergence for a initialization would usually refer to a dynamic initialization (nonlinear optimization), as the static initialization does not involve optimization. That being said, some static inits can be bad as soon as the platform is in the air: noisy ZUPT updates, bad IMU calibration and sigma/random-walk values. This is natural under custom frame mods, perhaps a full IMU intrinsics recalibration could help.

Nevertheless, it seems that you're running VIO by passing estimates to PX4, instead of using VFC Position (Local Controller with VIO estimates that send just setpoints to PX4). I am personally curious if the issues you're having are related to the PX4 integration with VIO estimates or if it's truly pure VIO estimates.

Experimental Attempt

Please try:

voxl-configure-vision-hub factory_enable_vfc_starling

In the voxl-vision-hub.conf, make sure you verify your hover thrust value and the offboard_mode key is set to vfc
Make sure you change your Position flight mode switch to offboard in PX4
Set a Kill switch in PX4 -- this is an experimental attempt, and you might have to tune the PID/PD values in vfc.conf

If you have logs to share, please feel free to send them.

Q: What is your EV_q (quality minimum) in PX4? Also what your HGT ref?

PS: We are bringing up better VIO debug tools for users, so stay tuned for updates as well.

All the best, ZBFT (Joao Leonardo Silva Cotta)

Zachary Lowell 0

@arvind_g3aero - how many cameras are you running? Can you paste the logs exactly - it is hard to understand the issue without the logs.

As for snapshot - when you change the stream in qgc, the snapshot is probably not tied to the new rtsp steam, causing a fault on the backend - I can look into this at somepoint in the next fwe days.

As for 1.3.5 and 1.4.0 those SDK's do NOT support multi camera streaming into qgc.

Zach

jmltt

Wanted to check in again. Any advice on swapping spektrum RC for ghost atto on voxl2?

ModalAI Forum

Regular

Posts

Setup

The problem

Path 1 (preferred): declare bus 3 with `cs-gpios` and a second spidev child node

Path 2 (fallback): add `SPI_NO_CS` to the controller driver's supported mode bits

What we're asking

Experimental Attempt

Member List

ModalAI Forum

Regular

Posts

Setup

The problem

Path 1 (preferred): declare bus 3 with cs-gpios and a second spidev child node

Path 2 (fallback): add SPI_NO_CS to the controller driver's supported mode bits

What we're asking

Experimental Attempt

Member List

Path 1 (preferred): declare bus 3 with `cs-gpios` and a second spidev child node

Path 2 (fallback): add `SPI_NO_CS` to the controller driver's supported mode bits