Automatic takeoff for unmanned autogyro

[roman-dvorak]

Autogyros have specific requirements for take-off compared to fixed-wings. For example, before take-off, the rotor must have sufficient (flight) RPM. This rotation can be ensured in several ways. Then the phases of the start itself are slightly different.

Takeoff algorithm is divided into several steps:

1. Takeoff prerotation start:
   Wait for minimal RPM when it is able to start prerotation by electronic prerotator. This is because not every prerotator can spin the rotor from zero RPM. Spinning up can be done by hand.

2. Prerotation
   The rotor must obtain sufficient speed here for a safe start. It goes through some resonances, etc .. Sufficient RPM can be obtained by prerotator or by forward movement from some moving platform.

3. Takeoff preparation completed
   If the rotor speed is sufficient and we are in motion (airspeed) then we can start. Give a mark for release from the hand.

4. Release
   Send command to release

5. Climbout
   Obtain some (safe) altitude. Then some operation (turning) will be allowed.

6. Fly
   End of takeoff controller.

Our goals

Our aim is to make the takeoff of autogyro simple and reliable. Expand the possibilities of starting (not only by throwing from the hand but also, for example, from a moving platform, the roof of a moving car, ...)

We think that this procedure can be used with small, model autogyros, as well as for larger and more complex ones.

Initial assignment was written in ThunderFly-aerospace#32

Testing

We are currently testing the takeoff mainly with the TF-G2 autogyro and with the FlightGear simulator.

Here is video from the FlightGear flight simulator. This shows a fully autonomous start, which then passes in the mission.
https://youtu.be/DB9H-5oQkBY

The second video is from the start of a real autogyro. An error occurred during takeoff and the automatic start was interrupted. But thanks to his flight characteristics, the autogyro overcame this "bug" and flew on in the mission.
https://youtu.be/PtyXAhcqUQg

Real test flights

Test flight 31.12.2021:

tf-g2.mp4

[Jaeyoung-Lim]

There seems to be some changes unrelated to the autogyro autotakeoff that are part of this PR and not mentioned in the description

For example,

• Changing the remote of the flightgear bridge submodule
• Updating jmavsim submodule
• Updating Nuttx submodule
• Updating libuavcan submodule

[roman-dvorak]

Hi @Jaeyoung-Lim, thank you for viewing our code..

Submodules (jmavsim, Nuttx, libuavcan) are changing very quickly. And I did the last rebase last week, and more adjustments have been made since then. These different versions (of submodules) will certainly be unified as soon as it is sufficiently tested and ready for merging. And there will be documentation for that.

However, I have some things there that I do not know how (or rather how to solve it properly ). I will try to ask you about it in the near future. Thank you!

[RomanBapst]

@roman-dvorak Great to see your work on auto-gyros! I briefly went through the PR and noticed quite a few places where there are some hacks in place. I think you probably know about them and if you address them, then we can do another review.

[roman-dvorak]

Hi, I have some questions about the implementation of autogyro takeoff mode. @Jaeyoung-Lim @RomanBapst

1

I need to turn off the stabilization during the some steps of starting the process and be able to set the outputs/actuators to a certain position.

I have extended vehicle_attitude_setpoint message with a new value if it should be stabilized.
https://github.com/PX4/PX4-Autopilot/blob/a204377ed4a84c3a2b8f73cbd2ce2bb891c6f764/msg/vehicle_attitude_setpoint.msg#L20

But I don't know how to implement it best in FW Attitude regulator. I'm able to do some bypass there. but I don't know if this is the right approach. Can you suggest me a solution?

2

How to enable autogyro takeoff mode?
Currently, I have a new parameter AG_TKOFF which turns on the autogyro automatic start. At the same time, the automatic start for the fixed-wing must be switched off. Is this approach sufficient? With some check, both modes aren't turned on?

3

