PX4
Automatic takeoff for unmanned autogyro
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:
-
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.
-
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.
-
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.
-
Release Send command to release
-
Climbout Obtain some (safe) altitude. Then some operation (turning) will be allowed.
-
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 https://github.com/ThunderFly-aerospace/PX4Firmware/issues/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:
https://user-images.githubusercontent.com/5196729/147875490-6f251c99-9d52-409b-bb59-161b635dd86d.mp4
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!
@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.
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.
https://github.com/PX4/PX4-Autopilot/blob/4ba84d56c9388f41e9ff366a7f4c73a2c4b5e4b8/src/modules/fw_pos_control_l1/FixedwingPositionControl.cpp#L622-L632
@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
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.
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:
Thanks for going through the code and for the first review.
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.
The autogyro for many flight operations is able to use controllers for fixedwings. We are currently in a state where there are not many changes to introduce a new category (FW, MC, AG ...) It now seems like overkill to me. If that's what you meant.
Knowledge of RPM is essential for the automatic start of the autogyro. Therefore, this is a requirement for this airframe.
At the same time, I would like to prepare for such a step (to separate autogyro as a custom category). But I'm not sure if I know what it all means. And if it's welcomed by PX4 side. Please write to me what you think is ideal. Because the number of changes in this direction (of supporting autogyro) will increase.
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 understand the concern. Would it be sufficient to create the parameter It is autogyro for a start? If it did not contain any RPM source, nothing would happen. But there is definitely a combination of parameters that could cause some damage.
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?
Ok, the autogyro is specific in that it needs to have sufficient rotor speed to take off (to produce enough lift). For this reason, he needs some forward movement before starting (airflow thought rotor ensures requested RPM).
So the running man only does to give him enough speed. The autogyro at the point when it is ready to start starts beeping, which is a signal to release from the hand. Subsequent operations such as climbing and navigating to the correct coordinates are fully automatic. Thanks to that, the start can be performed on very bad terrain (where it is possible to run).
We do not start from the ground because we do not have a suitable chassis for this (in the case of TF-G2). And using a TF-G2 rotorcraft doesn't even expect a nice runway.
Our goal is to do takeoff from the roof of a moving car (moving platform) that ensures pre-takeoff movement. And the disconnecting from the lock will also be fully automatic based on the mavlink message (currently a debug message is used)
Another way to takeoff should be from the runway. It should be able to do this with the autogyro TF-G1 or I use it so commonly in the FlightGear simulator. This has the disadvantage that it consumes an unnecessarily large amount of energy to start.
The selection of takeoff type is done by the parameter. And currently, we know the following types:
- From running man hang
- From the roof of the moving platform
- From runway
Each of them is fully automatic. But it is needed to start.
So I think that the name "autogyro automatic takeoff" is absolutely correct.
Would it make sense to separate out autogyros to a seperate module?
I guess I don't understand what you mean? I opted for these because our takeoff script uses an L1 regulator. And it's also run from there. Could you please spread this idea form me? Or do you mean to separate the whole L1 autogyro controller? Create a something like AG_pos_control_l1? That would probably be the way. But there would be (at least for now) enough duplicate code.
As for the possible enable of autogyro start at the same time with runway takeoff. Would it be enough to do fix that does not allow for ARM or start a mission?
Hi, @Jaeyoung-Lim I tried to answer the ambiguities and solve mentioned problems. Could you look at it again, please? Or what should be following steps?
@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?
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 https://github.com/PX4/PX4-Autopilot/pull/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)
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.
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?
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.
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.
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?
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