Using moveit on mrs_uav_system about mrs_uav_system HOT 5 CLOSED

Hello, to my knowledge nobody tried to use moveit with our system yet. But using it should be quite easy, simply send the trajectory you get from moveit to the topic control_manager/trajectory_reference (you can read more here - https://ctu-mrs.github.io/docs/system/uav_ros_interface.html) and the drone will track the trajectory (if it is feasible).

We are mostly using custom path planning algorithms, which are suited for different problems (target tracking, avoiding obstacles etc.). We might add a path planning layer to the system in the future.

Cheers, Dan H.

from mrs_uav_system.

Hello,
in principle, there should not be any significant issue in integrating these two frameworks. In general, any path-planning framework can be used with the mrs system, however, you, as the integrator, have to ensure that your data are correctly prepared (the output of moveit, the input to mrs_uav_system). Providing path-planning and SLAM handler layers is in our plans, but unfortunately is not available yet.

Follow the link to which @DanHert referenced you to. I'll just point out that if your path is not sampled with respect to time, you can use mrs_uav_trajectory_generation to obtain a time-parametrized trajectory.

Cheers, Pavel

from mrs_uav_system.

Hi Dan, Pavel,
Thanks for your answer!
I gave a shot to integrate the moveit and mrs_uav_system recently, thanks to the excellent interface of both sides, it didn't take long time to do so. I'd like to share my observation and problems I met:

1. Mrs doesn't use /robot_description param to spawn drone models in gazebo, while moveit relies on the urdf in the /robot_description param to parse the model and find tf tree, so I solved this by manually sending a “representative“ urdf to the /robot_description, it can be a simplified substitution since the only joint used in motion planning is the joint between the drone and the world.
2. The tf tree of mrs is kinda "reversed", like explained on the website and I understand it's for solving the multi-frame problem. However it will cause errors in moveit since we are trying to move a root frame (/fcu). I solve this by manually broadcasting another branch transformation from "/gps_origin" to "/base_stabilized" (same pose as /fcu). I think if you can also broadcast such an (additional) transformation with conventional hierarchy (maybe with different names, like world -> base_link), it will help people like me who are doing path planning with mrs to get odometry information more easily.

Above are some observations I have when I'm using mrs_uav_system, feel free to correct me and any extra information will be appreciated. :)

Thanks for your time!
Gaoyuan

from mrs_uav_system.

Hey, I don't have all the answers, but we normally use the spawn_model command. Just the URDF contents are not passed by the /robot_model param (which is rather arbitrary) as in http://gazebosim.org/tutorials?tut=ros_roslaunch, but we create the urdf by the drone_spawner script based on the desired sensor configuration.

Yep, our TF tree is rather inverted, however, it is still a valid tf tree. Sou you can add nodes as you are used to, e.g., putting the /fcu frame as a child of some another frame. As you wrote, we have the parents of the /fcu as its children (with the transform being inverted) so we can have more than one parent frame. But otherwise, it is a normal tree and programs, such as rviz work just fine with it.

from mrs_uav_system.

Thanks for your answer!
:)

from mrs_uav_system.