Using Loco deck and Lighthouse deck together on Crazyflie 2.1 Brushless — current status of the pin conflict?

[khajababa1139]

Hi,

I'm setting up UWB & TWR where I need the Loco deck ranging while the Lighthouse deck provides pose as primary source. UWB will be passive throughout Lighthouse does the flight control. So I need both decks live on the same Crazyflie at the same time.

From what I can find in the docs, the deck-to-deck compatibility matrix still marks Loco × Lighthouse with footnote 3 ("Could be patched using soldering bridges or can be supported in the future, SW update"), and the pin allocation table shows both decks on RX1/TX1, with Loco's alternates (IRQ) on IO_2 and (RST) on IO_3.

The most concrete instructions I've found are issue #663 (LOCODECK_USE_ALT_PINS, deck modified via the available soldering pads) and the hyperdemo blog post (IRQ to IO_2 via solder-jumper, RST to IO_4 via patch wire — though that used IO_4 only because a Flow deck occupied IO_3, which doesn't apply to me).

Three questions:

1. Is the hardware modification still required as of the current firmware, or has anything changed?

2. On the Loco deck Rev D, which jumper designators are which? The schematic shows GS1–GS4 on P1 with the note "By default IRQ/RST is on UART1," but I can't tell from the schematic PDF which designator sits on which pin. Are GS1/GS2 the UART1 defaults and GS3/GS4 the IO_2/IO_3 alternates?

3. How are the defaults connected? On my deck the default jumpers don't look like solder blobs. Are they bridged with a hairline trace that needs cutting, or is there a 0 Ω resistor to lift? I'd rather know before I go near it with a blade. A photo of a correctly modified deck would be enormously helpful if anyone has one.

Since I only have Loco + Lighthouse (no Flow deck), I believe IO_3 is free and the plain LOCODECK_USE_ALT_PINS flag should be enough without LOCODECK_ALT_PIN_RESET. Is that right?

Hardware: Crazyflie 2.1 Brushless, Loco deck, Lighthouse deck, mounting Loco underneath and Lighthouse on top.

Thanks!

[ArisMorgens]

Hello @khajababa1139!

Sounds like an interesting project!

In order to make the 2 decks work together, the hardware modification on the Loco deck is still required. Here's a picture of what it should look like.

Note that hardware modifications is not something we recommend, as it can damage your board.

Regarding the firmware modification, you're probably right about the IO_3 pin but I can't test it right now. You can use make menuconfig and navigate to Expansion deck configuration -> Deck drivers to enable the alternative options for the loco deck. Then, you need to build the firmware and flash it to your platform.

From our experience, using both decks with multiple Lighthouse base stations and Loco anchors can overload the Crazyflie. One solution that worked well was to reduce the maximum lighthouse samples that the Crazyflie uses. We experimented with setting it around 15 and the Crazyflie performance was almost the same.

Let me know if you have any questions and good luck with your project.

[khajababa1139]

Thank you @ArisMorgens, the photo is exactly what I needed — that settles the jumper question completely. I'll follow it and verify with a multimeter afterwards (IRQ↔IO_2 closed and IRQ↔RX1 open, same for RST↔IO_3 / TX1) before powering anything up. Understood on the risk of hardware modification.

Two follow-ups, and some detail on my setup that I think changes the overload picture:

1. My load may be lighter than the case you tested

A few things about my configuration:

• Only two Lighthouse V2 base stations (5 m apart, ~2 m high, different channels)
• UWB strictly in TWR mode, not TDoA
• UWB is completely passive. I dont need any range measurement to ever reache the Kalman filter. The estimator is fed by Lighthouse alone. I only need the raw range logged out over radio for offline analysis.

This is deliberate — I'm validating UWB TWR against Lighthouse as ground truth, so if UWB fed the estimator the pose I compare against would be partly a product of the measurement I'm evaluating, and the bias I'm trying to characterise would be partly absorbed by the filter.

