simulation

[aswinthomas]

Hi, Is it possible to simulate dagny in ROS? Basically I just want to view motion in rviz. Or would you recommend a package such as http://wiki.ros.org/ackermann_vehicle.

Would it be possible to include brief instructions (on this github homepage) on how to do planning (lets say assuming perfect localization).

[trainman419]

I'm currently doing indoor simulation using the stdr simulator package.

You can try out the simulation using the full_sim rosinstall file: https://github.com/trainman419/dagny_ros/blob/master/full_sim.rosinstall

I'm currently simulating indoor navigation with the two launch files: dagny_sim sim.launch for the core simulation, and dagny_sim nav_sim.launch for running the ROS navigation stack.

I'm experimenting with my own local planner, and it has its share of bugs and unhandled corner cases, but I think it usually behaves better than most of the other planners.

[aswinthomas]

Hi Austin, Thank you. I was able to start the simulation and I used your rviz file for viewing the path.

However I could only view the stl body in rviz. No wheels. Anyway this is not important.

The global plan generated tries to cut corners. Is this the expected behavior?

[aswinthomas]

I just realized that this has to do with the motion primitives

[trainman419]

Yeah... there are some minor design flaws in the simulator that prevent running it and the robot_state_publisher at the same time, which prevents the wheels from showing up. They aren't used for anything, so I've just left them alone.

I'm using SBPL for the global planner; it explicitly tries to choose smooth plans that the robot can execute. It doesn't usually cut through obstacles, but sometimes I've seen it generate a path directly through an obstacle when there weren't any other alternatives; there's definitely a bug in there somewhere.

The local planner is a work in progress; it definitely tries to shortcut the global plan and gets stuck sometimes. One of my next goals for it is to come up with an internal weighting metric so that it can evaluate paths based on how closely they follow the global plan.

[aswinthomas]

Hi Austin, Have you experienced the simulator getting stuck after moving a bit? The cmd_vel shows the following, but I dont see the robot move.

rostopic echo /robot0/cmd_vel linear: x: 0.5 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: 0.571428571429

[aswinthomas]

On the lattice planner; a well formed motion primitive should take care of all possible motions of the robot right? In this case wouldnt a simple (even simpler than your dublins method) 1m forward looking trajectory follower do the job?

[trainman419]

I've definitely seen that happen when the robot gets too close to an obstacle. I think the collision model used by the simulator and the collision model used by the planner are slightly different.

When it gets into that state I usually either use teleop (teleop_twist_keyboard) to get it unstuck, or just restart the simulator.

There are lots of ways to write the local planner; mine is just one approach.

[jonbinney]

@aswinthomas even if the motion primitives that the planner uses accurately reflect the motion model of the robot, you have the problem that it is operating on a discretized grid. So the robot is never quite on the path that is generated by the global planner, and you need to do something in your local planner to deal with that (like @trainman419's dubins curve approach).

If you got both the xy resolution and especially the angular resolution high enough, and you replanned fast enough to get around dynamic obstacles, then a simple lookahead approach would probably work pretty well. That high resolution will slow the planner down though.

[aswinthomas]

Hi Jon, Thank you for the description in detail.

[aswinthomas]

Austin, does the /cmd_vel control interface currently simulate a dual ackerman (solid lines) or single ackermann steering (dotted lines)?

From the simulation it seems like dual steering; which is what im going for. Just wanted to cross check.

[aswinthomas]

FYI, the problem of simulator getting stuck after first few /cmd_vel commands is no more in the latest version compiled from source. I was using apt-get install earlier.

[aswinthomas]

@jonbinney, One good example of only using a global planner is probably the hector_exploration node. Like you mentioned, the result is basically a non smooth motion. So yes I guess a local planner is necessary. One advantage of hector is that it fares well in tight spaces.

[trainman419]

Dagny is a single-ackermann vehicle. Note that the planning/movement point (the base_link frame) is between the rear wheels. For a double-ackermann-vehicle, it would be in the center.

[aswinthomas]

I tried out a few things to get different robot models:

1. I disabled the code in the ackermann utils; so that gave a tricycle robot
2. I changed the dimensions in stdr.yaml to be symmetrical; so that gave me a diff drive robot in stdr and a tricycle robot in rviz(urdf)
3. Enabling the code in ackermann utils and changing dimensions in stdr.yaml gives me a dual ack steering in stdr. Changing orgin to zero and replacing the stl file to a cubiold in the urdf gave me dual ack in rviz.

[trainman419]

The planner and the motion model in ackermann_utils will work well for single-ackermann vehicles, and dual-ackermann vehicles where the front and rear steering are mirrored.

If you're adjusting the STDR model of the robot and the URDF to change the location of the base_link frame, you should also adjust the footprint that the planner is using in dagny_sim/nav_sim.yaml and dagny_nav_launch/common_costmap.yaml

If you vehicle has independent front and rear steering and can do maneuvers such as crab steering, you'll have to revise the motion model. I'm also not sure if STDR supports sideways motions yet.

[aswinthomas]

Hi Austin, Does the Ackermann local planner check for collisions? If so where does it do this. If not, do you have any ideas on how I can implement this?

I am having problems where the local planner plans through obstacles.

[trainman419]

Nope. There's no collision checking in the local planner. It's on my to do list.

[aswinthomas]

Ok. Will try to reimplement this package similar to dwa_planner. In this way I can use an obstacle cost function to check for valid trajectories. Will keep you posted