The FW takeoff mode can be functional for a maximum of 10 seconds (hardcoded). What is this value based on? Is it a developmental remnant? Or it has some meaning. I would imagine that this should be decided on the basis of certain values (height, speed, ...). And that this value varies quite; depending on the type (size) of the aircraft.

PX4-Autopilot/src/modules/fw_pos_control_l1/FixedwingPositionControl.cpp

Lines 622 to 632 in 4ba84d5

	FixedwingPositionControl::in_takeoff_situation()
	{
	// a VTOL does not need special takeoff handling
	if (_vehicle_status.is_vtol) {
	return false;
	}
	// in air for < 10s
	return (hrt_elapsed_time(&_time_went_in_air) < 10_s)
	&& (_current_altitude <= _takeoff_ground_alt + _param_fw_clmbout_diff.get());
	}

[Jaeyoung-Lim]

@roman-dvorak Sorry that I haven't had time to look into the actual code yet, but it seems like you are merging in master into the PR branch. It would be better if you can rebase your change rather than merge so that it is clear what the diff is between master and the branch from the commit history.

This is also why you have submodule changes in your git history

[roman-dvorak]

We performed a real flight test with takeoff mode for the autogyro.
Here is a video record:

As a result, the starting procedure was greatly simplified and the dependence on the operator's experience was reduced.

[roman-dvorak]

Hi, we have made a number of flight tests with an automatic takeoff for the autogyro and the start is now very reliable and simple. This allows you to start directly into the mission. Real flight tests confirmed the functionality of the system.

Therefore, I would now like to make edits leading to the acceptance of this PR.

The following videos show the automatic takeoff:

[Jaeyoung-Lim]

Thanks for cleaning up the PR, and great work on getting autogyros work with PX4!

I personally have no experience with Autogyros, so I am not sure if I can fully review this PR. Howver, It seems like the autogyro takeoff module essentially adds additional states to handle special cases for autogyros to takeoff.

Few questions / concerns

• My concern is that the changes are quite specific to autogyros and specific to the airframe being tested with(e.g. rpm sensor means main rotor of autogyro). However, some of them are integrated into the general part of PX4 (e.g. tune control) and introducing new takeoff states but only used for autogyros and not propagating to the rest of the vehicle types. If these are autogyro specific things, I think we need to be explicit that it is specific for only autogyros and safeguard it from breaking other vehicle types.

How to enable autogyro takeoff mode?
Currently, I have a new parameter AG_TKOFF which turns on the autogyro automatic start. At the same time, the automatic start for the fixed-wing must be switched off. Is this approach sufficient? With some check, both modes aren't turned on?

• Biggest concern is that it is possible to enable a "Autogyro takeoff" with other vehicle types (e.g. fixedwings). What would happen if this was enabled for other vehicle types? could this be destructive? I don't think trusting the user to take care of this is enough

• I am slightly confused with the term "Automatic takeoff" since all the demos seem to show a person throwing the vehicle. Is a "runway takeoff" really something not feasible for autogyros or is this something specific to the airframe you are using?

• Would it make sense to separate out autogyros to a seperate module?

[Jaeyoung-Lim]

@roman-dvorak Did you come to any conclusions on what the next action would be on this PR after the discussion on the dev call?

[roman-dvorak]

Hi @Jaeyoung-Lim , the next step is to get working simulator in upstream/master with TF-G2 model. To do this, it is currently necessary to merge #19122, which now contains the latest version of the FG bridge. Then it should be very easy to run the start simulation with TF-G2.

In the last comment, I tried to clarify the ambiguities about the questions. And I have no feedback on whether explanation is sufficient clear or whether there is still a need for debate (in these questions)

We tested the automatic start (from hand of running man) with a relatively large number of flight tests.

We are now working on the development of an automatic platform for starting from the car. But this is another improvement and does not affect the way of start from hand (and this PR)

[Jaeyoung-Lim]

In the last comment, I tried to clarify the ambiguities about the questions. And I have no feedback on whether explanation is sufficient clear or whether there is still a need for debate (in these questions)

