@Moderator Hi, do you know where can I get a description of the tsdf file format that the voxl-mapper uses?

Is there a way to change or update body_wrt_local to body_wrt_to_fixed? This way we can start anywhere on the map and we are not forced to start on 0,0,0

Hi,
we are using apriltags on a starling with

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

when we plan and order to follow the trajectory using voxl-mapper if the drone detects an apriltag relocates and create a sudden change in the fixed frame that makes the drone quickly try to reach that offset. Depending on the drift of the relocalization this is a very strong change of position that can cause QVIO to fail. In the documentation it says that

"When enabled, any SET_POSITION_TARGET_LOCAL_NED mavlink messages received through UDP will have its position, velocity, acceleration, and yaw values updated with the fixed frame offset before being sent to PX4 over UART. This is very useful for MAVROS and MAVSDK processes running locally or remotely."

Is this process done all at one time? Is there an easy way to "average" this correction so as there is no sudden changes in the reference position. Is there any other way of doing this?

Thanks in advance

When we start voxl-tag-detector service with "en_tag_fixed_frame": true any change to offboard mode makes the drone loose the position, heavily drifting sideways. Isn't the px4 control referenced only to local frame? If so tag relocalization shouldn't affect the hold position. Is there any other configuration we are missing?

@Moderator Not all of them, recalibrated IMU, measured vibrations and some times vibrations were about 5 on the z axis. The problem happens when apriltag detection service is running.

@iparra I have narrowed it down a little. It has to do with apriltag detection. As soon as the service is enabled the drone looses stability even switching to figure_eight mode. The following options were enabled "en_transform_mavlink_pos_setpoints_from_fixed_frame": true, "en_tag_fixed_frame": true. Maybe it has something to do with the transforms. Any idea? Is the use of tag-detector in some way incompatible with autonomous navigation?

Re: ESC calibration guide

We damaged one of the blades and replaced (one pair on one of the rotors). The new blades are the same as the original ones. We have several questions:

• When a blade is damaged, do we change all the set (4 pairs) or only the pair that is damaged?
• Is it recommendable to calibrate the ESC after the replacement? Right now it feels a bit more unstable than before
• If so, can you point me to the recommended procedure for calibration?

Thank you in advance

We are using voxl-mapper for autonomous indoor flights and we are experiencing strong height looses or even drifting sideways when switching from position mode (Drone hoovering in position hold mode with 90-100% QVIO quality) to offboard (trajectory). Sometimes it is a short drop in height, but most of the times the drone reaches the floor or drifts sideways at a considerable speed until we switch to manual mode and land. The times it is able to regain stability, voxl-mapper works as expected. Any idea of what can cause this?

Thank you in advance

@Jetson-Nano Unfortunately it is not yet fully working, as I said I managed to create plans with waypoints and to fly those plans we are currently launching the plans on a waypoint to waypoint basis so, no full trajectory without stopping (we don't have to click on the waypoints but the drone stops to plan the next strecht). We have done so because we don't trust the VIO to be able to mantain a correct pose for the long trajectory through the waypoints and we "stop" at the waypoints (where we placed april tags) to relocate and replan with a corrected position after a flight between waypoints.

If you trust VIO to follow your planned trajectory it is possible. We have modified the planTo function from mapper to localize the closest waypoint to the clicked target and we launch global_planner_->createPlan(current_start, final_target, waypoints_); iteratively from way point to waypoint without clearing the waypoints_ vector until it reaches the last waypoint and then plan to the actual target. This creates a long trajectory that should be followed when you press follow button. As I said we have never tried to follow the long trajectory, but as far as I understand the drone should follow it given that qvio maintains a good enough pose.

Right now we are experiencing stability issues when switching from position mode to trajectory mode. If we manage to solve that I can run a test with the long trajectory and get back to you.

@Moderator Hi, do you know where can I get a description of the tsdf file format that the voxl-mapper uses?

Hi,
we are trying to load map a .vxblx tsdf map generated with voxblox into the drone. We have assumed that the vxblx is the tsdf file that the voxl-mapper generates and have transformed the vxblx file to esdf with the test tool tsdf_to_esdf from voxblox project. Unfortunately it seems that the .vxblx is not accepted by voxl-mapper. Apparently they are not the same format. Is there a way to load a voxblox .vxblx tsdf map into voxl-mapper? Are we missing something?

Another workaround would be to reproduce a bag directly into voxl-mapper and let it create the map files. We have found voxl-mpa-to-ros, is there an equivalent voxl-ros-to-mpa?

Thank you in advance