Hi @Alex-Kushleyev,

Thank you for the detailed explanation regarding the Starling 2 payload margin and the thrust-to-weight considerations. The breakdown is very helpful for my design trade-off.

I would like to ask one follow-up regarding the Stinger FPV. In my application, flight endurance is not the primary constraint, so the shorter flight time compared with Starling 2 is not necessarily a blocker. Durability, compact size, and the ability to carry a small external sensor package are more important for this specific use case.

With that in mind, could you please provide a similar payload-oriented assessment for the Stinger FPV?

Specifically:

What is the typical all-up weight of a standard Stinger FPV configuration, including battery? What is the approximate maximum thrust per motor? Using the same recommended minimum thrust-to-weight ratio of approximately 2.0 for good controllability, what additional payload margin would you consider practical? Are there recommended mounting areas or structural points on the Stinger frame for small external payloads? Are there any known limitations compared with Starling 2 regarding payload mounting, center-of-mass sensitivity, or PX4 attitude-controller tuning? For an indoor application where flight time is less critical, would you generally consider Stinger FPV a better candidate than Starling 2 for carrying a small external sensor package, or would you still recommend staying with Starling 2?

At this stage, I am trying to make a platform selection between Starling 2 and Stinger FPV before freezing the mechanical layout. Once I understand which platform has the more suitable payload margin and mounting flexibility, I can share the planned sensor list, estimated added mass, and CAD/mounting concept for your review.

Thanks again for the support.

Best regards,
Eyal

That pink hue usually ends up being related to white balance or ISP tuning rather than the sensor itself. I’ve also seen it happen under certain lighting conditions where the auto settings overcompensate a bit.
Might be worth checking the raw output vs processed output to narrow it down. If the RAW image looks fine, then it’s probably somewhere in the color pipeline.
Also, for comparing the tint between frames, I’ve used https://colorpickerimage.org/ before to inspect the actual RGB values in different areas of the image. Makes it easier to confirm whether the pink cast is consistent or only affecting highlights/shadows.

Adding more cameras can definitely improve robustness, but synchronization and calibration become super important once you go beyond the default setup. Even small timestamp offsets between sensors can throw VIO off pretty badly. I’d also keep an eye on bandwidth and CPU usage because extra camera streams add up fast on embedded systems.

Hello @Mason-N ,

Going back in git history, I was able to find the seeker documentation. I think this is what you are looking for:

https://gitlab.com/voxl-public/support/documentation/-/tree/530dadd6fb9d50654ea34496c3d7f02d142fd732/docs/20-dev-drones/45-seeker

b3db5b4a-0830-4b38-99fe-4b8574a52505-image.png

https://gitlab.com/voxl-public/support/documentation/-/tree/530dadd6fb9d50654ea34496c3d7f02d142fd732/docs/20-dev-drones/45-seeker/10-seeker-user-guide
1935f458-67ae-4c9d-8f34-1b140e52928c-image.png

@mkriesel It's possible the kernel you're flashing is incorrect. Can you provide the full terminal output of the install?

Hi Cbay,
There is a small clock buffer on the edge of the PCB. An RMA can only replace the whole board, not replace a single device. The part to check would be here: image (1).png

@Eric-Katzfey
I'm not sure what may have changed, before when setting BATT_MONITOR to 21 the param would write but we wouldn't get the additional parameters that that setting should have enabled. Last week I tried it again to reply to your last message and we got the BATT_I2C_BUS parameter and were able to get it all working. Gotta love when things seem to magically fix themselves, thanks for the support.

PS, we have built a parallel system on the latest SDK and will be migrating the current one over to match.

@RoyAzriel ,

you can back up your voxl-camera-server.conf and then run voxl-configure-cameras 29 and the following will happen:

all the existing sensormodule files will be wiped from /usr/lib/camera to avoid confusion only those sensormodules that belong in C29 config will be copied from /usr/share/modalai/chi-cdk to /usr/lib/camera the camera server config file (/etc/modalai/voxl-camera-server.conf) will be overwritten with the defaults for C29 configuration -- you can then see the config entry for TOF sensor and copy/paste that into your old config file, if you wish or use the new config file as is.

Alex

@chinlee5 Which drone do you have? Which versions of software are you using? Are those messages appearing on QGC? Also, do not try to arm the drone or fly the drone while attached to a power supply. Only use a battery for that. If you take the drone outside with a full view to the sky so that GPS can acquire satellites do the messages go away?

You might also want to double check the current rating of the power module versus the full load from your setup. A lot of weird reboot or brownout issues end up being power related, especially once extra peripherals get added. Keeping the wiring short and using a stable regulator helps too.

@Eric-Katzfey I’m looking for the voxl-emulator Docker image referenced in the documentation:

VOXL Emulator Documentation: https://docs.modalai.com/voxl-emulator/#install-the-voxl-emulator-docker-image

However, in the Development Sources / Developer Portal there doesn’t seem to be any Docker image available for voxl-emulator.

Could you please confirm if the image is still available, or if there is an updated download location for it?

One thing that helped me before was comparing the device tree and driver setup against an already supported sensor with similar specs. A tiny mismatch in clocks or I2C config can stop the sensor from initializing properly.

Thanks @Eric-Katzfey ! Here is the pinout for the dev board "UART" port that includes i2C_SCL and I2C_SDA.

0cda71eb-2c0f-4b1b-ba91-8b3862fc9763-image.png

The dev board pins 1-6 matching to J19 pins 1-6

We will give the COMPASS_DISBLMSK parameter a shot and see if that works.

Hello @Gerhold-Ten-Voorde ,

This is not related to the quality, but instead, it is a supply chain decision.

Alex

@Alex-Kushleyev Thanks for the follow up and working towards the calibration map. For us the real time processing speed doesn't matter too much, but the image file size does as we need to send the unprocessed images over radio in real time. We were hoping to use voxl-record-raw -j -q 90 as this doesn't show the vertical artifact and results in reasonable file sizes.