search

ZJU-FAST-Lab / ego-planner-swarm

An efficient single/multi-agent trajectory planner for multicopters.
GNU General Public License v3.0
1.2k stars 231 forks source link

no consideration of drone odometry while replanning #20

Closed shubham-shahh closed 2 years ago

shubham-shahh commented 2 years ago

Hi, Why the planner does not consider the current odometry of the UAV in the replanning step if the UAV is stuck at a point the planner traj keeps moving forward even if the UAV is stuck. @bigsuperZZZX

I found this https://github.com/ZJU-FAST-Lab/ego-planner/issues/9

but I am not sure what all places I'll have to make changes to add current odometry

thanks

bigsuperZZZX commented 2 years ago

Planning starts from a point on the current trajectory is to guarantee command continuity, therefore improving smoothness.

The UAV is guaranteed to not get away from the trajectory in our trajectory-planning-following framework. Therefore some external, forced stop is not considered in the current version. However, the FSM(finite state machine) has the potential to tackle such situations. You can just change the planner state to GEN_NEW_TRAJ when significant trajectory tracking deviation is detected. In this state, the planner plans a trajectory from the current odometry readings.

shubham-shahh commented 2 years ago

Hi, thanks for the response, but detecting a trajectory tracking deviation is difficult, that's why I want to try to combine the odometry in the planner. for a single UAV, I found following places where modification could be made

1, 2 along with startvel and startaccel

please correct me if there are additional places or If I pointed incorrect places.

also In your opinion, what are your thoughts what could be the possible downsides of adding odometry?

thanks @bigsuperZZZX

bigsuperZZZX commented 2 years ago

Modifying this is strongly not recommended since harming the continuity will lead to severe results.

In fact, detecting a tracking error is easy, you only need to compare the position in odometry topic with the command topic and set a difference threshold.

shubham-shahh commented 2 years ago

Modifying this is strongly not recommended since harming the continuity will lead to severe results.

In fact, detecting a tracking error is easy, you only need to compare the position in odometry topic with the command topic and set a difference threshold.

Okay, I'll try that. thanks for all the help