ModalAI Forum

jmltt

@Eric-Katzfey We're using Crazyswarm2 for now with a motion capture system for positioning

jmltt

I have a set of Sentinels and a set of Crazyflies. I like the Sentinels for the onboard compute, sensor suite and all the built-in functionality that comes with the voxl SDK, but I've found it difficult to manage networking multiple together and managing as swarms.

The crazyflies are obviously less robust, but they're cheaper and much easier to scale swarms of because of the existing open source swarming software packages.

I was just curious if ModalAI has ever looked at producing a more swarming-oriented platform. Something like a scaled-down version of Starling 2 with more scalable networking options. Seems like a hole in the NDAA-compliant UAS market. It's easier for us to purchase COTS systems than build our own so I just wanted to see if that would be a potential option on the horizon or if ModalAI is sticking to single agent mission-type platforms

Zachary Lowell 0

Hi! Planning on testing and getting into the weeds of this tomorrow to see if I can recreate and provide proper answers for this!

Zach

Rowan Dempster

@Vinny Hi Vinny, no worries we are going to change the electronics so that the other SPI device talks over SPI bus 11.

Adrian Hidalgo

@Colby-Howell New order# 8874.

Adrian Hidalgo

@Colby-Howell

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.

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

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

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