tu-darmstadt-ros-pkg / hector_quadrotor

hector_quadrotor contains packages related to modeling, control and simulation of quadrotor UAV systems.
Other
380 stars 276 forks source link

Quadrotor flies through walls and floor #6

Open muhrix opened 10 years ago

muhrix commented 10 years ago

Hello,

I am using ROS Hydro + Gazebo 1.9.3 + Ubuntu 12.04 with the most up-to-date hector_quadrotor, hector_localization, hector_gazebo and hector_models packages (according to hector_quadrotor.rosinstall).

Firstly, I loaded the willowgarage map: roslaunch hector_gazebo_worlds willow_garage.launch

Then, I spawned the hector quadrotor into the Gazebo world: roslaunch hector_quadrotor_gazebo spawn_quadrotor.launch

So far so good... However, once I took off and flew towards the wall, I realised the quadrotor flew literally through the wall. It does not behave as if there were no wall; there clearly is some disturbance in the flight. Nevertheless, it should never manage to pass through the wall (from my understanding).

I tried with other (ground) robots and they do crash and stop, never crossing the wall.

I have also noticed (in a Gazebo world I created) that if the world does not have a ground plane model, then the quadrotor does not land on the ground, but instead goes through the ground and falls to infinity. I did not observe this behaviour with the ground robots either.

I do apologise if this issue is not a bug with hector, but with something else. Could you please check whether you can reproduce this issue? Thanks a lot!

meyerj commented 10 years ago

Hi @muhrix,

sorry for the delay!

So far so good... However, once I took off and flew towards the wall, I realised the quadrotor flew literally through the wall. It does not behave as if there were no wall; there clearly is some disturbance in the flight. Nevertheless, it should never manage to pass through the wall (from my understanding).

I cannot really reproduce the problem. It is known that the simulated quadrotor starts to tumble around if it hits a wall and also that it can traverse it, but it is barely controllable afterwards and usually you have to reset the model. You definitely should see a reaction. I am not sure how we could make this behavior more realistic (given that the quadrotor has prop guards), as collision forces are handles by Gazebo's physics engine only. Ideas are welcome!

I have also noticed (in a Gazebo world I created) that if the world does not have a ground plane model, then the quadrotor does not land on the ground, but instead goes through the ground and falls to infinity. I did not observe this behaviour with the ground robots either.

This is desired behavior. There is no implicit "ground at z = 0" assumption. The world has to provide a collision geometry, otherwise the quadrotor will just fall until the motors are engaged (by commanding a positive vertical velocity). You can enable visualization of the collision geometry in Gazebo's "Views" menu. Some models might only have a visual model but no collisions defined. Can you see the collision mesh of the ground plane and for the walls/obstacles?

muhrix commented 10 years ago

Hello @meyerj,

Thank you very much for clarifying these issues.

The first part of what you explained makes sense. My doubts were mostly related to how the quadrotor managed to go through the wall and a ground robot cannot do it, but it does look like it is something to do with collision forces simulated by Gazebo. This was an observation I made, but ideally the quadrotor should avoid bumping into things anyway.

In regards to the second issue, I have a collada mesh which I use for visual and collision, defining walls and multi-storey floors. The ground robot does respect the mesh and does not fall to the ground floor, but the quadrotor only stops falling on the ground floor. I only managed to setup one plane in Gazebo (it appears to be by design). The issue with that is that I cannot land on the top floors.

I'll visualise the collision in Gazebo and get back to you (I cannot remember how it looked, but I did check that). I guess both cases were somewhat related.

Thanks again! :-)