There are a couple changes required here that will make this work:

1. Rebuilding Kernel with SPI14 enabled
You're going to have to rebuild and flash the kernel with QUP14 enabled as SPI. There is also a directional level shifter on GPIO67 that needs to be set to high in order for SPI on QUP 14 to work. I created this branch for you that should have the kernel changes that you need:

In order to actually build and flash the kernel please follow the instructions from our public docs on how to build the kernel

When building the kernel, after syncing but before building, make sure to go to the cloned meta-voxl2-bsp directory and checkout the branch that I created (feature/voxl2-mini-spi-qup14).

Also there is a chance you may need to build a kernel variant depending on your device so also make sure to check this document to see if you have a -2 device which would require building the kernel with the -v var02 flag

2. Configuring Trustzone with Correct QUP
I would recommend using the devcfg binary that comes from the `voxl2-mini_SDK_1.0.0.tar.gz. In order to flash devcfg you'll want to run the following command

You should flash the kernel and devcfg (Trustzone) during the same fastboot session to avoid running into any issues with the device booting.

Let me know if you have any additional questions or run into any issues!

Thank you for the clarification.

That makes sense regarding the accel parsing—agreed that a 4 LSB discrepancy on a 20-bit value is negligible compared to in-flight noise, but it’s good to see it will be corrected.

Appreciate you taking the time to investigate and confirm.
Igor

I am working on a Starling 2 / VOXL2 setup and I am stuck with an ESC communication / firmware issue. I would appreciate your guidance on whether this looks like a software mismatch, a known M0129 compatibility issue, or a hardware-side comms problem.

Hardware / platform:

• VOXL2 (M0054)
• Starling 2 platform
• ESC board label: M0129
• SKU shown on device:
  MRB-D0014-4-V1-C27-T9-M22-X0

Current software versions:

• system-image: 1.8.06-M0054-14.1a-perf
• voxl-suite: 1.6.3
• voxl-esc package manually upgraded from 1.5.7 to 1.6.1

What I did:

1. Reflashed the board
2. Restored / checked calibration as needed
3. Verified Wi-Fi and internet access
4. Confirmed newer voxl-esc was available in sdk-1.6 and manually installed:
   dpkg -i /data/voxl-esc_1.6.1_arm64.deb
5. Checked available firmware files under:
   /usr/share/modalai/voxl-esc-tools/firmware/

Firmware files present for M0129:

• modalai_esc_firmware_m0129_3_v39_25_a58f5f6f.bin
• modalai_esc_firmware_m0129_6_v39_25_a58f5f6f.bin

Note:

• My physical ESC only says M0129
• I do not see a suffix like M0129-3 or M0129-6 printed on the board
• I also do not see an m0129_1 firmware file in the installed firmware folder

Main issue:

• voxl-esc scan does not reliably detect any ESCs
• voxl-esc upgrade_firmware sometimes previously said “successfully pinged ESCs” but then failed with:
  [ERROR] Unknown board detected:
• After deeper testing, the underlying Python tools also fail to detect the ESC consistently

Direct tool results:

1. voxl-esc-scan.py

• No ESCs detected at all baud rates
• Sometimes reports:
  ERROR: voxl_uart_read_bytes: Bus '12' is not initialized

2. voxl-esc-board-detect.py

• Ends with:
  ERROR: No ESC(s) detected, exiting.

3. Debug scan:
   Command used:
   python3 voxl-esc-scan.py --enable-debug True --force-scan-all-baud-rates True

Observed behavior:

• UART TX packets are clearly being sent
• No valid UART RX from ESC
• In one case RX was all zeros after:
  ERROR: voxl_uart_read_bytes: Bus '12' is not initialized
• Every scan ends with:
  WARNING: No ESC(s) detected
  ERROR: not all ESCs found

Relevant logs:

• dmesg shows SLPI restart events after reset commands, for example:
  Fatal error on slpi!
  ... Got kill command from apps processor.
• /dev shows SLPI subsystem nodes, but the scan path still fails to get a valid ESC reply

Important observations:

• The VOXL side appears to be transmitting on the ESC link
• The ESC side does not appear to respond
• This now looks more like a low-level comms / wiring / power / bootloader issue than just a wrapper-script issue

Questions:

1. Is system-image 1.8.06 with voxl-suite 1.6.3 a supported combination for Starling 2 + M0129 ESC?
2. For an ESC labeled only “M0129”, which firmware should be used:
   • m0129_3
   • m0129_6
   • or is there another variant / package expected?
3. Is the missing response from the ESC more indicative of:
   • incorrect harness / connector / pinout
   • ESC not powered correctly
   • damaged ESC MCU
   • wrong firmware / bootloader state
4. Is there a recommended low-level recovery path for M0129 when voxl-esc-scan.py cannot detect any ESCs?
5. Are there any additional commands you want me to run to verify the ESC UART / SLPI bridge path on this platform?

Example command outputs:

system image / suite:

• system-image: 1.8.06-M0054-14.1a-perf
• voxl-suite: 1.6.3

voxl-esc version after manual install:

• 1.6.1

Direct scan result:

• WARNING: No ESC(s) detected
• ERROR: not all ESCs found

Direct board detect result:

• ERROR: No ESC(s) detected, exiting.

Any help would be greatly appreciated. I can also provide full logs or photos of the ESC board/harness if needed.

Thank you.

Alex

I am new to developing within the VOXL/Modal software ecosystem. As far as I can tell the recommended workflow for developing apps for VOXL2 is: write app ->cross-compile with voxl-cross or qrb5165-emulator->deploy to hardware and test. My team currently has limited hardware resources. It would definitely speed up our development process if we can validate how our app interacts with the voxl services even if we don't get the same latency as what we would get on hardware. To that end, is there a way to connect qrb5165-emulator, with my app, to the voxl-gazebo docker container? Being able to simulate how the software runs would be hugely beneficial, even if it is at a slower speed than what the actual hardware would give.

1. Do you think starling-2 Max can do the job?
2. The tunnels don't have sufficient lighting, you think I would need led illumination for the VIO to work? do you have addon you offer for illumination?
3. As I understand it you have cameras looking forward and downward, I was thinking of adding a 360 lidar weighing 265 grams. do you think it will help to reach better results?

BR,
Roy Azriel
System Engineer - Rogat

CMake Policy warnings: OV internally (external dir in the repo) still uses boost and references an older cmake version -- it's a harmless warning for devs (as you are building from scratch)

Yaml-cpp lib warnings: This is a third party dependency that gets compiled from scratch during the make/build process. We use C++ 17 but the library is based on an older C++ version; nevertheless, it compiles fine on C++ 17 with minor warnings. -- it's a harmless warning

TrackOCL warning: ModalFlow is a core library written in C++ 17 that allows function call usage as done in TrackOCL, i.e., the narrowing conversion is harmless in this case.

That being said, we are actively working on the dev branch, so all flight--impacting warnings are hopefully caught early. We currently have no flight-impacting warnings/bugs identified, but if you found one warning/bug that caught your attention, please feel free to share.

All the best,
ZBFT

You would need to create a config file /etc/xdg/weston/weston.ini

and try running it manually like this :

a sample config file might look something like this:

We have not tested this yet, but hopefully it's a good start.

Alex

If you have the original adapter for Boson+ which allows you to connect it to a USB port, then you can use the FLIR SDK (we use Boson Plus SDK 4.0). Unfortunately, M0153 board does not have J3 connector populated, which would allow you to connect a serial-to-usb adapter to it.

We have several python scripts, which use the Boson SDK to help set up the Boson sensor without the GUI.

query basic sensor info:
https://storage.googleapis.com/modalai_public/temp/boson/boson_read.py

set up sensor for 8bit MIPI mode, 60fps (option to set 30fps):
https://storage.googleapis.com/modalai_public/temp/boson/boson_set_8bit.py

You can put both of these scripts next to the BosonSDK directory and run them. Please check the USB port name inside the scripts.

Once you get that configured, you can put M0153 back on boson. Regarding where to plug it in on Voxl2, please tell me what other cameras you plan to use with your Boson.

Alex

Does this mean you can create a custom data file partition that you can flash using fastboot?

Yes that is correct.

We have not explored this before but it has been asked a few times. This could be very helpful for other developers.

I'm certainly hopeful that it will be helpful here at Cleo Robotics! So far with my prototyping it works as expected and cuts flashing time of some large docker images we have here at Cleo down by a noticeable fraction (no file overhead via fastboot like with ADB).

I think the snippet I posted covers the baseline functionality of getting a custom "payload" into the data partition. However if there is more I can elaborate on in terms of the toolchain / what's in the payload, and if that elaboration will be helpful to other VOXL2 developers, I would be happy to elaborate 🙂 Just let me know!

Other similar discussion points I tackled recently that I'm happy to talk about lessons of:

Looks the same bug as here: https://github.com/PX4/PX4-Autopilot/issues/22148

Added the change from this commit and it looks like it works now: https://github.com/PX4/PX4-Autopilot/pull/22194/commits/38f3c711084b349cb9ed82cf44ff181c6a40738a

What is the status of voxl-remote-id?

It seems like the current version may be bugged according to this post.

I am using a Starling 2 Max (SKU below) and would be interested in broadcasting RID while being connected to another WiFI network i.e. not in SoftAP mode. As far as I can understand from the remote-id docs page this is not possible as the RID is broadcast over the wifi signal. Is that understanding correct?

family code:   MRB-D0012 (starling-2-max)
compute board: 4 (voxl2)
hw version:    2
cam config:    29
modem config:  24 (M0090-3-2 Sierra EM9291))
tx config:     9 (ghost)
extras config: 0 (none)
SKU:           MRB-D0012-4-V2-C29-T9-M24-X0

Note that if I even try running voxl-remote-id I get the following error:

voxl2:/$ voxl-remote-id
INFO:    Remote ID SN: 1814C1425399169
ERROR: in json_read_file, file is missing: /etc/modalai/voxl-remote-id.conf
ERROR: object missing self_id_message
ERROR:   Could not read in self ID string
ERROR:   Could not read from config file
ERROR:   Failed to fill uas data

Kind regards,
Griffin

We also had our first log of that it occurred again with our forked voxl-mavlink-server. The drone continued its flight now which is good. This is the changed function:

And we got log lines like this:

but I don't yet understand why it is triggering this log because both timestamps seem to be identical. Maybe you have an idea?

Akira

D1 (green) is an indication of the local 3.3V power being Good. So, that implies you have 3.8V input, and the 3.3V reg is OK.
DS2 (RGB) is controlled by Qty-3 GPIOs from the SoC. This can briefly blink on boot until the GPIOs are configured by apps software.
D2 (green) is the 5V USB VBUS USB1 (10-pin) port power indicator, which only comes ON after the QRB5165 boots and Apps controls the GPIO to turn the VBUS ON.

On failed SW loads, it is common to diagnose that by seeing DS2 or D2 blink, which indicates boot loops. D1 should NEVER go off, if so, something is wrong in HW or cabling.

We do caution any customer that sets up their own CI or internal validation automation to include a nice pause before repeated power cycles. A common 5 second rule is good to let the large caps discharge, or certain ICs will never fully reset. This is the most common cause of "bricking" devices.

The RMA is your best bet here and we can try to recover them for you, or diagnose for any other issues: https://www.modalai.com/pages/rma

Choose Option 2 if you are using the camera board
3a551368-4c35-4edd-8f0d-09b2f6cd47da-image.png