@roman-dvorak Sorry, My understanding was that we discussed this topic during the dev call.

I think the changes in here are not generic enough to apply for fixed wings. As far as I can see I don't think having this takeoff logic inside the fixedwing poisition controller will benefit either fixedwing or the autogyro. It would have been a different discussion if the autogyro was doing a runway takeoff and reusing all the logic of fixedwings with the slight addition of rotor spool up / or the autogyro was taking the logic of hand throwing from fixedwings. However, this is not the case with the current implementation.

Therefore my proposal during the dev call was to make autogyros as a standalone module.

Also I am still not sure if the runner takeoff(A person running with an autogyro, while obeying the takeoff state sequences) is a generic autogyros feature, since I have only seen such operation procedure on the autogyros from Thunderfly aerospace. Isn't such procedure specific to the TF-G1 ? (Please correct me if I am wrong)

It would be helpful if @tstastny @sfuhrer have chime in if they have different opinions.

[roman-dvorak]

Also I am still not sure if the runner takeoff(A person running with an autogyro, while obeying the takeoff state sequences) is a generic autogyros feature, since I have only seen such operation procedure on the autogyros from Thunderfly aerospace. Isn't such procedure specific to the TF-G1? (Please correct me if I am wrong)

I have to say that I also don't know other people with a autogyro who would also start from hand. And I thing, that it's for 2 reasons. First is that autogyro is not common especially for autopilot-controlled autogyros (see unavailability of existing autogyro controllers). The second thing is that we developing drones for difficult conditions. And not just weather/wind conditions. But also for places with bad terrain. Where it is not possible to start from the ground. And man can run there :)

Hand throw starting is specific for ThunderFly TF-G2 and AutoG2 autogyros (with weight bellow 2 kg). Because their weight/size allows do this thing. Bigger TF-G1 (MTOW 25 kg) assumes starting from the car roof. Hand start is a simplified start from a car (moving platform)p

Therefore my proposal during the dev call was to make autogyros as a standalone module.

Okay, I'm sorry, I guess I probably didn't understand it very clearly during the dev-call. Separation into own module is probably reasonable and logical. Because other autogyro-specific features will be able to be placed into this module in the future.

But if I understand correctly, is it OK for this autogyro module to be called from the fixedwing-l1 controller so far? So how is it currently done?

[Jaeyoung-Lim]

But if I understand correctly, is it OK for this autogyro module to be called from the fixedwing-l1 controller so far? So how is it currently done?

This I guess depends on how you want to implement it, but my original intention was that autogyro has its own module (not library) so it does not fight with the fw_pos_control module at all.

[roman-dvorak]

This I guess depends on how you want to implement it, but my original intention was that autogyro has its own module (not library) so it does not fight with the fw_pos_control module at all.

Ok, I understand.

I would like to avoid this step for now (It can probably be expected in the future), because it would mean that fw_pos_control would be duplicated for some time. It would be fw_pos_control and ag_pos_control. with the same code and it will be much more difficult to reflect changes from one module to another.

Or do you think it's reasonable to have two controlers/modules with the same codes like this? Because before the position control controller will be created attitude regulator for autogyro.

[roman-dvorak]

Hi @Jaeyoung-Lim, gradually, I'am considering separating the automatic takeoff into the own module. With autogyro L1 regulator.

But I have question about flight taks. The use of flight tasks is spreading quite fast in PX4. A relatively large number of flight tasks are created.

Is there any consideration that the fixed wing takeoff would be created as a flight task? I am interested of this because it is probably also an interesting way to implement autogyro takeoff in PX4. What do you thing?

[Jaeyoung-Lim]

Is there any consideration that the fixed wing takeoff would be created as a flight task? I am interested of this because it is probably also an interesting way to implement autogyro takeoff in PX4. What do you thing?

@roman-dvorak I think from the discussions on one of the dev calls is that we want to have flight tasks for fixed wings, but it is not straight forward how we would implement this