Posts made by Alex Kushleyev

@shawn_ricardo , just to close the loop on the original issue.. the delay in the calibration procedure was caused by UART data or processing of the ESC feedback backing up. The fix is to just slow down the command rate, seen in this commit : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/commit/b512f9e3d5e695868775de3d40eedb2ad15cf6d9 . Additionally, using command line argument --cmd-rate 100 when you run the calibration script on VOXL2 will fix the issue.

Regarding the issue in the step response where the feedback data appears not smooth, i believe it is related to FTID's buffer / delay. FTDI adapters have this parameter latency_timer which is 16ms by default, which amount of time the FTDI board holds the RX'ed data before passing forwarding it to the PC (and vice versa, i believe). You can set that value to 1:

You can check this value:

cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

And set it:

sudo su
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

You would need to do this every time you unplug / plug the FTDI device back in.

(note that this applies only to Linux PC, not VOXL2).

Besides this, i think the plots look good. It looks like you have set the kp pretty low, which keeps the response softer (less chance of de-sync).

Alex

@victochen , just to close the loop on the original issue.. the delay in the calibration procedure was caused by UART data or processing of the ESC feedback backing up. The fix is to just slow down the command rate, seen in this commit : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/commit/b512f9e3d5e695868775de3d40eedb2ad15cf6d9 . Additionally, using command line argument --cmd-rate 100 when you run the calibration script on VOXL2 will fix the issue.

@jonathankampia ,

(just FYI we just updated some more information about M0201 / M0153 here : https://docs.modalai.com/M0153/)

It seems that connection is not an issue in your case. However, the config file is not correct.

Please use the minimum config, as provided in the Hadron setup docs. We will update the Boson setup with a minimum config as well.

https://docs.modalai.com/voxl2-hadron/#minimum-config

What is happening is that the ISP is not liking the custom resolution of the Boson (640x512) and it causes a low level buffer overrun, causing voxl to crash. So disabling small and large streams should fix it. use preview stream only and enable raw preview.

Here is the config snippet from the above link:

{
          "type": "boson",
          "name": "boson",
          "enabled":  true,
          "camera_id":    0,
          "fps":  30,
          "en_preview":   true,
          "en_misp":  false,
          "preview_width":    640,
          "preview_height":   512,
          "en_raw_preview":   true,
          "en_small_video":   false,
          "en_large_video":   false,
          "ae_mode":  "off"
      },

(please note that after you run voxl-camera-server with this minimal config entry, the camera server will auto populate some additional fields). Also note that i did not paste the full config here, just the camera entry - a few more lines at the top and bottom (mostly braces) are misssing.

I am going to add Boson support in our MISP processing pipeline so you will be able to get h264/h265 encoded boson video feed as well, but meanwhile you could just use voxl-streamer to encode these relatively small frames.

Please let me know if the config update fixes your issue.

Alex

@george-kollamkulam , also are you able to use voxl-esc tools to verify the voltage?

You can run the following command, which will not actually spin the motors, but will communicate with the ESC and receive feedback:

#stop px4
systemctl stop voxl-px4

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

The script should run and print out the voltage reported by the ESC.

Alex

@somalley ,

Very cool, thank you for sharing. We will try something like this.

Please note that we have observed that the wifi dongle, which is right under the gps receiver, causes some interference as well. Can you please try to repeat your test by unplugging the dongle completely?

A workaround to move the dongle to a different location is to use a different USB breakout board. Instead of M0141, use M0151 with a cable (JST GH to USB A Female).

Alex

@tonygurney , yes.

Please see the comment about pin availability and pin numbers here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/voxl-esc-pwm.py?ref_type=heads#L17

Please note that running voxl-esc-pwm.py script will use the serial port and cannot be done concurrently with PX4. This is a standalone tool, unlike voxl-send-esc-pwm-cmd tool, which sends a message to voxl-px4 and the pwm control message is then forwarded to the ESC by the voxl_esc px4 driver.

Alex

@Luca-Zanatta , I believe your issue is that you are specifying the wrong type of TOF sensor. There are two types:

• pmd-tof (old, EOL)
• pmd-tof-liow2 (a.k.a irs2975c)

Based on your sensor id (Slave Address: 0x007A, Sensor Id: 0x2975), you have pmd-tof-liow2, so you should run camera-server-config-helper tracking:ov7251:0 tof:pmd-tof-liow2:1).

When you configured for pmd-tof, the camera server config was incorrectly set for the old TOF sensor, which has resolution of 224x1557. The new TOF sensor has resolution of 240x1629

Please try. Sorry i did not catch that earlier.

Alex

@Jordyn-Heil , sorry for the delay.

I will provide an initial example of getting 4 AR0144 streams into a standalone app and doing something with all of them on the GPU using OpenCL. This should be a nice example / starting point for multi-camera image fusion.

Initially I will just use our standard mpa approach to get the image buffers from camera server to the standalone app. After that i will also try to do the same using the ION buffer support (which is already in camera server) which will allow us to map the buffers to GPU without doing any copy operations or sending image data over pipes. using ION buffer sharing will allow to further reduce the cpu and memory bandwidth usage, but it's still a bit of experimental feature and will need some more testing.

Please give me a few more days.

Alex

@h3robotics ,

