ModalAI Forum

Hello @nostrain

Please take a look at the ESC firmware changelog:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/firmware/FIRMWARE_CHANGELOG.md

• support for the M0138 FPV ESC has been added in firmware V39 RC10, which is likely what you received (i assume the ESC is reasonably old, since we are now shipping with latest firmware)
• please note that only starting version V39.15, the ESC firmware sends back the exact version in format Vxy.ab -- so 39.00 could mean 39.10-39.15
• also note that the firmware hash that you have (e4f576a0) is not listed in our firmware changelog, but it is essentially the V39 RC10 release (39.10).

We will look into the changes. To help with this, are you able to share the approximate motor specs? (motor kv and what supply voltage you are using)? We can try to replicate.

Are you able to test the firmware from this release and tell me how it behaves? https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/tree/366d652e3680bb769d87dfca94f76b226481a6db/voxl-esc-tools/firmware . Initially we had a few releases that were not documented in the changelog (v0_39_RC10_a7f0bccb)

Thank you

Alex

@sebastianp , sorry for the delay. There a lots of questions, let me start with what I can answer right away and will go from there.

1. Hires Video

Resolution:

• Starling 2 Max comes with dual IMX412 cameras (front, down-facing). IMX412 maximum resolution is 4056x3040, which is larger than 4K. 8K is not supported on Starling Max. In general, we do have support for one 8K camera (OV64B), which has maximum resolution of 9248x6944 and that resolution is supported only at 10FPS. The only way to get that camera right now is part of a Flir Hadron combo (Boson + Color camera), which is probably not what you are looking for. So the best bet for Starling 2 Max is to use the provided IMX412 camera.
• you can see some details regarding operating modes of IMX412 camera here : https://docs.modalai.com/camera-video/low-latency-video-streaming/#imx412-operating-modes

Data Pipeline:

• our camera server application (voxl-camera-server) can publish processed YUV images via shared ION buffers (zero copy) and the user application can receive those buffers for processing without any cpu overhead for doing inter process communication to send the image data.
• you can also publish raw Bayer data (the exact data that comes from the camera) if that's what you mean by "raw"

Optics:

• no optical zoom is supported on any of our cameras, only digital

2. Onboard AI Compute and Performance

• I will need to check with colleagues and follow up.

3. Flight Range, Autonomy & Control

• Starling 2 Max used PX4 as flight controller, so all the standard flight modes are supported

Answers to additional questions

