Dear @Alex-Kushleyev, @Eric-Katzfey this did the trick! Thanks for the quick fix!! Everything works as expected now.
Latest posts made by smilon
-
RE: voxl_mpa_to_ros2 camera_interface timestamp
-
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.
-
Custom px4-firmware build on StarlingV2
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:
-
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?
-
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
-
-
RE: Issue with ros-melodic-cv-bridge and voxl-vision-hub conflict on VOXL2
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
-
RE: StarlingV2: ROS2 offboard control using voxl-microdds-agent
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? :)))
-
StarlingV2: ROS2 offboard control using voxl-microdds-agent
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:
- 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?
- 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! -
RE: ESC failure error after SDK 1.1.2 upgrade
@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!
-