Moveit for non holonomic mobile base in 2D

[Aswin Thomas]

Hi all,
I am interested in generating plans for a non holonomic base. I tried running demo.launch in the moveit package generated by setup assistant and the system can generate omni motions using OMPL RRTstar.

How do I get the planner to plan with robot specific constraints. Does this have to do with writing a better urdf?

I am guessing one of the ways would be to work on a different state space such as DubinsStateSpace. How do I specify this? Will changing the state space in pose_model_state_space work?

Regards
Aswin

[Aswin Thomas]

Lets say I am using husky_description package. How do I setup the moveit package using setup assistant? Since I want the robot to move as a whole, do I set all joints as one base_group?
 Right now it plans as shown here: https://dl.dropboxusercontent.com/u/8948006/husky.gif


How do I make it plan better trajectories

[waldez junior]

Hi Aswin,

As far as I know, MoveIt! does not allow for planning with differential contraints, e.g. planning for non holonomic robots.

In order to do that you would need to implement a planner framework on your own, with OMPL for example, since OMPL has planners that work with these kinds of constraints.

The downside of it would be to "reinvent the wheel" and all the amazing things MoveIt! has done to us (thank the developers for that =D). Since I'm turning in my final project in the next week I actually did something like this, but I REALLY dont recommend it as a general solution, since its full of workarounds, instead of real fixes.

A (MUCH) better option imho would be to try to modify moveit to at least plan for differential drive mobile robots (which are very popular among robots).

[Aswin Thomas]

Hi Waldez,

Thank you for your reply. I wanted to get an idea of how to do this rework on moveit ...OR would it be best to design a separate library based on OMPL and other libs i.e. similar to what moveit aims, but for differential constraints. At the moment I am only interested in base planning though.

I also have doubts about planning with controls vs geometric planning. Assuming we are using the same planning algorithm e.g. RRT, Is it necessary to do planning with controls as in OMPL? Or is it better to do higher level geometric planning and later control as in moveit? I know its a generic question, but what would be the pros and cons.

Thank you

Aswin

[waldez junior]

Well, since you only want to plan with the base you MIGHT wanna check this out:

http://wiki.ros.org/move_base

Regarding the pros and cons between the two approaches there's this paper from Dr LaValle about motion planning that may help:

http://msl.cs.uiuc.edu/~lavalle/papers/Lav11c.pdf

About the rework on moveit, i'm not sure about how to do it, this is something I guess it should be up for debate.

My best guess right now would be to develop a node for base-planning that could wrap around MoveIt! features into an OMPL planner with differential constraints, I mean, if you ever try to plan with OMPL on its own you'll see how MoveIt does a LOT of work for us.

And to actually track the trajectory, you would have to develop your own controller for the base.

[Martin Günther]

Hi Aswin,

Usually, base planning is done using move_base or sbpl. Is there a specific reason why you want to use MoveIt?

Cheers,
Martin

[Aswin Thomas]

Hi Martin and Waldez,
Thank you for your input. I am interested in sampling based planning. In my opinion, move_base is not a generic architecture.

I am also interested in FCL and octomap that moveit already uses. There is also no tool like setup assistant. Yes, I think moveit authors have done a great job and the progress is awesome. But it would be good to have base planning as well. There are robots that have to do base and arm planning and it would be great if both could collaborate on a same map.

Regards
Aswin

[waldez junior]

+1 about whole-body planning addition to MoveIt! in the future!

I understand MoveIt! could plan for a mobile manipulation problem easily if provided the joint values for all joints (virtual base joint included), i may be wrong but the only problem in my opinion would be the kinematic constraints of the base that could vary from robot to robot.