• Camera and Zoom integration: yes, raw and yuv frames can be shared with customer's C/C++ applications via shared buffers (or regular buffers via named pipes, which will have a lot of overhead for duplicating the data). No optical zoom is supported. Examples are available upon request
• We provide voxl-cross docker image which can be used to build the projects for VOXL2. Majority of ModalAI packages that run on VOXL2 are built using this cross-complier environment and can serve as examples how to build your own applications (you can find most packages here : https://gitlab.com/voxl-public/voxl-sdk)
• you can mount more hardware on Starling 2 Max, see the following thread regarding flight time : https://forum.modalai.com/topic/3732/starling-2-max-payload-capacity-and-flight-time-impact

Frequency selection

• when you configure your starling 2 max (https://www.modalai.com/products/starling-2-max) , you can select several options and the SKU will change accordingly. The page also has explanation for the different SKU options, so it sounds like you will need:
• MRB-D0012-4-V4-C28-M11-T9-K2
• C28 : dual tracking and dual hi-res cameras
• M11-T9 : Microhard and Microhard pMDDL2450 and Ghost Atto (2.4Ghz)
• it seems that this would be a custom SKU that you would need to request a quote for : https://www.modalai.com/pages/contact-us

Ground Controller:

• If the drone ships with an RC transmitter, it should be already bound to the receiver.
• the controller and receive depends on the selection, see above regarding SKU and the shop page for more description
• note that the RC controller has no ability to display video, so there is no out-of-the-box ability to stream video without additional setup, such as external computer, display / goggles, etc.

I hope that answered a lot of your questions, please let us know additional questions or need clarification regarding anything else.

Alex

@royazriel ,

We do not recommend doing apt upgrade, since we do not test this update method. If you want to update the SDK, you should do that following our SDK install instructions.

As an advanced user, you may select to update your apt sources to use dev releases (basically latest dev branches) and selectively install packages that you want to test.

The recommended SDK release for Starling 2 (Max) is 1.6.4

With that in mind, please let us know if you have any more questions about this.

Alex

OK, thanks for checking. maybe there was a typo before

@nickanick ,

Now that the main issue is resolved.. i am confused why the following test command did not work for you :

./voxl-esc-spin.py --id 255 --power 0

The screenshot you posted had the command cut off -- are you sure you used the correct command? 255 is a special value that should spin all 4 ESCs: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/voxl-esc-spin.py?ref_type=heads#L190

Can you check if the voxl-esc-spin.py script on your VOXL2 is the same as this file?

Thanks!

Alex

@zaimin78 ,

It looks like I got this working. I modified the kernel to do the following

• not use the combo mode for J6L and allow using J6U as independent camera
• GPIO109 is used as a shared reset for cameras in slot 1 and 3 (because that's how the signal routing works on VOXL2 + M0135), so the kernel knows that this reset pin is shared
• this setup is not set up for camera sync - all cameras are running independently
• I have not tested any cameras in J8U, it may not work - but it should be possible to enable it, just need to test it.

You will need to update the kernel on your voxl2:

• https://storage.googleapis.com/modalai_public/temp/quad_ov7251_boson/qti-ubuntu-robotics-image-m0054-boot-quad-ov7251.img
• this kernel is based off the kernel that ships with SDK 1.6.3
• you can test it before overwriting the current kernel: https://docs.modalai.com/voxl2-kernel-build-guide/#test -- you should do to reduce the chance of bricking your VOXL2 (just in case)

HW Configuration:

• VOXL2
• four OV7251 plugged in to J6L. J6U, J7L, J7U via two M0135 adapters without any mods
• boson320 plugged into J8L via M0194 (you can use M0181 also)
• there are no shared CCI buses between the ov7251 cameras - slots 0-3 use CCI 0-3 respectively, so no CCI slave address conflicts

SW configuration

• appropriate sensormodules placed into /usr/lib/camera/ -- you can get them from /usr/share/modalai/chi-cdk/ov7251 and ../boson folders:

com.qti.sensormodule.ov7251_0.bin
com.qti.sensormodule.ov7251_1.bin
com.qti.sensormodule.ov7251_2.bin
com.qti.sensormodule.ov7251_3.bin
com.qti.sensormodule.boson_4.bin

• use provided voxl-camera-server.conf : https://storage.googleapis.com/modalai_public/temp/quad_ov7251_boson/voxl-camera-server-quad-ov7251-boson.conf
  • may need to modify your Boson resolution from 320x256 to 640x512 if you you have Boson640

Testing

• after you have all the cameras connected, boot using the test kernel
• test to see if all cameras are detected:

voxl-camera-server -l
...
DEBUG:   Cam idx: 0, Cam slot: 0, Slave Address: 0x00E2, Sensor Id: 0x7750
DEBUG:   Cam idx: 1, Cam slot: 1, Slave Address: 0x00E2, Sensor Id: 0x7750
DEBUG:   Cam idx: 2, Cam slot: 2, Slave Address: 0x00E2, Sensor Id: 0x7750
DEBUG:   Cam idx: 3, Cam slot: 3, Slave Address: 0x00E2, Sensor Id: 0x7750
DEBUG:   Cam idx: 4, Cam slot: 4, Slave Address: 0x00D4, Sensor Id: 0x00FF
...

• start voxl-camera-server
• inspect sterams: voxl-inspect-cam ov7251_0 ov7251_1 ov7251_2 ov7251_3 boson
  

Please give it a shot and let me know if it works!

Alex

What i meant was that sometimes, depending on the frame design, the orientation of the cameras may change slightly over time. This can happen as the plastics can change shape due to exposure to heat, sunlight, humidity (depends on the plastics), bumps and crashes, etc.

Additionally, there has been some research showing that the camera + lens intrinsics change over time / temperature, especially if the lenses are made of plastic (which is the case in our old OV7251-based fisheye modules, which use plastic lenses - although we have not characterized them vs temperature).

It is possible to use stiffer and more stable materials (metals, carbon fiber) to ensure that the sensor mounting remains consistent over time.

I hope that answers your questions.

Alex

Thanks for your patience, I will try to test this today.

@nickanick ,

Here is some background..

The Mini ESC (M0129) and the FPV ESC (M0138) do not have individual channel current sensing (unlike M0134 ESC), so the individual ESC channel current is reported as 0, while each ESC channel still reports the measured voltage in the standard telemetry packet sent to the FC. For these two ESCs (M0129 and M0138), one of the ESC channels measures the total board current that flows through the ESC and sends out a second telemetry message with just voltage and total current. For M0129, the ESC channel 3 does this, and for M0138, channel 2 (0-indexed).

The telemetry messages are sent from the ESC to the FC (VOXL2) via UART and is parsed in the PX4 in voxl-esc driver. In the voxl-esc driver, if the battery status telemetry message is received from the ESC and VOXL_ESC_PUB_BST is enabled, then the driver will publish the battery_status topic with the battery voltage and current from the ESC telemetry message.

In order to do a quick test to make sure the ESC is sending out the battery status, you can do the following:

• stop px4 : systemctl stop voxl-px4
• test the ESC using voxl-esc tools (note that these tools are not part of px4):

cd /usr/share/modalai/voxl-esc-tools
./voxl-esc-spin.py --id 255 --power 0

Note that you will be running a spin test command (take off props for safety!), but the command is 0, so the motors will not spin, but you will see the telemetry from the ESC being printed in the terminal on voxl2. You will seeBOARD_VOLTAGE and BOARD_CURRENT being reported and that is coming from the extra telemetry message from the ESC. If you see this current printed, then the ESC is sending the correct information.

The argument --id 255 will tell the test script to communicate with all 4 ESC channels and the commands will be sent and telemetry requested from all 4 ESC channels (including the channel that sends back the battery status telemetry message).

Can you please check this?

voxl2:/usr/share/modalai/voxl-esc-tools$ ./voxl-esc-spin.py --id 255 --power 0
Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00) 
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.9
VOXL Platform: M0054
Detected RB5 Flight, VOXL2 M0054 or M0104!
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
Sending library name request: libslpi_qrb5165_io.so
Sending initialization request
INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 2000000
	ID         : 0
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555313000F0036
	Firmware   : version   39, hash 9c6233d6
	Bootloader : version  184, hash 10bf24c8

	ID         : 1
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555313000F0032
	Firmware   : version   39, hash 9c6233d6
	Bootloader : version  184, hash 10bf24c8

	ID         : 2
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555313000F0034
	Firmware   : version   39, hash 9c6233d6
	Bootloader : version  184, hash 10bf24c8

	ID         : 3
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555313000F0038
	Firmware   : version   39, hash 9c6233d6
	Bootloader : version  184, hash 10bf24c8

---------------------

WARNING: 
This test requires motors to spin at high speeds with
propellers attached. Please ensure that appropriate
protective equipment is being worn at all times and
that the motor and propeller are adequately isolated
from all persons.

For best results, please perform this test at the
nominal voltage for the battery used.

Type "Yes" to continue: yes
[0.015] (0) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A
[0.015] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.24C, CURRENT: 0.000A
[0.015] (2) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A
[0.015] (3) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A
[0.036] (0) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A
[0.036] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.24C, CURRENT: 0.000A
[0.036] (2) RPM: 0, PWR: 0, VOLTAGE: 16.059V, TEMPERATURE: 38.85C, CURRENT: 0.000A
[0.036] (3) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A
[0.059] (0) RPM: 0, PWR: 0, VOLTAGE: 16.039V, TEMPERATURE: 38.22C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.059] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.24C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.059] (2) RPM: 0, PWR: 0, VOLTAGE: 16.059V, TEMPERATURE: 38.85C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.059] (3) RPM: 0, PWR: 0, VOLTAGE: 16.047V, TEMPERATURE: 38.86C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.075] (0) RPM: 0, PWR: 0, VOLTAGE: 16.039V, TEMPERATURE: 38.22C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.075] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.23C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.075] (2) RPM: 0, PWR: 0, VOLTAGE: 16.065V, TEMPERATURE: 38.89C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.075] (3) RPM: 0, PWR: 0, VOLTAGE: 16.047V, TEMPERATURE: 38.86C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A
[0.101] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.19C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.101] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.23C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.101] (2) RPM: 0, PWR: 0, VOLTAGE: 16.065V, TEMPERATURE: 38.89C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.101] (3) RPM: 0, PWR: 0, VOLTAGE: 16.041V, TEMPERATURE: 38.91C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.119] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.19C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.119] (1) RPM: 0, PWR: 0, VOLTAGE: 16.054V, TEMPERATURE: 38.23C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.119] (2) RPM: 0, PWR: 0, VOLTAGE: 16.060V, TEMPERATURE: 38.88C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.119] (3) RPM: 0, PWR: 0, VOLTAGE: 16.041V, TEMPERATURE: 38.91C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A
[0.137] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.25C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A
[0.137] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.22C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A
[0.137] (2) RPM: 0, PWR: 0, VOLTAGE: 16.060V, TEMPERATURE: 38.88C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A
[0.137] (3) RPM: 0, PWR: 0, VOLTAGE: 16.043V, TEMPERATURE: 38.90C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A
[0.156] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.25C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A

