@tonygurney The ESC doesn't use PWM to control the motors. So it has the PWM channels free for other uses. The ESC used in the Sentinel actually has the PWM IO on a connector (J3) so no need to solder: https://docs.modalai.com/modal-esc-datasheet/

@yardy ,

looking at mpa to ros code..

The timestamps for the message headers are assigned here :

https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros/-/blob/master/catkin_ws/src/src/interfaces/imu_interface.cpp?ref_type=heads#L113

https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros/-/blob/master/catkin_ws/src/src/interfaces/camera_interface.cpp#L163

So the timestamps should be correctly converted to ROS time and not susceptible to any delays in the mpa to ros conversion.

Are you logging the ros messages using rosbag record and analyzing them offline? Make sure that you are not using the bag timestamp for that.

Alex

@Ege-Yüceel , in this case, i believe it should be OK to cross compile the voxl-tflite-server with dependencies from SDK 1.3 but deploy the application to VOXL2 that is running SDK 1.4.1. This is because there were no interface changes that would affect voxl-tflite-server (to my knowledge).

We will try to resolve the build issue soon, it should be a matter of fixing up CMakeLists file.

Alex

@jared, yes, all of the Lepton connectors on voxl2 breakout boards are 2.8V. you can try using your pure thermal breakout board with 2.8V input. It is possible that the voltage regulator on your pure thermal breakout board would go in pass-through mode in undervoltage condition with 2.8V input. But obviously we cannot guarantee performance since this would be out of spec for the Pure Thermal board. You could also modify your breakout board to bypass the regulator and feed 2.8 directly to the sensor, but i cannot guarantee any results, you would have to experiment!

@Indra-Jaganathan ,

The voxl2_io driver works as a standard PX4 actuator, supporting up to 8 actuator outputs.

When voxl2_io driver is enabled, you can select which outputs to assign to the 8 pwm outputs using QGC, just like any actuator setup.

Then during normal operation, the PX4 mixer will send the standard commands (based on your PWM channel assignment) to the voxl2_io module (the commands typically range between 1000-2000, but the range can be changed).

voxl2_io driver, will take these values and package them into a special packet, which is then sent out via UART to M0065 board.

M0065 board will receive the pwm control packet and set its pwm values based on the packet contents.

There is no SBUS involved in this communication (standard UART between VOXL2 and M0065 board).

Does that clarify the data flow from PX4 to the M0065 board?

Alex

@somalley @Alex-Kushleyev Thanks for referring to my March 1, 2025 post regarding the GPS problem:

https://forum.modalai.com/topic/4226/starling-2-max-no-gps-data

Overall I'm a big fan of ModalAI, but in my opinion this product contains a fundamental design flaw (complete loss of GPS position data due to EMI) that should have been detected and corrected early in the design testing phase. Moreover, that fatal design flaw has remained uncorrected for many months now, and I have received no information about if/when a permanent fix will be available. Our company spent over $5,000 on a Starling 2 Max, and it remains largely unusable due to this problem.

Alex Kushleyev at ModalAI has in general been very responsive, and has developed a temporary fix that customers can implement on their own, which I genuinely appreciate. But the fact remains that ModalAI inexcusably sold a product with a fundamental design flaw, and has not offered a permanent fix for many months now. In my opinion, at this point a permanent fix should be one of ModalAI's highest priority if they want to avoid a significant loss of customer confidence.

I would suggest that, as a first step, ModalAI should create a new post dedicated to providing ongoing fix updates and timelines, and to systematically update that post on the same day and time each week until a permanent fix is made available.

Thank you for your consideration.

Robert Judd

@taiwohazeez The build flow should be like this:

cd voxl-mpa-to-ros2 git checkout dev git submodule update --init --recursive voxl-docker -i qrb5165-emulator ./install_build_deps.sh qrb5165 dev ./build.sh qrb5165 dev ./make_package.sh deb

@tom that worked, thank you!

@Vinny thank you for the informative reply. Cheers

@shawn_ricardo , your issue looks identical to this one : https://forum.modalai.com/topic/4476/esc-calibration-help

When the values seem to be "stuck" and don't change for seconds, does the actual motor behavior also reflect that? in other words, does the motor RPM also get stuck? You would definitely hear the uneven transitions during the calibration procedure.

I have not had a chance to look at it, but there must be something up when running this script on VOXL2.

Can you please try the same calibration script after setting the voxl2 cpu to perf mode? voxl-set-cpu-mode perf. I will also try it.

Do you have a chance to try the calibration procedure while connecting the ESC to a Linux PC?

Alex

@mkriesel , the exposure and gain period parameters should be set to 1. They were used a long time ago for Auto Exposure control for ov7251 camera, which would have weird image flicker issues if you updated gain every frame, so we would use ae_gain_period set to 2. The issue with ov7251 was also resolved a while ago and it supports gain period of 1.

These parameters specify the update period (in frames) for sending out the new gain and exposure from the AE algo. So these parameters should be set to 1, which is the default for AR0144.

There is no practical reason to use any value other than 1.

Alex

Here is the output of voxl-camera-server -l, which shows that the system detects 5 cameras, including the TOF sensor:
4.png
5.png

@george-kollamkulam , something seems fishy here.

The Starling 2 drone has the VOXL Mini ESC, which acts as the APM (measures voltage and total current). The ESC sends this data to PX4 via UART together with regular ESC telelmetry.

The Battery status packet is an uint16 with 0.001V resolution, so the maximum voltage it could report would be about 65V (2^16 millivolts).

packet definition:
https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/actuators/voxl_esc/qc_esc_packet.h#L157

packet parsing:
https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/actuators/voxl_esc/voxl_esc.cpp#L577

I suspect something else is going on. Maybe you need to choose a different Source for the battery monitoring (not Power Module)?

Is this voltage 267.55V updating or just stuck at that value?

Alex