Real world experiment about cerlab-uav-autonomy HOT 7 CLOSED

@cheslee-z Hi, thanks for your feedback. Here is my thoughts:

1. Regarding your safety consideration, your modification seems fine to me.
2. For endless loop, I am also aware of that issue but happens very occasionally. I would very appreciate if you can go deeper to check what causes this endless loop and feel free to provide your feedback. I am planning to commit a revised version for solving that issue and also feel free to create a pull request if you have figured it out.
3. For the dynamic map visualization, if you can get message but cannot visualize it, I would suggest you check your network (is it because you the laptop didn't receive msg from the drone?). Or is the visualizatoin frame set to the correct one (i.e. "map"). Feel free to provide more information.

from cerlab-uav-autonomy.

@Zhefan-Xu Hi, thanks for your quick reply.

Now I update the follow-up:

The dead loop is because I did not take off during the test, so the orientation of the drone has not reached the expected value. When I manually correct the orientation of the drone, the program will jump out of the loop and really start the planning task.
But what's interesting is that this ros node automatically shuts down right away, apparently because of a problem with the eigen library. I checked about the log, this error ERROR: Ran out of pool, index= 27 76 -1 occasionally appears in simulation, but does not cause the program to die.

after I comment out this->moveToOrientation(yaw, this->desiredAngularVel_);, I conducted a new round of real flight experiments, and only a few times the program did not automatically interrupt. In the few successful planning experiments, the drone did not accurately track the trajectory, but instead demonstrated a higher speed than the set desired speed, which was set as a parameter of desired_velocity: 1.5 # m/s. The PID parameters of the tracking controller have been verified by other planners, so the problem of tracking the controller is ruled out.

from cerlab-uav-autonomy.

@cheslee-z

Can I ask what is the your testing height (z)? There is a parameter for height constraint in the planner parameter.

Also, are you using the local coodinate? From the msg output, it said path search want to find path between (0.13, -0.02. -3.90) to (3.13, -3.2, 0.05). I am a little bit confused with this data. If you start the drone at the ground, why there exist -3.90m in z direction? (Z should never go below zero)

from cerlab-uav-autonomy.

@cheslee-z

Can I ask what is the your testing height (z)? There is a parameter for height constraint in the planner parameter.

Also, are you using the local coodinate? From the msg output, it said path search want to find path between (0.13, -0.02. -3.90) to (3.13, -3.2, 0.05). I am a little bit confused with this data. If you start the drone at the ground, why there exist -3.90m in z direction? (Z should never go below zero)

@Zhefan-Xu

I think when specifying waypoint in rviz, the default height is 1m, which is also set by default in the code, and I have not changed it.

For the parameters of height constraint, you mean bspline_traj/min_height and bspline_traj/max_height? When I adjust these two parameters to 0.0 and 3.0 respectively, the node still terminates automatically, as shown in the figure below.

Also, I didn't pay much attention to the problem of coordinate system, but for the parameter of odom_topic, I set to odom_topic: /mavros/local_position/odom. I found that this parameter may still drift when the data of localization topic /vins_fusion/imu_propagate from vio does not drift. I think what you said about the z direction being less than zero is probably caused by that, because I've been putting the UAV on my desktop and not moving. So I set odom_topic to /vins_fusion/imu_propagate again. The following is the result of my experiment.

Maybe the key of the problem is not the coordinate system, I still need to further study the code. If you have any suggestions, could you please let me know at your convenience? Thank you very much!

from cerlab-uav-autonomy.

@cheslee-z
according to what you described: "Also, I didn't pay much attention to the problem of coordinate system, but for the parameter of odom_topic, I set to odom_topic: /mavros/local_position/odom. I found that this parameter may still drift when the data of localization topic /vins_fusion/imu_propagate from vio does not drift."

It seems like your VIO system is not working properlly (since you said there exits drift which can make the height estimation go to -3). I would suggest you to figure out the correct px4 VIO setup before running any flight test.

Also, as far as I remember, px4 mavros has different coordinate system from vins. In px4, x is the forward direction and y is the forward direction in vins framework.

Please let me know if you have any further questions.

from cerlab-uav-autonomy.

I am closing the issue. Feel free to reopen if you have any further updates.

from cerlab-uav-autonomy.

@cheslee-z according to what you described: "Also, I didn't pay much attention to the problem of coordinate system, but for the parameter of odom_topic, I set to odom_topic: /mavros/local_position/odom. I found that this parameter may still drift when the data of localization topic /vins_fusion/imu_propagate from vio does not drift."

It seems like your VIO system is not working properlly (since you said there exits drift which can make the height estimation go to -3). I would suggest you to figure out the correct px4 VIO setup before running any flight test.

Also, as far as I remember, px4 mavros has different coordinate system from vins. In px4, x is the forward direction and y is the forward direction in vins framework.

Please let me know if you have any further questions.

I checked my vio Settings and there was no problem. I finally found that the positioning height drift was caused by the fact that the altitude source setting of the px4 was set to the barometer main.

I'm still trying to replicate your work. I've also found that localization with vio is prone to drift, but optitrack is much better.

Thank you.

from cerlab-uav-autonomy.