ayushgaud
commented
6 years ago Hi @skierlin I have been meaning to add a readme to the code but there are some bugs which need to be fixed before that. Anyway for your reference here is a small description:
- GoalPointTransformer.cpp allow the users to select on goal point on the map through rviz
- path_planning.cpp publishes trajectory_msgs::MultiDOFJointTrajectory "waypoint"
- "waypoint" is taken as an input by trajectory_generation in order to produce a new trajectory_msg which is smoothed with jerk constraints
- The scaling node is used to calculate the scale required for converting the monocular slam estimates to metric units.
- The transform node is used to transform point cloud from camera axis convention to ROS convention.
- The old_path_planner code is there only for reference since I have modified it in the path_planning node for replanning which is currently not working properly.
Regarding the implementation:
- I am using FCL for collision checking but instead of using RRT I am using RRT* with path length minimization as optimization objective.
- Ideally, collision checking should also be done for trajectory polynomials but you can increase the margins by increasing the size of the quadrotor model in the code. Still, this will never guarantee you collision free path which is a major problem if you require aggressive maneuvering hence the workaround is to take keep on taking intermediate waypoints until the trajectory is collision free (Ref). Secondly, I don't use Bspline since waypoints are treated as control points hence the trajectory will not pass through it.
- For simulation, I pass this trajectory message to RotorS simulator which uses a popular nonlinear geometric controller based on the work of T.Lee while in the real case I use a simple position controller keeping my parameters under the limit so that the generated trajectory is not aggressive and can be tracked easily with a simple linear controller.
- I saw the mav_trajectory_generation package after writing the minimum jerk code, but yes it can be used you just have to pass the waypoints to it. They have also made certain modifications where they are further optimizing the trajectory using unconstrained nonlinear optimization so as to generate better solutions (Ref)
- I feed octree and quadrotor model using only FCL definitions which are necessary for collision checking while OMPL only gives random poses to FCL quadcopter object and takes in the binary collision flag.
WR0903
ifaceyou123
acpl00
bitguige
and still, in the goalpoint_transformer.cpp file I changed the listener.lookupTransform("odom",....) to listener.lookupTransform("map",....) , because the frame_id of my nav_msgs/Odometry is "map". but there is always an error in the bash. as we can see in this picture.
Do you know the reason? Is my modification wrong? thanks a lot!!
witcher-joey
I think it is interesting and I have finished the catkin_make. but I can't start this program by rosrun the several nodes, can you give a introduce about the operation of the program. Thank you for your program.