@patkirkmartin , let me double check with the team what the process for this will be and the timeline. I will get back to you soon.

Since the plan would be to provide the source to the public, it would be posted on gitlab, the feature-related discussion can happen there. We will certainly be able to help review the code and perform some testing.

Alex

Starling 2 Max is designed for 4S batteries only (two 2S Li-Ion battery packs, which are connected in series inside the vehicle). The Mini ESC, which also acts as a power source for VOXL2 inside the Starling 2 Max, is rated at least for 4S input (depending on the version of the ESC).

There are several versions of the Mini ESC to provide the users some flexibility, in particular the voltage of the VOXL2 regulator (5V for VOXL2 and 3.8V for VOXL2 Mini). Since Starling2 Max uses a VOXL2, the ESC part number will be either M0129-5 or M0129-65.

An updated (6S) version of the Mini ESC was released after the release of Starling 2 Max (new ESC part numbers: M0129-63, M0129-65). This ESC update extended the supported voltage for the ESC (not for Starling 2 Max) from 4S to 6S. The 4S version of the ESC has been phased out because the 6S version outperforms the original version even at 4S voltages (due to better Mosfets), so the 6S version is an improvement over the original 4S version of the ESC, while being fully backwards compatible.

Using the 6S-rated ESC in the 4S-rated Starling 2 Max is completely safe.

