Link_attacher: irregularities between drone types about mrs_uav_system HOT 9 CLOSED

Hey Raphaël, the differences you observe are correct. All our simulated drones are modeled according to their real-life counterparts. So the mass, inertia, and motor curves are "realistic". And in reality, our f450 barely flies, it does not have much of a power reserve. On the other hand, the t650 is very powerful and it has plenty of spare thrust.

Beware, 0.1 kg does not sound like much, but it is even more to the UAV if an additional moment is created (e.g. by connecting a fixed rod to the UAV, or by mounting it not below the center of mass).

I am not sure what is your goal here, so it is hard to give advice. If you need a powerful UAV, then use the t650.

from mrs_uav_system.

Hey,

Thank you for your answer! We tested with 0.1 kg, because we thought the f450 would be able to lift it. Our reasoning was that each motor of the f450 can lift 1kg, so we should have 2 kg of reserve thrust (2 kg for the drone), is this correct? For the t650 this would be even more.

Our setup is done as below, we spawn a simple box and do the link attacher with the drone once it is 1 meter above the box. The link we use for this is the base_link (center of mass of the drone?) and the link type is 'ball'. From what we see there is no moment. The tests our done with the SE(3) controller and MPC tracker.

We try to do the simulations with the f450 as we have one at our disposition for experiments.

Thank you in advance!

Raphaël

from mrs_uav_system.

Hello, yes the F450 is capable of lifting the load, however attaching it to a tether changes the system dynamics significantly and the controller is not tuned nor designed for that. The t650 has a bit different dynamics and it has different (lower) default gains in the simulation.

You can change to supersoft gains for the f450 (https://github.com/ctu-mrs/mrs_uav_managers/blob/master/config/simulation/f450/gain_manager/gain_manager.yaml), or tune the default gains with rqt_reconfigure, or here - https://github.com/ctu-mrs/mrs_uav_managers/blob/master/config/simulation/f450/gain_manager/gains.yaml.

You can also try switching from the SE3 controller to MPC controller, maybe it will handle the tether better. But keep in mind that none of our controllers is designed with the tether in mind, so you will have to design your own controller which encompasses the tether dynamics for best control performance.

Dan H.

from mrs_uav_system.

Ye can confirm, this "pendulum" affects the dynamical model of the UAV. The controllers might not be able to cope with that. They might if there is more spare power. But are you sure you are attaching it using a "ball" joint? The last time I checked the ball joint in the gazebo was not actually a ball joint and I had to model it using two revolute joints.

from mrs_uav_system.

Hey,

Thank you for your answers. The next step is to write a custom controller to cope with the load. I just wanted to check how your controllers would behave. I expected that a 'small load' (0.1 kg) would be regarded as a disturbance and be handled quite well. I tested with the MPC controller and indeed it handles better the load attached to it.

In the examples above we used the link_attacher from the extra_ressources package. Here we can define a 'ball' joint type between two links of different urdf files. But in urdf/ xacro for my model, I made a connection using 2 continuous joints. The final objective is to attach two drones to a load.

About changing the gains, how can I do this without modifying your files?

Raphaël

from mrs_uav_system.

We have experienced that you would need two revolute joints (for the 2D motion of the pendulum) since there is some inconsistency in the movement of the other joints. I think our system does have such support already. Try to spawn the drone with a --enable-ball-holder.

from mrs_uav_system.

Hey,

Thank you for your answer! Instead of using two continuous joints, we will switch to two revolute joints. We use the link attacher because we have to connect our xacro file (payload) to the f450 (your xacro file). But we think this is not the most efficient way.

How could we modify the component_snippet.xacro to reproduce what is done in the ball_holder example, without having "uncommitted changes"? We work in the workspace currently without modifying your files. There we have our own session.yml file but the component_snippet is not referred in there. Also the ball_holder is not available for the f450 (see Image) and we would like to have a bar instead of a 'ball'.

Thank you for your response!

Raphaël

from mrs_uav_system.

Raphael,
As Dan wrote we don't usually use the f450 to have some payload since it's really on the edge, thus we have attached the ball holder only on the f550 or t650.
For not having uncommitted changes, I think the best option from my point of view is to fork and commit your changes. Since it's a simulation addition. Also, you may try to extend the model path, and change the drone xacro, take a look here Gazebo docs . Though I haven't really done this, maybe other guys will have some other suggestions. @spurnvoj for example?

from mrs_uav_system.

Hi Raphael,
the simplest way to do it is to create your own fork of mrs_simulation pkg and commit your changes, as @WingRS explained. There is the possibility to create your own ROS package with the modified f450 model description, which will extend GAZEBO_RESOURCES_PATH. However, for that, you will still have to modify mrs_simulation pkg to look for your created pkg, so it doesn't make sense for you.

Note: Sometimes, the physics computed in the gazebo does a weird thing. For example, this happens when the object that the UAV is attached to is inside another object (e.g., box partially inside of ground). So when you see weird behavior check this.

Vojta

from mrs_uav_system.