mavlink set_position_target_local_ned does not seem to be transformed

coreyazion

" I took the drone off a few meters away from the Aruco code (EKF home position) without a view of the Aruco code. After flying manually to place the aruco code in view, "

What helped me is that at this stage I will often do voxl-inspect-pose -f. This will tell you the drone's current pose in fixed frame. Usually when this is correct and I have these enabled (as you already did in the tag_locations.conf ) :

"en_tag_fixed_frame": true,
"en_transform_mavlink_pos_setpoints_from_fixed_frame": true,

then the drone will fly to that coordinate in fixed_frame instead of in ekf_frame.

If the result of voxl-inspect-pose -f is not as expected (either the same as ekf_frame or comepletely off from where it should be), you can launch voxl-tag-detector or voxl-vision-hub with the debug tag to see what is wrong (type voxl-tag-detector -h in the terminal will reveal some info for launch option).

Matt Ooi

@coreyazion Thank you for this, I have used the web GUI to inspect the fixed frame pose; it does "jump" in position as soon as it sees the Aruco code, which is why i thought the only thing that may not be working was the transformation.

Nonetheless, I will test this out right now and get back to you!

Matt Ooi

@coreyazion I have just tested the voxl-inspect-pose -f, the results are as they should be. Is it possible that my mavlink command may be incorrect? From my understanding, set_position_target_local_ned takes in a few different coordinate frames as per link. The one which i am using is MAV_FRAME_LOCAL_NED. There are a few other options and parameters, i am unsure if any of these affect or prevents the transformation?

coreyazion

@Matt-Ooi

You seem to be doing everything right, but I am using MAVROS with PX4 maybe there's some subtle difference in the implementation?

One weird error I recall from my memory is that there was a time that I was also doing everything right but the relocalization just not work. (But the symptom is voxl-inspect-pose -f give me the ekf_frame coordinates). What magically worked is that I delete the tag_locations.conf and voxl-tag-detector.conf, reset voxl-tag-detector using voxl-configure-tag-detector, and then it worked. But this may very well not be your case maybe it was just some ill-formed json for me.

Matt Ooi

@coreyazion I would be using MAVROS eventually as well, pymavlink is just a quick and easy way for me to test this out, I would assume that they would be sending the same mavlink message to the VOXL. As for PX4 vs Ardupilot, i would also assume that they would be the same, as the transformation would be within VOXL instead of the AP; if my drone is still reacting to the commands, but going to the EKF origin instead of the Aruco code, the problem may be within the voxl. This is what i think at least.

I will give a go at resetting and reinitializing everything in the configs! Hope it works!

Matt Ooi

@coreyazion Just did another flight test after performing voxl-configure-vision-hub wizard and voxl-configure-tag-detector. Unfortunately the results were still the same and seems like the transformation is not happening despite fixed frame being offset in all debug modes I've tried.
I might try to use MAVROS next time since it worked for you. There is a slight chance that it may be the issue.

Matt Ooi

Hi ModalAI team,
I have a suspicion to this issue. Firstly, i am connected to the VOXL via UDP, but i am not sending any heartbeats from my GCS (laptop); i am only sending the set_position_target_local_ned message. Could this be causing the VOXL to determine that this GCS is "disconnected" and thus not transforming the set_position_target_local_ned message?

Zachary Lowell 0

@Matt-Ooi said in mavlink set_position_target_local_ned does not seem to be transformed:

set_position_target_local_ned

@Matt-Ooi so this is actually intrinsicly a huge difference between px4 and ardupilot - PX4 functions in NED as well as ardupilot - BUT if you are using MAVROS to communicate to ardupilot then it leverages the ENU/FLU coordinate system which is a massive pain in transofrmations which is why you are seeing this error - you will need to manually do the transofmraiton your self before streaming it into mavros to match its right coordiante system.

Zach

Matt Ooi

@Zachary-Lowell-0 Hi! Thanks for the response. Im not sure if i am understanding correctly. Are you saying that the VOXL SDK would not compute the transformations for Ardupilot? And that i would have to compute those transformations myself within my GCS before sending the guided commands?

Zachary Lowell 0

Spot on @Matt-Ooi - the voxl2 is natively meant to handle transformations for ardupilot and px4 - BUT you are using MAVROS which is a different tranformation all together - hence why you would have to do the transofmratio yourself before sending into the flight stack running ardupilot (aka when calling mavros offboard) or something