Posts made by Alex Kushleyev

@Sam-Kiley , yes, every Starling 2 / MAX is going to have M0173 board installed and needs to use the option 1.

Alex

@mkriesel , you should try to communicate with the ESC from a linux PC using a serial to usb adapter and voxl-esc tools. This will remove VOXL2 from the loop and allow you to test the ESC independently.

It seems there may be some intermittent issue, since you are saying that sometimes you are able to manually spin. what about voxl-esc-scan.py ? Check UART cable?

Alex

@psafi the html file is saved in the same folder where you run voxl-esc-spin* scripts if you have --enable-plot 1 . on VOXL2, the plot wont show up on screen, since there is no screen attached to VOXL2 (which would work on a linux pc), but it will be saved to html. In order to save to html, you will need to have plotly installed. You may first need to install pip3

apt update
apt install python3-pip
pip3 install plotly --upgrade

Alex

@Sam-Kiley ,

From your post i see that you are using the Linux Kernel that is configured for camera front end M0173. I can tell this from mach.var: 1.0.1 in your voxl-version output above.

You need to re-install your SDK and make sure to select the kernel option. You will need to select option 0. See the following thread for more details, however the that user's issue was the opposite - they had 1.0.0 and needed 1.0.1. You need 1.0.0.

https://forum.modalai.com/topic/4725/camera-not-working-after-upgrading-voxl-sdk/7

Alex

@psafi ,

We sometimes refer to VIO as QVIO because our VIO software uses a VIO library from Qualcomm (hence the Q). this implementation is robust and works well for a single camera.

For using multiple cameras, we are using a custom version of OpenVins.

Both voxl-qvio-server and voxl-open-vins-server are briefly mentioned in the debug section of the doc that you referred to : https://docs.modalai.com/flying-with-vio/#debugging

Alex

@psafi , it looks like the motor simply does not spin-up properly, most likely because the sinusoidal spin-up is enabled (which it is by default) and the motor parameters are not correct or there is not enough power to spin the motor during spinup.

for the sinusoidal spinup to work properly, you need to set the following parameters in the esc config file (i adjusted the parameters for your motor):

    <param name="vbat_nominal_mv"     value="22200"/>  <!-- used for sanity checking and limiting of voltage-dependent funcions -->
    <param name="num_cycles_per_rev"  value="7"/>      <!-- number of pole pairs in the motor. used for converting electrical frequency to mechanical rpm -->

    <param name="spinup_type"         value="1"/>      <!-- 0: traditional, 1: sinusoidal -->
    <param name="spinup_power"        value="120"/>    <!-- power used to during spin-up procedure -->
    <param name="latch_power"         value="120"/>    <!-- power used during latching stage of spin-up (out of 999)-->
    <param name="spinup_power_ramp"   value="16"/>     <!-- it will take ( 4096 / (spinup_power_ramp*10000) ) seconds to ramp sinusoidal start-up power from 0 to spinup_power -->
    <param name="spinup_rpm_target"   value="1500"/>   <!-- Desired RPM at the end of the sinusoidal spin-up procedure -->
    <param name="spinup_time_ms"      value="1500"/>   <!-- Duration of the sinusoidal spin-up procedure -->
    <param name="spinup_bemf_comp"    value="1"/>      <!-- 0: disable, 1:enable back-emf compensation in sinusoidal spin-up procedure -->
    <param name="motor_kv"            value="900"/>    <!-- kV value of the motor. used in back-emf compensation during spin-up -->

If the motor still struggles, you can try to increase the spin-up power a bit higher to 130 or 140, but double check the current (per motor) during spin-up - a good rule of thumb is not to exceed 2-3 amps per motor during the spin-up phase.

In the params above i set 1.5 seconds spin-up time. you can try shorter if needed. However, significantly shortening the spin-up period, may require slight increase in spin-up power (to give it more torque).

If you calibrate using ID2, you will also see the total current (which will also include power for VOXL2, but that should be minimal).

Also, you mentioned running calibration in several motors - you typically do not need to do that, but you certainly can, just to check for consistency. All the ESC channels should have the same params / calibration.

One more tip; you can test reliability of spin-up by automatically commanding the motor to start / stop using existing test script:

./voxl-esc-spin-step.py --id 2 --rpm 0 --step-amplitude 2000 --step-frequency 1  --timeout 10 --enable-plot 1 --cmd-rate 100

(please note that this is a RPM step command, so your motor should be calibrated for RPM control) . if you don't want to spin in rpm mode, you can just use the following command to do a power step:

./voxl-esc-spin-step.py --id 2 --power 0 --step-amplitude 10 --step-frequency 1  --timeout 10 --enable-plot 1 --cmd-rate 100

