ModalAI Forum

hi @nostrain ,

Thank you for providing an important detail regarding unloaded motor. I am going to test that condition with a similar motor.

I am a bit hesitant to ask you to go back to the older firmware since we have had a number of improvements since the original firmware, so we will try to figure out how to make this work.

In general, the ESC with unloaded motor should not be doing this, even while running in RPM control mode (which has been tuned for optimal response with a propeller). Ideally, the unloaded performance should not fail (while would behave differently from loaded motor).

Meanwhile, i am not sure how much value it is to do RPM step response tests with unloaded motor, because RPM controller assumes a loaded motor and the RPM controller is using the tuning parameters you provided. However, the motor behavior is extremely different without the propeller. To test realistic conditions, we typically run robustness tests like this with propeller on.

One more request, are you able to repeat the same test with the original firmware (that currently works) and set the demag_timing ESC parameter to 0. This was a feature originally put in for testing to help with low kv motors, but we later decided that this feature was not complete / robust enough to cover general use cases and it was removed. I am curious if it is helping in this case.

Alex

Hi @jbiscan21 ,

The main issue was that the max_rpm_delta was set to zero. Even with PI gains (and max errors) set to zero, you could have had it working with non-zero max_rpm_delta. Let me explain.

max_rpm_delta term is used to cap the target rpm relative to the current rpm. This is done to prevent very aggressive motor behavior, especially if motor is spinning very slowly because it is tangled in grass, etc, allowing unlimited max_rpm_delta could cause motor to burn out or de-sync.

The RPM controller has a feed-forward term and feedback terms.

• feedback terms are Proportional and Integral with corresponding gains and error terms (k * e).
• feed-forward term comes from the calibration : for desired RPM, the calibration tells the ESC what PWM (duty cycle) to apply
• there is also battery voltage compensation, so that even if voltage is changing, the feed-forward curve will still be accurate.

The rpm error is computed like so : rpm_error = rpm_desired - rpm_current, which standard. But then it is capped with the max_rpm_delta, so if that is equal to zero, then rpm_error will be zero. One subtle detail is that the rpm_error is also used to look up the desired rpm feed_forward : rpm_for_feed_forward_term = rpm_current + rpm_error (roughly speaking), so having the max_rpm_delta set to zero, caused the motor to be always stuck at minimum rpm.

So you could still have zero P and I terms and the motor would use a feed forward term with voltage compensation and it would provide a nice and soft response (similar to traditional ESC). Adding P and I will make the response better than a traditional ESC.

In fact when using a new motor + prop, you should start off with P and I gains zero, just use a feed forward term to test at first and then you can increase the ESC's responsiveness by giving it more max_rpm_delta and also P and I terms. However, that is more advanced tuning should be done using voxl-esc tools first in order ensure ESC response stability (we could discuss that in another thread).

To answer your earlier questions:

• You could use pwm (power) control, but i have never used it with PX4. Perhaps @eric-katzfey can comment about that
• the ESC calibration for modalai ESCs calibrates the feed-forward term (as described above), and has to be done with a propeller. Yes, in flight, the air dynamics will change due to many factors such as air pressure, temperature, air speed, etc, etc, but the job of RPM controller is to keep a desired rpm. A higher level controller could potentially estimate the thrust vs rpm is changing due to air temperature or pressure difference from the calibrated response (outside of the scope of ESC's rpm controller).

Alex

@dan-jennings , I would be happy to help you with the Hadron Issues on newer SDKs. There were no changes to the Hadron (Boson + OV64B) functionaliy recently.

Please make a new post for this issue and provide the following details:

• which SDK is working and which SDK(s) are not working for Hadron
• detailed description of the issue, any useful info from camera server or dmesg?
• how is Hadron connected to VOXL2? which interposers and which VOXL2 camera port (J6, J7, or J8)
• please provide voxl-camera-server.conf that you are using
• please provide a list of sensormodule.bin and *so files in /usr/lib/camera

Thank you

Alex

@jbiscan21 , can you also share the esc params that you uploaded to the ESC after ESC calibration ? I am assuming you went through this procedure : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md

From the log I see that all 4 motors spun up but the rpm is capped at about 2200 rpm, which may mean you ESC tuning params are incorrect.

Also note that after arming, your drone immediately commands about 10000 rpm, which is not great, because that would be a sudden jump.. you may want to check your flight mode to avoid this.

Yes, I believe the system image v1.8.08 has all the above changes built applied. Easy way to confirm

• voxl-camera-server -l and check the printed min gain. it should be 100 not 54. if you see 100, then you have the latest com.quite.tuned.default.bin
• exposure control improvements should also be in there as of v1.8.05 (com.qti.sensor.ar0144.so). this is harder to test, but sdk 1.6.5 should have the latest. To test, cover up the camera to drive the exposure and gain to the max and then uncover and you should observe smooth transition, no jumps in image brightness.

it looks like we are not shipping com.qti.sensormodule.ar0144_fsin_3.bin in the system image right now, but like i mentioned earlier we are moving towards putting the camera drivers into the voxl-camera-server repository.. but for now you will need to manually copy that one.

Alex

example of voxl-px4 driver output when running voxl-px4 -d:

...
Starting VOXL ESC driver
INFO  [qshell] Send cmd: 'voxl_esc start'
INFO  [muorb] [uORB] Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] [qshell] qshell gotten: voxl_esc start
INFO  [muorb] [qshell]   arg0 = 'voxl_esc'
INFO  [muorb] [qshell]   arg1 = 'start'
INFO  [uORB] Advertising remote topic actuator_outputs
INFO  [muorb] [voxl_esc] Starting VOXL ESC driver
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_CONFIG: 1
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_MODE: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_BAUD: 2000000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC1: 102
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC2: 103
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC3: 101
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC4: 104
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR1: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR2: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR3: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR4: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_PWR_MIN: 0.050000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_RPM_MIN: 2000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_RPM_MAX: 12000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_PERC: 90
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_DEAD: 20
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_EXPO: 35
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_MINF: 0.150000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_COSP: 0.990000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_VLOG: 1
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_PUB_BST: 1
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_WARN: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_OVER: 0
INFO  [muorb] [voxl_esc] Params: GPIO_CTL_CH: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_CMD: 0
INFO  [muorb] [qshell] Ok executing command: voxl_esc start
INFO  [muorb] [voxl_esc] Opening UART ESC device 2, baud rate 2000000
INFO  [muorb] [voxl_esc] Successfully opened UART ESC device
INFO  [muorb] [voxl_esc] Detecting ESCs...
INFO  [muorb] [voxl_esc] 	ESC ID     : 0
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0036
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 735us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] 	ESC ID     : 1
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0032
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 721us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] 	ESC ID     : 2
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0034
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 104us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] 	ESC ID     : 3
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0038
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 727us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] Use extended rpm packet : 1
INFO  [muorb] [voxl_esc] All ESCs successfully detected
...

