@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.
Best posts made by smilon
-
RE: Rename ROS Topics pulished by the RB5
Latest posts made by smilon
-
RE: Height estimate not stable and wrong heading
@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:
- 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".
- 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
-
Height estimate not stable and wrong heading
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.
-
RB5 VOXL support deprecated?
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.125hw platform: M0052
mach.var: 1.0voxl-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 -
RE: Rename ROS Topics pulished by the RB5
@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.
-
RE: voxl_mpa_to_ros2 camera_interface timestamp
Dear @Alex-Kushleyev, @Eric-Katzfey this did the trick! Thanks for the quick fix!! Everything works as expected now.
-
RE: voxl_mpa_to_ros2 camera_interface timestamp
@Alex-Kushleyev Great! Please ping me here whenever you have this updated because current workaround is kinda ugly :S. Thanks a lot!
-
voxl_mpa_to_ros2 camera_interface timestamp
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!
-
RE: Custom px4-firmware build on StarlingV2
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?
-
RE: Custom px4-firmware build on StarlingV2
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.