Objects pickup is practically impossible to execute

[pieniacy]

Rationale for the issue

This issue touches the same problem as #188, however, we believe we can provide bigger picture, more in depth insights, accurate analysis whilst considering the problem in general and proposing a solution.

The problem

It is impossible to pick up an object using the suction gripper when deviating from exact COM (Center Of Mass). Test and demonstrations presented in this repository are superficial, selective and impossibly optimistic. They check only the perfect condition of artificially teleporting the drone over the exact COM of the object. It is physically impossible and unrealistic to expect such setup with actual autonomous controller flying the drone. Therefore, current setups with suction gripper are unusable and the task is impossible to perform.

Our experiments

We performed a series of experiments testing primarily how far from the exact COM we can place the drone so it can lift the object. We took a quadrotor with a suction gripper and placed small blue box in a known position, Then we teleported the drone, but we did it mulitple times with different offsets dx. We turned on suction, verified contact and called cmd_vel up command. After a few seconds we checked the drone z coordinate and plotted them like so:

The graph above shows that further from the center we were the lower we could fly. The grasp height is indicated with a red line, which means being just 1 centimeter off we end up descending, because the drone does not have enough power.

Analysis — concepts

We analyzed how the drones, grippers, payloads are set up, how the thrust is calculated and how the objects are picked up. Here are our findings:

• the same grippers are used on the manipulator and on the drones, that's unrealistic and not optimized
• suction gripper creates stiff joints, connection is not elastic, which is not the case for most real life suction grippers and thus doesn't allow for natural elastic alignment of COM by tilting the gripped object
• drone's thrust is calculated using something called motor_constant, which is more or less just a hardcoded coefficient applied to the square of the propeller speed to convert it to thrust
• motor_constant is different for every drone configuration. There are 6 different values for all configurations of {quad, hex} x {empty, gripper, suction}. There are no real life drones that magically become more powerful when more payload is attached. We consider this solution non-physical

Analysis — numbers

Now we come to the reason for the problem. Numbers that are chosen as masses and thrusts are irrational.

Let's consider a quadrotor with suction gripper and the small blue box:

• Drone: 1.5 kg
• Suction gripper: 4 kg
• Payload 1 kg
• Total mass: 6.5 kg
• Thrust @80%: 5.26 kg
• Thrust @90%: 5.92 kg
• Thrust @100%: 6.58 kg
• Thrust % needed to hover with payload: 98.8%

This drone needs 83.60% of its thrust to hover without any payload. Just hovering with small blue box requires 98.80% of the thrust, basically making it necessary to constantly go full power.

We have created a spreadsheet that should show the whole picture. Feel free to review it, report any mistakes and modify it for your needs. It clearly shows the problem of unusable configuration and possibly even shows that motor_constants were intentionally chosen so that the thrust is just enough to lift 1 kg, however this is just wrong and that's not how drones work, which will be explained below. It also contains our proposal, which also will be explained later.

Disclaimer: Similar math was presented in #188. The only inaccuracy is that it contains a false statement that lifting is an impossible task. It is technically possible, like it has been demonstrated in the artificial demo and in our calculations, but physically impossible to execute. We believe that the mistake in #188 is taking gravity of 10m/s^2 instead of 9.8m/s^2.

Explaining simulator behavior

Our spreadsheet analysis is completely consistent with what we observed in the simulator. The key to understanding the behaviour is just this:

Drones realize their attitude control by increasing and decreasing propeller speed. For example leaning forward means increasing the speed of rear motors and decreasing front ones. There has to be "enough room" to do this, i.e. the propellers has to spin lower than 100% to allow for a control-needed increase.

Intuition based explanation: In the simulator, when attaching a suction gripper off the center of the object we are shifting center of gravity of the whole assembly. The center of mass is no longer in the middle between the motors. If we moved back just before attaching the object then there is more weight to the front of the drone, so front motors need to spin faster than rear ones for the drone to stay level. Controller is prioritizing staying level, so it requests for example 10% difference front to back. From the hover point of 98% of the total thrust we want 93% on the back motors and 103% on the front ones. But it is not possible to magically have more thrust than maximum, so front ones spin at 100% and the thrust is not enough to even lift off.

By the way, this problem becomes even more apparent when any wind is present as the drone needs to sacrifice a component of its thrust to fight the wind.

Clearing misconceptions

Simulation environment testing

We believe that this simulation environment is not properly tested. Artificial demos with ideal conditions do not reflect on actual flying interactions. Here we see why testing only a single perfect scenario can lead to a situation where the task is actually impossible to execute.

Payload to drone mass ratio