If you use the Mini ESC outside of the Starling 2 Max, you need to verify the part number / sticker on the ESC before plugging in 6S battery (M0129-63, M0129-65 only)

The ESC variants and part numbers are documented here : https://docs.modalai.com/voxl-mini-esc-datasheet/

Alex

Hello @patkirkmartin , thanks for clarifying.

Just to give you some more background and the reason for my questions: we have previously experimented with enabling DSHOT output using VOXL2 IO board and it worked during testing. However, due to lack of need and time to properly test and release, the feature was never mainlined. Also, we tested receiving the telemetry via UART only (which some DSHOT ESCs support) - had to hijack a UART port on the voxl2 io board for that.

Further developing the (bi-directional) DSHOT on the voxl2 io board is currently not on our roadmap, however if you we willing to do your own code development for the voxl2 io board, we can look into releasing the source code for it (together with the initial DSHOT output implementation).

VOXL2 itself is not capable of outputting the required DSHOT signals.

Alex

Hello @patkirkmartin,

If you are using our ESC with a new motor / prop, you need to perform a one-time ESC calibration and upload the new ESC params using the voxl-esc tools. Please see : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md

If the motor kV is relatively low (less than 800), you may need to take a look at this as well : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/low_kv_motor_tuning.md

It sounds like your de-sync is right during spinup - make sure that you are using sinusoidal spin-up and that also needs to be tweaked for best performance (only a few parameters like spin-up power and time).

• https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md#tune-the-motor-spin-up
• https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/low_kv_motor_tuning.md?ref_type=heads#spin-up-parameters-for-low-kv-large-motors-it-is-better-to-use-sinusoidal-spinup

If you would like to provide more details about the motor / prop / voltage, we can try to provide more guidance.

Alex

Also, please keep in mind that the OV7251 cameras have been EOL for a while and are not recommended for a new design (actually it looks like we have no stock at the moment). It seems that you already have the cameras, so we can certainly give this a try.

Hi @zaimin78 ,

First let me answer your questions about OV7251. The are two issues that need to be resolved in order to use the 4th ov7251:

• re-build the Voxl2 Kernel so that the port J6 is set up for two independent cameras in J6L and J6U instead of only supporting a single camera in J6L or a "combo" sync'ed cameras (via a stereo flex). A combo mode (in the ISP) works by using one 4-lane CSI interface to receive data from two 1-lane cameras. The default Kernel configuration is set up this way and basically the hardware mapping (which is configured in software) does not work for an independent camera in J6L. This change is relatively easy, I would need to re-build the kernel and test.
• second issue to check is to make sure that the IO pins used for camera control (power on/off), etc does not conflict with the other cameras. ports J6U and J8U have some common pins that could make the cameras in those ports interfere. However, in the current set up, you would not have any cameras in J8U, so the issue may not be present.

