Add planning options inside circle_motion.py

[fanshi14]

Add motion planning options inside circle_motion.py. Add environment for collision test.

[tongtybj]

@KahnShi

Why are there two same PR? #31 and #30

[fanshi14]

@tongtybj One for master branch, one for planning branch. And I am also thinking about whether we need planning branch here.

[tongtybj]

common sense: PR to the main branch, that is master in this repo. If we want check the code before merge, we can do:

$ git check shi/perception

So, there is no meaning to send PR to origin/perception

[fanshi14]

Thank you for your explanation. I removed.

[chibi314]

Functions isConvergent, saturateVelocity, goPos and goCircle are copy-and-pasted. So we should consider better design of files. I suggest creating 'drone_navigation.py'. It has four functions noted above and related params.

[fanshi14]

I agree with you. @chibi314 By the way, when in the state of approaching to target, do you think it needs to be revised as the following to be more accurate, in case when tree_direction_ang is not so close to 0?

tree_direction_ang = math.atan2(self.tree_xy_pos_[1], self.tree_xy_pos_[0])

vel_msg = self.goPos(self.LOCAL_FRAME_, np.array([self.tree_xy_pos_[0] - self.circle_radius_ * math.cos(tree_direction_ang), self.tree_xy_pos_[1]] - self.circle_radius_ * math.sin(tree_direction_ang)), self.takeoff_height_, self.uav_yaw_ + tree_direction_ang)

[chibi314]

@KahnShi

I agree with you. @chibi314

Could you implement and test that file?

By the way, when in the state of approaching to target, do you think it needs to be revised as the following to be more accurate, in case when tree_direction_ang is not so close to 0?

I think it is better, so please revise it. Thanks.

[fanshi14]

@chibi314 You are welcome, I have implemented and tested it, and make a PR #36 here.

[tongtybj]

Check #37 which discuss the related issue. I don't want to stop this PR, just want everyone to recognized some potential problem will occur.

[tongtybj]

I think the obstacle avoidance mode should be the default function. Simple suggestion is to combine the circle_motion.py and motion_plannar_client.py, or create the navigation.py separating control and navigation part.

@KahnShi @chibi314 Let's have a small meeting tonight after me and shi coming back from kashiwa.

[tongtybj]

Resolve the ghost obstacle problem by #47

[tongtybj]

@KahnShi

Remove the state machine like "init_state" and "safty_flying_state" in the planning node. Change to a single flag which start the planning mode. Please check fd45bbe

[tongtybj]

@KahnShi

Please add your message here.

[tongtybj]

@KahnShi d24e170和b3423ed在做同样的事。

后者是我昨天push到shi/planning的，人多的话就不能这么开发了。这次我刻意这么做，是想让你在rebase时确认下前面的人都改了那些地方。

[tongtybj]

@KahnShi @chibi314

Integrate the obstacle avoidance into motion script, check with simulation, but still need to check with real machine in kashiwa