Posts made by smilon

@tom Hi Tom! To be honest I was not even aware this tool existed... super handy! So I played with the different EKF2_helpers and while the "Height estimate not stable" error was solved, I have two problems with the outdoor profiles that my application requires:

1. outdoor_gps_baro.params:

While the heading is correct in this profile, I get the error "local position estimate not valid". I checked that VIO is up and PX4 receives vehicle_odometry data. Therefore I cannot takeoff with this configuration. Additionally I get a warning that "GPS speed accuracy too low".

2. vio_gps_baro.params:

I can takeoff with position mode but I get the same "GPS speed accuracy too low" warning which does not allow me to trigger any autonomous PX4 functionality, which is crucial for my application. Even with 14 satellite lock, seems strange. Additionally the drone heading remains to be the local heading from the VIO initialization orientation, instead of the correct global heading. Is this intended?

Any ideas on how to solve these problems? I am more interested in the vio_gps_baro.params profile. Could it be a hardware issue with the GPS?

Best,

Milton

I have a clean install of voxl-sdk-1.1.2 and I am getting an error of a "height estimate not stable" which does not allow me to switch to position mode, or any autonomous functionality. Even with a GPS lock and 12 satellite connections.

I additionally observe that my compass's North points to the north of the PX4's init LOCAL orientation instead of the GLOBAL north, from GPS.

I am able to reproduce that by just changing orientation of the drone and restarting voxl-px4 service, while visualizing on QGroundControl.

Maybe the two are related. Is there any way to configure orientation to be taken from GPS and not perhaps the VIO channel?

P.S. I can bypass the error and switch to position mode by first arming in manual mode and then switching, but still I can't e.g return to home. Position holds great though.

Did the trick btw

Hello all,

Just wondering if the VOXL support (versions upwards of 1.1.2) for RB5 has halted.

In the light of some problems with vibration, position hold accuracy even at high GPS lock counts and voxl-open-vins-server initialization failure I am also wondering what should be the most stable SDK version for the RB5?

Currently, that I'm facing these issues, I'm running a nightly version I don't even remember putting on there (hopefully the root of my problems):

system-image: 1.7.1-M0052-14.1a-perf-nightly-20231025
kernel: #1 SMP PREEMPT Thu Oct 26 05:24:02 UTC 2023 4.19.125

hw platform: M0052
mach.var: 1.0

voxl-suite: 1.1.4-custom0

Packages:
Repo: http://voxl-packages.modalai.com/ ./dists/qrb5165/sdk-1.1/binary-arm64/
Last Updated: 2024-09-23 14:50:45
List:
libmodal-cv 0.4.0
libmodal-exposure 0.1.2
libmodal-journal 0.2.2
libmodal-json 0.4.3
libmodal-pipe 2.9.2
libqrb5165-io 0.4.2
libvoxl-cci-direct 0.2.1
libvoxl-cutils 0.1.1
mv-voxl 0.1-r0
qrb5165-bind 0.1-r0
qrb5165-dfs-server 0.2.0
qrb5165-imu-server 1.0.1
qrb5165-rangefinder-server 0.1.1
qrb5165-slpi-test-sig 01-r0
qrb5165-system-tweaks 0.2.6
qrb5165-tflite 2.8.0-2
voxl-bind-spektrum 0.1.0
voxl-camera-calibration 0.5.3
voxl-camera-server 1.8.9+1
voxl-ceres-solver 2:1.14.0-10
voxl-configurator 0.5.2+1
voxl-cpu-monitor 0.4.7
voxl-docker-support 1.3.0
voxl-elrs 0.1.3
voxl-esc 1.4.0
voxl-feature-tracker 0.3.2
voxl-flow-server 0.3.3
voxl-gphoto2-server 0.0.10
voxl-jpeg-turbo 2.1.3-5
voxl-lepton-server 1.2.0
voxl-libgphoto2 0.0.4
voxl-libuvc 1.0.7
voxl-logger 0.3.5
voxl-mavcam-manager 0.5.3
voxl-mavlink 0.1.1
voxl-mavlink-server 1.3.2
voxl-microdds-agent 2.4.1-0
voxl-modem 1.1.2
voxl-mongoose 7.7.0-1
voxl-mpa-to-ros 0.3.7
voxl-mpa-to-ros2 0.0.2-202402291159
voxl-mpa-tools 1.1.3
voxl-neopixel-manager 0.0.3
voxl-open-vins 0.4.4
voxl-open-vins-server 0.2.18
voxl-opencv 4.5.5-2
voxl-portal 0.6.3
voxl-px4 1.14.0-2.0.68
voxl-px4-imu-server 0.1.2
voxl-px4-params 0.3.3
voxl-qvio-server 1.0.0
voxl-remote-id 0.0.9
voxl-ros2-foxy 0.0.1
voxl-streamer 0.7.4
voxl-suite 1.1.4-custom0
voxl-tag-detector 0.0.4
voxl-tflite-server 0.3.1
voxl-utils 1.3.8
voxl-uvc-server 0.1.6
voxl-vision-hub 1.7.3