Since the throttle exists to limit the sample rate reaching the estimator, and my estimator only sees Lighthouse from two base stations, I suspect I may sit below the 50 samples/s default and the throttle would be inert. Is that a reasonable read?

One thing I'm less sure of: I'll still be running the TWR state machine at full rate (~272–320 Hz to a single anchor) plus roughly 150 CRTP log packets/s. That load exists whether or not the estimator consumes the ranges. In your experience, was the overload you saw driven by the estimator update rate specifically, or by the deck driver and radio load underneath it? That determines whether the throttle is the right lever for my case at all.

2. Can overload cause physical damage?

If I do push the system too hard — high log rates, both decks active — is there any risk of physical damage to the STM32 or the decks, or does it fail purely as degraded behaviour (dropped packets, missed deadlines, watchdog reset, estimator divergence)? I'd like to explore the throughput limits deliberately to find where they are, and I want to know whether that's a software-safe experiment or something that can cost me hardware.

3. Common coordinate frame — is tape measure plus a software transform enough?

For the comparison to mean anything, the Lighthouse frame and the LPS anchor frame have to be expressed in the same global frame.

My plan is to survey the anchor positions by tape measure relative to the Lighthouse origin, enter them via lpp anchor position packets, and apply any residual rotation/translation offline.

Two questions there:

• Is there an established workflow in the Bitcraze tooling for aligning the LPS anchor frame to the Lighthouse frame, or is offline alignment the expected approach?
• Does the Lighthouse geometry estimation define its origin in a way that's stable enough to survey anchors against — i.e. if I re-run the geometry estimation later, does the origin move?

Thanks again for the photo and the throttle pointer, both very helpful.

[ArisMorgens]

Hello @khajababa1139!

I'll do my best to answer you questions.

Since the throttle exists to limit the sample rate reaching the estimator, and my estimator only sees Lighthouse from two base stations, I suspect I may sit below the 50 samples/s default and the throttle would be inert. Is that a reasonable read?

From my understanding, the throttle doesn't only stop the samples from reaching the estimator. It also reduces the samples used in the geometry solve. With just 2 base stations you get less samples, so you might be right that you're not hitting the maxRate of 50 samples/second. I would recommend skipping the throttling for now and perform some tests where you place the Crazyflie within the flight area with both decks attached, receiving as many base stations and anchors as possible.

One thing I'm less sure of: I'll still be running the TWR state machine at full rate (~272–320 Hz to a single anchor) plus roughly 150 CRTP log packets/s. That load exists whether or not the estimator consumes the ranges. In your experience, was the overload you saw driven by the estimator update rate specifically, or by the deck driver and radio load underneath it? That determines whether the throttle is the right lever for my case at all.

The "overload" I was talking about didn't happen in the estimator. This was the assert error:

crazyflie-firmware/src/hal/src/radiolink.c:171

This explained why the problem was "solved" by reducing the lighthouse samples early on, and not by preventing them from reaching the estimator, using this parameter. Btw, for your application, you could use this parameter to stop pushing loco measurements into the estimator.

2. Can overload cause physical damage?

From my experience, when the system encounters a hard error, it will assert. The main concern is that these asserts could happen mid-flight, causing the Crazyflie to simply drop from the sky.

Is there an established workflow in the Bitcraze tooling for aligning the LPS anchor frame to the Lighthouse frame, or is offline alignment the expected approach?
We don't have an established workflow for aligning the 2 positioning systems yet. It has proven to be a hustle to first set up the Lighthouse system and then measure the distance of every anchor from the origin. That said, here are 2 options that worked better for us:

1. Set up both systems independently, making sure their axes are parallel. Then use this experimental tool I created for shifting one of the systems to match the other one.

2. Start by setting up the Loco positioning system. Take a Crazyflie that is using only the loco measurements and physically mark 2 points: the origin and the 1m forward on the positive x-axis of your system. Using a Crazyflie that is using only the lighthouse measurements, estimate the geometry of the Lighthouse system using the 2 marked points.

I hope this helps. Don't hesitate to reach out if you have further questions.