It is rather unrealistic to expect the drone with its mass of 1.5 kg to lift 4 kg gripper and 1 kg payload. It is just unreasonable to assume that a drone can carry three times its own weight and fly for any reasonable amount of time.

Hover point

Drones should be designed to hover fairly low on the throttle. Exact numbers depend on the particular design, but generally around 50% should be ok and above 80% is not. This allows to operate in fairly friendly conditions for the electronics, have good controllability, be able to gain altitude quickly, but also to have some reserve for unexpected conditions or emergency situations (e.g. motor failure in a hexa)

Max thrust

The fact that specifications of a motor/propeller give for example 1 kg of max thrust does not mean that we can build a quadcopter with an all up weight of 4 kg. Usually half of that can be a suitable value to assume as nominal thrust. Max thrust should always be available, but never planned to be used.

Movement beyond hover

Any movement beyond hovering, that is lateral travel or ascending requires extra amount of thrust. In both cases our opponent is the air resistance, either vertical or horizontal. When flying up we need more thrust from the motors to counteract air resistance that acts on the drone from above and when flying horizontally we need to tilt the drone to counteract air resistance and only some cosine of the thrust points upwards.

The wind

This is somewhat analogous to the previous point, but worth mentioning, because even hovering in place when the wind is present requires more thrust. Flying against the wind is double as hard — we fight both the wind and the resistance due to our lateral speed, which btw would be impossible in the current simulation even with the payload being perfectly balanced, because if we hover at 98.8% we do not have any reserve to be able to fly against any substantial wind.

Unstable drones with grippers

In real life attaching any weight-wise noticeable payload would require re-tuning of the flight controller. In current simulation controller parameters are the same for all setups. We believe that accepting drones' wrong behaviour with payload and just using the same parameters is unrealistic and it is much better to tune the drones appropriately.

Proposed solution

We believe that current setup is just impossible to execute. At this point of the competition we do not want to propose any big changes or overhauls. We want to make minimal changes so that the issue is averted and drones behaviour is manageable. We propose to just lower masses of the grippers as indicated in the spreadsheet, which should bring all the numbers into sensible regions. We can propose a PR if osrf/organizers would like us to do so.

By the way — control interface

This is not strictly related to the issue, but somewhat on the similar subject.

Realism

The way we control drones now (with wanted linear velocities) is not realistic. A drone without GNSS cannot know its true velocity. Such control mode makes sense if and only if the flight controller is running full state estimation, including GNSS position and velocity, which is obviously not the case in our narrative. You could argue that airspeed could be measured, but in practice no real drone measures its airspeed in all 3 linear axes.

Usability

Although not realistic, this mode of control is convenient when just flying freely. It may or may not restrain our options when wanting to catch, lift and carry an object. But it can definitely be a problem when controlling the drone to drag a heavy object across the deck. Since this is not strictly related to this issue we will not dive into the details, but we can provide them if needed.

---

Let us know if you have any suggestions, we are happy to help if needed. Karol Pieniący Team Captain Nomagic Warsaw MIMotaurs

[iche033]

H, thanks for the detailed analysis. We are aware of the issue you raised about the weight of drones vs payload. The multirotor motor params are indeed artificial and we understand that they introduced inconsistencies with how real world drones behave. The priority for us was making sure the tasks are do-able first and then making them physically realistic. Ideally we achieve both but given aggressive timeline of this challenge, we had to make sacrifices in accuracy / realism. Having said this, we did various testing to make sure the UAV object grasping task can be completed. Thanks for the proposed solution. We will be discussing this with the organizers soon.

[iche033]

hi, we have approval from the organizers to make small adjustments for the UAV small object grasping task. Just thinking about the suggested change of reducing suction gripper mass. Reducing the mass of gripper may have the unwanted side effect of actually reducing the overall output thrust due to the way the multicopter velocity controller works. Changing the velocity controller is too risky at this point and only small changes will be accepted. So if you have a configuration / gripper mass params already adjusted and verified that it works, please post the changes here as soon as you can so we can get this out in a new release before the end of the week (Fri, Jul 29). We will likely need to incorporate those changes into a complete new UAV / gripper model so it does not affect existing behavior. Thanks.

[pieniacy]

Hi, the controller is indeed not designed correctly (it is quite silly that reducing its mass makes it less able to carry payloads). However, we were able to track down the problem and provide a relatively clean solution in #194. So now together with our proposed slight mass reduction grasping with suction gripper works and looks reasonable. We did not change any parameters beside the mass of the suction gripper. Changes are applied to the existing model and velocity controller for convenient diff readability, let us know if you believe these changes should be merged as a new controller and model, we will prepare the commmits.

Also please keep in mind that these changes do not touch finger gripper at all.