@Prabhav-Gupta You can just remap the topics coming out of the voxl_mpa_node, or remap the topics inside your ORBSLAM launch file. No need to mess with the source code.

Dear @Alex-Kushleyev, @Eric-Katzfey this did the trick! Thanks for the quick fix!! Everything works as expected now.

@Alex-Kushleyev Great! Please ping me here whenever you have this updated because current workaround is kinda ugly :S. Thanks a lot!

Heya,

I just found out something that's causing me issues with my TF's in ROS2. Shouldn't the timestamp of the ROS2 msgs be constructed from both nanosecs and secs?

In the camera_interface.cpp only the nanosecs field is populated causing the timestamp to be incompatible with any ROS2 time conventions.

This however is not the case in the imu_interface.cpp which works as intended.

Thought I would point it out!

Thanks for the info @Zachary-Lowell-0 ...I think day by day I am turning more towards MAVROS even though it is not the intended way to communicate with PX4 in ROS2.

I ran into an issue while installing the newly built voxl-px4 which states it depends on libfc-sensor(>=1.0.5) and I only have (1.0.4) on my system. @Eric-Katzfey I saw you authored some commits on libfc-sensor-api, do you have any clue how I can update?

Hi @Zachary-Lowell-0. So I haven't worked with microdds in PX4 before but say for example I want to implement PX4's PrecisionLanding feature. I need to send LandingPoseTarget uORB messages to PX4 and I want to do that with input from ROS2 topics. Currently, only a few basic topics are bridged by default, just like you point out in your docs, but I read in PX4's docs that I can expose the required topics for both input to PX4 and output to ROS2. At least that's my understanding. So I am not creating new uORB topics I just want to get more uORB topics into ROS2 and conversly publish more data from ROS2 into existing uORB topics.

I will post here in a few days with hopefully actual results!

Thanks.

Hello,

I am trying to figure out how to build px4-firmware which lives in voxl-px4 as a submodule.

My goal is to modify the microdds client config (dds_topics.yaml), in order to expose more uORB topic pub/subs for my custom ROS2 nodes.

I am going to ask some basic questions as I don't quite understand the process I need to take and can't really find any documentation that makes sense to me, at this time:

1. Do I have to rebuild voxl-px4 in order for the modifications to take place? If no, where does px4-firmware live inside the voxl2 environment in order to make these modifications?

2. If I have to rebuild voxl-px4 can I do it following the instructions from here? I am confused because it states that I need the rb5-flight-px4-build-docker docker image. Is this procedure supported for StarlingV2?

I would really appreciate some guidance here as I don't want to break anything again

Hi i've faced the same issue! Was wondering where voxl-vision-hub went ^^

How can we get it back on the system? @Zachary-Lowell-0

Ok, in a stroke of epipahny I realised that when switched to offboard mode through ROS2, the drone attempts to do both the modalAI "figure eight" that was configured in /etc/modalai/voxl-vision-hub.conf and satisfy the TrajectorySetpoint given to it by ROS2, resulting in this very jerky motion. Switching offboard_mode parameter to "off" solved this issue!! Works flawlessly now.

Any ideas how I can switch off passing the local odometry to PX4 and pass /vvhub_body_wrt_fixed instead? If I just publish to /fmu/in/visual_vehicle_odometry does it only take input from the publisher or will it publish from both sources similar to the offboard mode example? :)))

Hi!

I have recently embarked on the wonderful journey of offboard control using VIO, ROS2, voxl-microdds-agent and voxl_mpa_to_ros2.

My goal is to be able to set TrajectorySetpoints relative to a fixed frame, and let PX4 do all the control between setpoints, using its own position PID controllers.

I understand that a "fixed frame" cannot be obtained by pure VIO since this just creates a local frame where the VIO initialized and that odometry is sent to PX4 in the form of a VehicleLocalPosition (UORB message) and that local frame is prone to drift and/or jumps depending on VIO quality.

In order to solve this I have followed the AprilTag Relocalization guide and set a series of AprilTags on the floor so that I can always have a position relative to a fixed frame. This looks just fine on VIO tab of the web-portal (which is a great debugging tool by the way) as well as on the voxl_mpa_to_ros2 topic -> /vvhub_body_wrt_fixed.

This is the setup, now to the problem...

Before even attempting to pass the visual odometry wrt to the fixed frame to PX4 (instead of the local), I have been trying to get the following offboard example to work. I am not really sure how to debug the TrajectorySetpoint coordinates but whenever I run it the drone is very jerky and flies off hugging the ground in the wrong direction. Eventually it sort of spirals towards the moon but I have not been able to witness the complete behaviour because I test it on a 2x3x2.5m enclosure for safety purposes. The script is just telling it to move upwards (in the NED frame) by 1m.

Initially I thought I will tweak the position PID of PX4 but that did nothing and a coordinate frame inconsistency is much more reasonable given the behavior.

Now, I am pretty much a PX4 / VOXL2 noob but I understand that the odometry obtained from VIO in the local frame is passed into PX4 somewhere in the VOXL stack and that also accounts for the frame conventions. I have struggled a great big deal the past few days debugging this behaviour and am wondering the following:

1. Where in the VOXL stack is VIO passed onto PX4. Also, is it possible to pass the "fixed frame" odometry without tampering with the source code?
2. Any idea why I am seeing this behaviour and how I can solve this problem? Could it be a frame inconsistency? I always ensure VIO and position mode works well before I attempt to run the example but the motion in ROS offboard mode is very very jerky.

Any help is much appreciated!
Cheers!

@Alex-Kushleyev Hi Alex, to clarify what you asked:

• For ESC calibration I ran the voxl-esc-tools/voxl-esc-calibrate.py. This was not something I was prompted to do but since all of the voxl-esc scan/detect / voxl-esc-verify-params.py tools returned fine and was still getting "ESC failure" from QGC, I wanted to make sure that my ESC's are calibrated correctly.

• The parameters I refer to were PX4 params. Unfortunately I have not captured the output but they were several "ESC_" prefixed params. From my understanding, after flashing SDK 1.1.2 I had to run voxl-esc-calibrate.py and then voxl-configre-mpa again in order to register them properly to PX4.

Thank you!

I ran a voxl-configure-mpa and while im still getting quietter sounds from ESC, the Sentinel seems now fully functional. A lot of parameters were for some reason N/A and got filled in by this operation.

@Alex-Kushleyev Hi, indeed they run just fine. Also performed a calibration and everything returns fine. However, when I boot up the drone I get a "sad" sound from the ESC's, much quietter than I used to get previously. Any ideas how to proceed?

After having some issues with voxl-esc previous issue and recently upgrading to SDK 1.1.2, I am now facing an issue where when I try to arm I get the following in QGC:

My output from voxl-esc spin:

Finished!
[1702925954.747698] TX=508, RX=505 packets, RX CRC ERRORS=0
Average RPMs: 0.00 0.00 0.00 2996.27
Average RPM deviation between ESCs : 2996.27

My output from voxl-esc scan:

INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 2000000, protocol: firmware
INFO: Verifying ESC Params..


INFO: ESC Information:
INFO: ---------------------
	ID         : 0
	Board      : version 37: ModalAi 4-in-1 ESC (M0134-1)
	UID        : 0x2033303852465719004F002E
	Firmware   : version   39, hash d4fe8e3d
	Bootloader : version  183, hash b4fa2cf8
	Params     : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml 

	ID         : 1
	Board      : version 37: ModalAi 4-in-1 ESC (M0134-1)
	UID        : 0x20333038524657190050003B
	Firmware   : version   39, hash d4fe8e3d
	Bootloader : version  183, hash b4fa2cf8
	Params     : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml 

	ID         : 2
	Board      : version 37: ModalAi 4-in-1 ESC (M0134-1)
	UID        : 0x203330385246571900460047
	Firmware   : version   39, hash d4fe8e3d
	Bootloader : version  183, hash b4fa2cf8
	Params     : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml 

	ID         : 3
	Board      : version 37: ModalAi 4-in-1 ESC (M0134-1)
	UID        : 0x2033303852465719004D002C
	Firmware   : version   39, hash d4fe8e3d
	Bootloader : version  183, hash b4fa2cf8
	Params     : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml 

---------------------
successfully pinged ESCs

My output from voxl-esc detect:

Received standard error event 2

ESC detected: ModalAi 4-in-1 ESC (M0134-1)

Also when I try to run any of the below:

./voxl-esc-verify-params.py
./voxl-esc-scan.py
./voxl-esc-calibrate.py 

I get:

Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00) 
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.4
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
Received standard error event 2
Sending initialization request
Received standard error event 2
Couldn't configure flight_controller sensor
ERROR:   fc_sensor_initialize failed
ERROR:   Failed to initialize slpi
ERROR:   Encountered error while initializing bus 12
ERROR:   voxl_uart_flush: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_flush: Bus '12' is not initialized
ERROR:   voxl_uart_close: Bus '12' is not initialized
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 250000

And then it hangs there. I saw a similar issue here.

My model is StarlingV2 with SKU MRB-D0005-4-V2-C6

I am facing a similar-natured issue after upgrading to SDK 1.1.2. While everything from voxl-esc tool works fine in my case (scan, spin). I am getting px4 warnings that arming is denied and failsafe triggered when I try to arm. Then when I run:

./voxl-esc-verify-params.py
./voxl-esc-scan.py
./voxl-esc-calibrate.py 

etc.

I get:

Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00) 
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.4
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
Received standard error event 2
Sending initialization request
Received standard error event 2
Couldn't configure flight_controller sensor
ERROR:   fc_sensor_initialize failed
ERROR:   Failed to initialize slpi
ERROR:   Encountered error while initializing bus 12
ERROR:   voxl_uart_flush: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_write: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_read_bytes: Bus '12' is not initialized
ERROR:   voxl_uart_flush: Bus '12' is not initialized
ERROR:   voxl_uart_close: Bus '12' is not initialized
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 250000

Ok final update and case-closed...it was a USB-C issue! Even though I was most of the times able to discover my device, I was never able to discover it when in fastboot mode. Whenever anybody is facing such issues always switch to another USB-C cable first...