mavcmd - Takeoff and land in a local position

[TSC21]

@vooon I don't know if you agree with this but this could be an awesome thing to add considering the ROS framework capabilities we can use.

@mhkabir, @ggregory8: Guys this could be tricky so I must ask for your help and suggestions in this!

As you know, current MAV_CMD_NAV_TAKEOFF and MAV_CMD_NAV_LAND commands are built to support waypoints and not position vectors. So, considering that we don't want to use GPS for this or we are planning to do flights indoor, we should use local position instead.

A current approach I'm thinking off is: if we issue a command to takeoff (using for example the mavcmd script which @vooon greatly implemented), the mav should do the following (assuming that the mav is already armed, in POSCTL with position lock):

The command issues a setpoint to a local position in <curr_x, curr_y, des_z>, where curr_* are the current local_position_NED x and y and des_z is the z defined in the mavcmd issued. In this case, the <des_pitch> should be 0.0, or a mislead control will happen. The <des_yaw> can be used though. It can look like rosrun mavros mavcmd local_takeoff <yaw> <z>.

To set a land, this landing can be with two commands: a local_land and a local_land_curr. Both will work similar to the takeoff, with the difference that local_land lands in a setpoint position defined by us and local_land_curr lands in the current local position. Then, the local_position.position.z is read, and if it is =<z>, which is the z issued in the command, throttle turns to min. It can look like rosrun mavros mavcmd local_land <x> <y> <yaw> <z> and rosrun mavros mavcmd local_land_curr <yaw> <z>.

We can also think of, instead of defining a z of landing, let the command loop check when z =sensor_distance_to_ground, assuming we are using a sonar or something, or = 0.0, after doing a proper correction to z.

This, offcourse, will only be testable when offboard2_externalsetpointmessages branch is merged into PX4 Firmware master and our current vision_estimate branch can use it. It's a future work and not a priority, but we can start thinking on it.

What's your opinion on this?

[TSC21]

@vooon with the current info I gave, do you think you can get this done? Can aid but I'm not used to the python scripts you wrote (I'm more used to the plugins right now).

[vooon]

Sorry, currently i busy on my bixler (want first fly at weekend).

[TSC21]

Ok no worries @vooon this is not a priority :)

[andre-nguyen]

About landings

I've found that the best way to land isn't by inputting a position set point. The cleanest landings I've programmed were when I was in position control over the target point and switch to a controlled descent using velocity control. The reason is that sometimes your measured z vs your actual z will drift over time or your sensors just aren't in the right range.

For example, we use the px4flow's sonar for altitude measurement. However, this sonar has a minimum distance of 30 cm, which means if you try to go down to your take off height, you might end up going down and hovering at 30 cm.

About take off

Here's where I don't have a definite answer. Inputting a set point at a higher altitude will get your copter there but the initial start will be unstable due to all the backwash. It's preferable to have an aggressive take off so as to minimize that and reduce drift. The problem is that I don't know how to reliably implement an aggressive take off. I have a few theories but they are all hacks at best.

[mhkabir]

@vooon @andre-nguyen @LorenzMeier

I think this feature would be something we'd implement on the PX4 side as a command or similar, which would only be accepted in Offboard mode. Not something we'd prefer to do in mavros, I think.

Suggestions are welcome.

[andre-nguyen]

I think the px4 has a takeoff command when it comes to waypoints right? What's the behaviour in that context?

[mhkabir]

That works only for global missions I think. It is a mission command.

[mhkabir]

Oh wait, I missed this before : https://github.com/PX4/Firmware/issues/1281

[mhkabir]

What we need, I think, is support to be able to TAKEOFF and LAND commands in offboard mode, separate from mission logic. Offboard will extend to support global setpoint control later, I think and having the takeoff and land commands will be handy for a high-level planner running on a companion. Edit : Not supported yet : https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_receiver.cpp#L682

[TSC21]

We need to get our eyes on this soon. Don't know if it is easier to implement the actions on the firmware or in mavros. But probably it is the best approach to implement those commands on the firmware, and add some messages to mavlink.

[tonybaltovski]

The messages exist in mavlink but with GPS data.

[TSC21]

Well, updates: we have https://github.com/mavlink/mavlink/pull/401, so now we are in business on this. The idea is to implement the autonomous behavior on firmware. But then, we have to add the rosrun mavros mavcmd local_takeoff and rosrun mavros mavcmd local_land to mavros scripts.

[TSC21]

@vooon we need new mavlink release :)

[mhkabir]

@TSC21 Are you doing the modifications to navigator/commander/controllers in order to get this in Firmware? We are pretty ahead with protocol development, but have nothing working yet.

[TSC21]

@mhkabir yes I am

[wangsen1312]

@TSC21 @mhkabir Did the takeoff and land in local position works? For OFFBOARD Mode, maybe we can change something just like set_local_position function in thrust axis?

[tuofeichen]

Yeah, same question here. Is the local takeoff working already?

[saikrn112]

Is this feature implemented ?

[revantad]

Hey @mhkabir, I came across this thread since I am facing a similar problem. I am using a python script to take off and the arguments for the takeoff service are ALT, LAT, LONG,etc which probably uses the global position. Also, the drone is always taking off to the minimum_takeoff_altitude set using QGC regardless of what the altitude argument is set in the takeoff service. It would be great if you could give me some pointers.