@jbiscan21 , have you tried the actuator test feature in QGC? make sure to remove propellers for safety.

Also, as px4 starts up, the voxl-esc px4 driver will detect the ESCs and print some information, similar to what the CLI tool does without PX4. You can run voxl-px4 in foreground and check. voxl-px4 -d

Alex

Hi @srydell , you should use hobby / fpv quadcopters to get started with learning how to fly quadcopters. Most of them are flown very similarly to Starling 2 Max and you should at least master the angle + thrust control mode (roll, pitch, yaw angle an thrust as the 4 controls / sticks). More advanced (acro) mode would require controlling angular rates + thrust, which is for expert flyers and is not needed. Position mode (x,y,z position and yaw) is the easiest but would require some kind of positioning system (gps or VIO, etc), but that is the easiest to learn, since if you just let go of the control sticks, the vehicle will remain in place.

Learning to fly in angle + thrust mode is most useful and it will also let you better understand the vehicle's flight dynamics.

We do not have suggested options for what to buy for flight practice, but you should probably buy something that uses BetaFlight as the flight controller (very popular on fpv drones), but avoid aggressive racing drones -- it is better to start with something that is designed for smooth flight and filming rather than racing.

Alex

Hi @dinesh-varun-kandiyappan ,

Please see follow up responses

1. If your IMX412 camera fails fisheye calibration, this is probably because the lens is not actually a fisheye. Please see the following post regarding a recent lens change : https://forum.modalai.com/topic/5321/imx412-m12-lens-difference

• the new lens is rectilinear, so you should use the non-fisheye (plumb bob) model

The branch that saves the TOF calibration to a file is this one : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/tree/save-tof-v2-lens-cal . Sorry, we have not mainlined it yet. i will see if we can do that in the near future. see relevant post : https://forum.modalai.com/topic/5054/where-to-find-the-tof-and-hires-sensors-calibration

3. You may consider replacing your lens on IMX412 from the narrow one you have to a wider lens. We have the wide ones in stock and can get you a custom order if needed. Then you will see more features. The fisheye lens is about 30 degrees wider (horizontal FOV) than the non-fisheye.

4. VIO Features - maybe worth starting a separate post because it could be a long discussion and we could focus on that. Maybe make a new post with more details and we can get more folks on our team involved to look into it.

5.0 . PX4 params for Starling 2.. it looks like you may be correct.. double checking..

7.0 . We are testing Open Vins with rolling shutter cameras, let's discuss in another thread (see above).

8.0 . I don't think we have substantial updates to voxl-tflite-server.. will check.. and yes, qrb5165 is getting relatively old, so support for newer models can be difficult to get.

9.0 . If you are going to load up the cpu / gpu substantially, then a fan / heat spreader is needed. In general this is true for many mobile SoCs - they are powerful and efficient, but cannot sustain running at high utilization for long -- even phones can overheat and employ thermal throttling. My suggestion is to build up features / components one at a time and check your cpu / gpu utilization and thermal. Sometimes inefficient implementation of one component can overheat the whole system. also important to keep track of what resolution images you are using and make sure that you are not sending uncompressed images across regular (non-ION) pipes between processes..

10. before putting the second VOXL2 on the drone, you should proof everything on the bench. Starling 2 could certainly fit an extra VOXL2 mini. We don't have any official dates for VOXL3 yet, so it's best to focus on VOXL2. I will see if there is any info about VOXL3 we could share right now in terms of supporting newer inference models.

11. Can you please clarify what you mean by control policy? At what level are you training the control model (inputs and outputs?).

Hi @markmst ,
please see the following changelog for the AR0144 camera driver and the default tuning file. You can reference the system image versions here : https://docs.modalai.com/sdk-1.6-release-notes/

v1.8.06, v1.8.08, v1.8.09

• fix the min gain in default tuning file from 54 to 100. Even if you specify min gain of 54 in voxl-camera-server config, it will get corrected to 100 (so, no issue). this change is going to be in com.qti.tuned.default.bin

v1.8.05

• improve AR0144 exposure control to make it smoother (compensate with digital gain for the fact that AR0144 analog gain steps are not linear. This change actually lives in the com.qti.sensor.ar0144.so file.
• fix an issue where the max value (saturated pixel value) would be a function of the analog gain (would vary between 224 and 255)

By the way, it looks like we are going to move towards maintaining the camera drivers in the camera server repo so that we can update them much quicker and not require the system image update.

Can you tell me which AR0144 drivers you have been using? (where they came from). I can commit the latest to the camera server repo for convenience.

Alex

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