Yes you should be able to test the Hadron on J8 using the instructions from the docs page (https://docs.modalai.com/voxl2-hadron/) -- just make sure you use Boson sensormodule 4 and ov64b sensormodule 5 (and camera IDs will still be 0 and 1 respectively, if there are no other cameras attached / detected).

At this point you do not need to build a custom kernel, just need to use kernel variant 1 because it enables independent camera support on J8 which is needed for Hadron. Please note that you would not be able to use our standard ucoax camera on J8U because the camera reset signal is still not correctly patched through to J8 (which would require a kernel modificaiton). But in Hadron use case, camera reset is not used (both the IR and RGB camera are always on, so it happens to work out ).

I agree, it may be more convenient for you to switch to using the M0173 camera front end, so you can use a single kernel variant and also this would be a more future-proof approach.

Alex

@ROBERT-JUDD ,

Yes, we are aware about the cable mismatch (sorry, the shipment was rushed a bit, but we will get it right!)

Regarding the satellite SNR, yest it still looks low. I would normally expect 10dB higher.

Are you able to test with disabled 5G modem? maybe pop out the 5G card or shut it down via a pin ( think we discussed how to do this long time ago).

I just received the same kit and will be testing it today and compare with my initial implementation of the mast. Will report back..

Alex

@tonygurney , I am assuming that you are using the ESC hardware version M0134 (you can confirm using voxl-esc scan tool.

Here is the datasheet for M0134.
https://docs.modalai.com/modal-esc-datasheet/

This ESC has an option (via installing a 0 ohm resistor) to provide 3.3V to pin 1 of J3. This is the same voltage that is used for the MCUs that run on the ESC and should be used with caution (if this voltage rail is brought down by overloading, the ESC will shut down). Please see image below that shows where 0 ohm resistor should be (carefully) installed to enable 3.3V on pin1 of J3 (marked in red)

If you actually wanted 5V (VAUX), that is available on the other side of the board via two test points at the edge of the board. This voltage rail is provided by a separate switching regulator. See the following section : https://docs.modalai.com/modal-esc-datasheet/#neopixel-led-support

If you REALLY need 5V to be present on pin1 of J3, then you can add a small wire jumper from the VAUX test point directly to the pin1 of J3 (which is marked with a white dot). This pin 1 of J3 is normally disconnected. Please only do this if you are comfortable performing this type of soldering and we cannot guarantee the results :).

Alex

M0153 step file : link

@JackHammer no problem.

This should be the esc param file for the Starling 2 Max motor : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-params/D0012_Starling_MAX/esc_params_m0129_f2203_5_1500kv_7x3.7x3.xml

The param file should also be present in /usr/share/modalai/voxl-esc-params

Do you know how to update the esc parameters?

systemctl stop voxl-px4
cd /usr/share/modalai/voxl-esc-tools
./voxl-esc-updload-params.py -p <full path to params file>

After updating the params, you can run a "power ramp test", as shown here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/doc/low_kv_motor_tuning.md?ref_type=heads#power-ramp-test . Use id=255 to spin all motors (and you can limit power to 80%)

./voxl-esc-spin.py --id 255 --power 80 --ramp-time 3.0 --timeout 3.5 --enable-plot 1 --cmd-rate 250

Since you can't display the plot on voxl2, a plot will be saved as html, which you get download from voxl2 and view in a browser.

You can do it without propellers (for safety). If all the motors are working properly, the four rpms will be very close to the same as the power ramps (within 100-200 rpm). Otherwise, you may have a bad motor that was damaged during the crash.

https://www.modalai.com/products/starling-2-max-replacement-parts?variant=49704826896688

Alex

M0162 step file : link

@JackHammer , can you please tell me which drone you have an post a picture of the motor just in case? I can point you to the correct parameters for your motor.

Alex

@Rodrigo-Betances , yes, absolutely. I will provide your name to the team.

@KLindgren , yes something seems off. Few things to try:

• try plugging the ar0144 camera into the lower slot of M0084 and using sensormodule with id 2. Double check the orientation, but the camera should face the same way (towards the voxl2 mini)
• use J6 port on the VOXL2 mini (and the corresponding camera slots will be 0 and 1)
• if you have any other camera to test, we can try just to make sure M0084 is functional. If you have another camera, let me know which one, i can help set it up.

Alex

@JackHammer

That error is weird, since 555 <= 744 <= 755. I think there is some issue with the leading 0 in the perms... Have not seen that before.

You should not have to remove the old voxl-esc package, all the files in the package will be overwritten.

I am assuming you are just making a custom version of the package? If not, you can always get the latest package from : http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/

Alex

@h3robotics , you are welcome!

Actually I already tested the Hadron data flow via J8. The only change required is to use the kernel variant 1 (which is designed for M0173), but you dont actually have to have M0173 installed. Besides the kernel change, just use appropriate sensormodule drivers for Boson in slot 4 and ov64b in slot 5.

Do you have enough information from the above description to try it or do you need more details (how to install kernel, etc).

Without any other cameras there will be no limitations, but if additional cameras are used with hadron in J8, there will be some limitations. I will document soon.

Keep in mind that for the other use case (IMX412 and tracking cameras), if you are not using M0173 camera front end, you will need to use the kernel variant 0. Just one more thing to keep track of

Alex