I ran a similar command on a much smaller motor and here is a result (the exact command i ran was the following, but it will be too fast for your big motor / prop. Additionally, i ran the test on a linux pc, which allowed me to get much higher rate of feedback (2000 hz)

./voxl-esc-spin-step.py --id 2 --rpm 0 --step-amplitude 3000 --step-frequency 3  --timeout 10 --enable-plot 1 --cmd-rate 2000 --step-delay 0.1

This type of test can be used to automate testing multiple start / stop. Since your motor is different, you should make sure the motor spins down completely before restarting (adjust --step-frequency).

Additional tip, if you want the motor to stop faster (at least for spin-up testing, or permanently), you can set the following param to 1 and the brake will be applied when the motor is commanded to stop spinning (not just coast down):

<param name="brake_to_stop"       value="1"/>             <!-- apply brake when stopping motor (or not) -->

Alex

@ysc , I am glad that the camera is working, but could you clarify what you changed to make it work? You should be able to get higher resolution and FPS if everything is working properly.

Also, if the logcat outout is not showing up, it is probably because the logging from camera pipeline is disabled in the following file : /vendor/etc/camera/camxoverridesettings.txt:

systemLogEnable=0

If that is set to zero, you can just comment out that parameter and try again.

Alex

@ysc ,

Thank you for performing the tests. It is possible that the cables were damaged, since they were working originally, it seems, even with the "fpv" version of the drivers.

Regarding the output resolution vs camera mode, the best way to find out which resolution the camera is actually streaming is to run the following before you start voxl-camera-server:

logcat | grep -i selected

The output should be something like this (may look slightly different in your case):

03-02 13:03:06.847  3338  3338 I CHIUSECASE: [CONFIG ] chxextensionmodule.cpp:2358 InitializeOverrideSession() Session_parameters FPS range 30:30, previewFPS 0, videoFPS 0 BatchSize: 1 HALOutputBufferCombined 0 FPS: 30 SkipPattern: 1, cameraId = 0 selected use case = 1
03-02 13:03:06.852  3338  3338 I CHIUSECASE: [CONFIG ] chxsensorselectmode.cpp:558 FindBestSensorMode() MAI: Selected Usecase: 7, SelectedMode W=4056, H=3040, FPS:30, NumBatchedFrames:0, modeIndex:0

this tells you that the camera mode 4056x3040 @ 30 FPS was selected from the several modes that the sensormodule driver provides. Since you have selected the ISP processing in your config file, the default logic in the camera pipeline will select highest resolution camera mode and then down-scale in the ISP (for highest quality). So, even though you were selecting 1280x720 output, it is most likely that the camera was still running in full resolution mode (you can check).

In any case, there is an issue with the flex cables. One last thing, I just wanted to confirm that you are NOT connecting two M0036 flexes back-to-back (to make a longer cable), because that is not guaranteed to work due to the length.

If the single M0036 cables are not working, then we will replace them for free. Please submit an RMA request (www.modalai.com/rma) and ask for QTY 2 free replacement M0036 cables (include a link to this thread)

Alex

@Federico-Wyrwal , thank you for the reply. More debugging would be needed to figure out the root cause and it looks like you already submitted an RMA for the inspection / repair, so we will take care of it. Thank you.

Alex

@ysc ,

the "fpv" version of the IMX412 driver uses the fastest camera MIPI bit rate at 2.1 Gbit/s per lane. The M0036 cables, when designed, were not tested under these conditions, since the camera driver update came recently and the test was not available.

Can you please try to use the IMX412 sensormodule from /usr/share/modalai/chi-cdk/imx412/com.qti.sensormodule.imx412_2.bin instead of the FPV variant of the driver? (you will need to remove the com.qti.sensormodule.imx412_fpv_2.bin file from /usr/lib/camera/.

The older driver streams the camera data at a lower rate, I believe 1.5Gbit/s. Please let me know if this change works for you.

Regarding the cable supplier and degradation - we have not encountered cable degradation over time, however some cables may be slightly out of spec for this fastest MIPI bit rate. Also, we do not have other suppliers for the M0036, so you should purchase from ModalAI. However, lets figure out if there is a software solution first.

Also, what is the final resolution of the image and FPS that you need for your application? Lower resolutions require less bandwidth and we could lower the bitrate even more if that helps.

Alex

@ysc , can you please provide the end of the output from dmesg when you attempt to start the camera?

And just to confirm, you tried using a different IMX412 camera (of the same type) and a different M0036 Flex cable?

In the past we have seen that some flex cables (may be out of spec) do not work well with IMX412 camera. We can test this with a special camera driver (sensormodule), which will use the camera in very low MIPI bit rate. However, before we do that, can you please provide the output of dmesg when this failure happens?

Also, did this camera + flex configuration work before, or this is the first time you are testing it and it is not working?

Thank you

Alex

Yes, Hadron is working when plugged into J6 of VOXL2 Mini with default kernel.

You just need to have the following sensormodule files in /usr/lib/camera/:

com.qti.sensormodule.boson_0.bin
com.qti.sensormodule.ov64b40_1.bin

And instead of gpio6, you need to use gpio30 to enable the CCI mux, so that communication with the EO camera is enabled:

voxl-gpio -m 30 out
voxl-gpio -w 30 1

I will update the Hadron documentation..

Alex

@jcai , just wanted to confirm... since Voxl2 mini does not have J8, are you asking about about connecting Hadron to Voxl2 Mini J6?

Since this is VOXL2 Mini, which is not set up by default for the stereo pairs, I believe there should not be any changes needed to the kernel. I will test it.

Alex

Please keep in mind that the bayer image may have padding at the end of each row in order to align the line start with 16 or 32 byte boundary. This padding is done by the ISP when it receives the image from the camera.

For example, a number of common raw resolutions have the line stride listed in the FindFrameSize function in voxl-camera-server source code:

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L4636

@psafi , are you asking about QVIO?

For QVIO we typically try to get the extrinsics from CAD, which should be quite accurate. If you don't have exact CAD, then XYZ measurements should be within 5mm accuracy or better and within a few degrees rotation. QVIO actually estimates extrinsics, so it will try to correct as part of its estimated state. QVIO will probably converge to correct extrinsics even if you have a larger initial error in the extrinsics, however it's not a good approach to rely on QVIO doing this every time you start QVIO, because it can make the initialization of QVIO more prone to errors.

In the case when exact measurements are not available, you just use your best guess and then run QVIO in a feature rich environment, while holding the the drone by hand, smoothly carrying it around (smoothly rotating and translating). QVIO should converge and its state actually reports the estimate of the IMU to Camera translation and rotation (the extrinsics). Running this test several times (completely restarting QVIO) you can see what extrinsics the QVIO converges to and whether they are consistent. Then, you can update your extrinsics guess to the average value of the translation and rotation you obtained after running QVIO.

Hopefully this helps, let me know if you have any questions.

Alex

@jakkkkobo ,

The source code of voxl-send-neopixel-cmd test tool is here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-io-server/-/blob/master/tools/voxl-send-neopixel-cmd.c

The function that creates a binary packet (which is forwarded to the ESC via PX4) is here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-io-server/-/blob/master/lib/modal_io.c#L181 . Basically you need to provide the following information to this function:

• number of LEDs you are controlling
• LED type (RGB or RGBW)
• array of LED colors (3 bytes for each LED in case of RGB, or 4 bytes per LED for RGBW).
• the array should contain all LED values ranging from 0-255, so if you had 3 LEDs and first should be red, second green and third blue (50% power), the LED color array would be : [127, 0, 0, 0, 127, 0, 0,0,127].
• this function will create a packet with checksum and send it to PX4, and PX4 will forward the packet to the ESC.

You can modify the voxl-send-neopixel-cmd to do what you need, maybe you can make it accept an array of LED color values via command line.

I know the tool could have been more helpful. If you describe your use case, maybe I can help improve the voxl-send-neopixel-cmd tool.

Alex

@Federico-Wyrwal

Did anything happen between flight 1 and flight 2 which could have damaged anything on the drone?

When you power on your Starling 2, do you see blue lights blinking on the ESC? You can see the description of the expected behavior here : https://docs.modalai.com/voxl-escs/faq/#q-what-is-the-behavior-of-the-four-blue-on-board-leds. In the ESC datasheet (https://docs.modalai.com/voxl-mini-esc-datasheet/) you can see which side the LEDs are located and one of them is labeled, you should be able to spot the other three next to the each MCU.

Do you hear a tone that the ESC typically makes (using motors) when the power is applied?

Please check the integrity of the UART cable that connects the ESC to VOXL2.

Alex

@Rupesh , you need to reinstall the same sdk and select the correct variant during the initial stage of the SDK install.

Alex

@Rupesh , can you run “voxl-version” and check which mach var (variant of the hardware / kernel) you have? It should be 1.0.1, not 1.0.0. When you install the sdk, you have to select the correct one, which installs the correct Linux Kernel and enables the camera configs for Starling drones, which use the M0173 camera front end.

Please double check this.

Alex

@Rupesh , you should run voxl-configure-mpa or at least voxl-configure-cameras and make sure you select the correct camera configuration for Starling 2 Max, which could be C27, C28, C29 etc. The camera configuration is in the drone's SKU.

Please try. Let us know if you need any additional clarification.

Alex