Dear @Alex-Kushleyev, @Eric-Katzfey this did the trick! Thanks for the quick fix!! Everything works as expected now.
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!
-
-
RE: ESC failure error after SDK 1.1.2 upgrade
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.
-
RE: ESC failure error after SDK 1.1.2 upgrade
@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?
-
ESC failure error after SDK 1.1.2 upgrade
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
-
RE: Problem contacting ESC
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
-
RE: VOXL2 unbricking StarlingV2 - Forced fastboot mode doesn't work
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...
-
RE: voxl-configure-mpa failled on voxl-esc step
@Alex-Kushleyev @Eric-Katzfey Thank you for clearing this up. I am trying to install SDK 1.1.2 but my host machine can't discover the VOXL2 as a fastboot device (I have made an issue here). I would appreciate if you have any recommendations to hop on there as it is an urgent issue.
-
RE: VOXL2 unbricking StarlingV2 - Forced fastboot mode doesn't work
Update: I have also tried entering fastboot mode by keeping device powered on and holding SW1 for 30 seconds.
dmesg -wH confirms that device is disconnected after approx. 30 seconds.
It seems my linux can't discover the device whenever it's in fastboot mode. Any ideas how I can work around that? I have installed fastboot by running sudo apt install android-tools-fastboot. Note the reason why my VOXL got bricked occured while flashing in fastboot mode.
-
VOXL2 unbricking StarlingV2 - Forced fastboot mode doesn't work
Hi,
I have faced an issue with my Starling for a few days (issue) and after some debugging attempts I decided the only way forward is to reinstall the latest version of the SDK (voxl2_SDK_1.1.1).
Following the steps discussed in another topic (topic) I attempted a "factory flash":
cd voxl2_SDK_1.1.1 cd system-image ./flash-system-image.sh -f cd .. cd voxl-suite ./offline-install.sh adb shell
My VOXL2 was unable to fastboot automatically so I had to do a manual fastboot following this guide VOXL2 - How to force fastboot
After some attempts (was kind of tough to get it with 2 hands). I managed to start the flash but it got stuck here:
After letting it hang for ~45minutes I unfortunately had to cancel it and power cycle. At which point I was no longer able to discover the device either through adb or fastboot. At this point i considered my VOXL2 to be bricked and followed the following guide to unbrick it. For some reason after switching the VOXL to EDL it was not consistently discoverable in my host PC and had to do several attempts by rebooting both my host PC and power cycling the VOXL until I got it to succesfully flash. I tested the succesful image flash by doing an adb shell which connected.
The Problem
At this point I follow the afforementioned procedure to reinstall the SDK but I am having trouble to fastboot. I can now consistently discover the VOXL in both QDL and normal mode but whenever I attempt the fastboot procedure (and I assume it enters fastboot) I can no longer discover the device as either USB, adb or fastboot connection. Is there any other way I can tell my VOXL to fastboot on next boot? Do you have any suggestions on how to proceed?Setup:
host: Ubuntu 20.04 (tested on Ubuntu 18 too)
starling power supply: 12V 3A (/w custom XT60 to XT30 connector)
USB-C connection: USB-C to USB-C on host (has worked without issues prior to the factory flash, attempted other cables too)