I am going to check the second issue first before doing the work to re-build the kernel with updated Device Tree (wit the camera IO and CSI mappings).

Now, regarding other options.. Have you looked into our AR0144 cameras (part number M0166): https://www.modalai.com/products/msu-m0166 . It has a diagonal FOV of about 160 degrees, as stated in our camera module spec sheet. This is the primary camera type we use now for VIO applications (monochrome, global shutter). Note that these cameras do not use flex cables like the EOL camera ov7251. We are now using uCoax type of camera cables and it also means that you would need to use a different interposer to connect the cameras to voxl2. Specifically, you would use M0173 camera front end. Several users have asked about connecting 4 AR0144 cameras this way, please check the forum for the discussion.

• https://forum.modalai.com/topic/4491/ar0144-rgb-output-on-voxl2/
• https://forum.modalai.com/topic/5233/ar0144-on-voxl2-j8-or-alternative-4x-ar0144-config
• (there is actually another option, if you don't need a hi-res camera plugged into M0173), all 4 AR0144 can be plugged into M0173, but the i2c slave id would still need to be changed for one of the AR0144 via a resistor swap.

So if you wanted to switch to the AR0144 cameras, you would most likely have to use

• M0173 camera front end (which uses voxl2 J6 and J7) with 4 AR0144 cameras plugged in (one with i2c id change)
• the Boson would be plugged in to voxl2 J8 via M0181

Please let me know which route you would like to explore.

Alex

Hello @jameskuesel ,

Sorry for the confusion about the lens change. Please see the details below.

The original lens in the IMX412 modules (M0107 and M0161) had manufacturing issues where the internal components of the lenses were loose and vibrating in flight, causing shaky video.

Due to quality / vibration issues of the original lens (part number M10000580) shipping with IMX412 (M0107 and M0161) modules, the default lens was changed to M10001028 (late 2025). However the new lens does have much narrower FOV. When purchasing the standalone camera, you have a choice of lens:

M0161 with old lens (wide) : MDK-M0161-1-07 (3.1mm EFFL, M10000580 lens)
M0161 with new lens (narrow) : MDK-M0161-1-08 (3.24 EFFL, M10001028 lens)

It seems that there maybe some discrepancy in the manufacturer stated EFFL for the new lens (3.24 vs original 3.1) because the actual FOV change is more significant than the change in the effective focal length would result in. We are looking into this.

Starling 2 and Starling 2 Max drones are currently shipping with the new lens (narrow FOV).

We do currently have stock of the old (wide) lenses that should have no issues (according to the manufacturer), however we cannot provide any guarantees for this lens due to past history of issues. If you would like to update your drone / camera with the original wide lens, please contact us and we will make it available for you to purchase (lens part number M10000580).

Alex

Sorry for being very specific.. but there are two types of telemetry you can get from DSHOT-capable ESCs.

• UART telemetry : the four ESCs send telemetry one at a time over a dedicated UART line, which can be fed into standard UART RX
• DSHOT telemetry is sent from each ESC over the PWM lines (all at the same time) and do not use UART. The FC hardware as to change the PWM outputs to inputs while receiving telemetry (requires tight timing)

So, do you have a requirement to use one or another.. or which specific fields in the telemetry are you looking for?

Alex

Hello @zaimin78 ,

Without any changes, you can have 1 Boson and 3 ov7251 only. I would suggest connecting Boson to J8, so that the mounting tab on the M0181 aligns withe the VOXL2 mounting hole. So you would have:

• J6L : slot 0, cci bus 0 : ov7251
• J7L : slot 2, cci bus 2 : ov7251
• J7U : slot 3, cci bus 3 : ov7251
• J8L : slot 4, cci bus 1 : Boson

In order to connect the 4th ov7251 (it would go to J6U, via M0135), you would need a device tree change in the kernel (need a different kernel).

Also I need to double check to see if any other signal routing changes would need to be made (on M0135).. Let me get back to you soon.

Alex

@mrawding , I am sorry, but it looks like we are not going to be officially supporting Ubuntu2.0 Kernel on VOXL2, as we are working on enabling next gen hardware.. We did start the effort but it is not going to be finished for the general availability for VOXL2.

Alex

@PatkirkMartin,

I will pass on your note about the order to our team.

Regarding DSHOT, can you please clarify which features are a must-have for your application? specifically, do you need both DSHOT control (lets say Dshot600) and DSHOT telemetry? Or UART Telemetry.. or no telemetry..

Thanks,

Alex