I’m working on a similar system to the two implemented below. Would anyone be interested in collaborating? I’m about to dive into that implementation from tomorrow, and having a partner to work with would be great! It would be simpler, and initially use GPS. The idea would be to enable throw-launches of small quadrotors, with an aggressive recovery and position hold.
Hi @mhkabir,
Are you still willing to work on this topic ?
Do you already have ideas on how to do that ? Where would you start ?
I tried some things as mentioned here but I don’t know what would be the best approach.
In my opinion that should not be too complicated because the attitude controller is not based on Euler angles and do not have singularities; as far as I understand it should already recover from any orientation. So the main difficulty would be on the logic to set the MC into this mode, and to start the motors fast enough as soon as free-fall is detected…
What do you think?
Hello rousselmanu
I think there are two ways. First, in mc_pos_control module, if free fall is detected, throw launches logic would be started. The throw launches code would be added into the task_main main loop. The mc_pos_control module is running in all modes, but I think some assisted modes are better to use while testing.
The second way is to control it in offboard mode. This could be more customized. You can set attitude, motor or arm and your own logic.
I guess the attitude cannot be easily adjusted to near level only by the attitude control module, since the it might be flip over in a short time. Controlling the motors directly may be necessary.
What do you think?
Thanks for the answer. I would rather do it onboard.
Don’t you think that the logic should be added in the commander module rather than in the pos_control module ?
I think of two possibilities:
For starting motors quickly, I think that we could use the same approach than what was done with the killswitch here : motor’s outputs would be inhibited until free-fall is triggered…
Hi Guys,
I’ve been a bit busy, so didn’t get much time to look into this previously.
Essentially all the work that needs to be done will be in navigator and commander. I propose we add a “launch” mode for multirotors (with circuit breaker!!) and run the specific launch control loops within after that.
It’s just a matter of sequencing things in the right way to get it working. Controllers should be running at all times, and just enabled when we reach a particular stage of the throw.
This is a tested launch control sequence, and is proven to work well in practice.
Sounds good to me 
I am starting to work on it, and will use this branch: https://github.com/rousselmanu/Firmware/tree/launch-control
It may take some time because commander and navigator modules are pretty big and hard to understand… 
Try to not change everything. There is absolutely no need for a new flight mode. It should instead be a small addition in the commander main loop which kicks the system into armed mode. Look at the land detection handling, you need to do the opposite.
Ok, understood. But in my opinion the system should be armed before throwing.
I just pushed a first simple try with the following logic:
For the past few months I have been attempting to create this exact feature for my dissertation, bit of a shame I have only just found this, but from what I have done so far come to the same point as @rousselmanu, this has been partly driven by having to make the application simple enough for it to be marked by someone without the knowledge of the field. The plan was to use simulink and the PSP. However, I am now going attempt to go the route suggested by @LorenzMeier to make it a more relevant piece of work. Although the commander seems to have changed significantly. Are there any updates on the original works in this topic?
Hi @Ethan_Bond,
The throw/free-fall detection part is working and has been merged with master (see parameters LNDMC_FFALL_THR and LNDMC_FFALL_TTRI to tune the detection). I did not go much further than that, but would definitely be interested if we can collaborate.
ArduPilot has a “throw” mode, maybe we can learn from it even if it seems very experimental! See http://ardupilot.org/copter/docs/throw-mode.html
I noticed the free fall boolean when going through some data on drop tests I collected, and was curious where that had fed into the firmware. Needless to say I got very excited that a chunk of the project had already been completed, and then went on to find this topic. I will try and do a breakdown for the ardupilot code very soon. I have a report deadline on this due for Sunday so providing I get all my initial findings written up, it would be nice to add a breakdown of the ardupilot code to it. Then I will move on to getting my head around the commander module and hopefully get something to work in HITL.
Found another similar project being ran on the crazyflie seems pretty basic.
https://forum.bitcraze.io/viewtopic.php?t=1584, yet to look at it properly but look at it properly but as far as I am aware the crazyflie typically runs PX4.
UPDATE: Have made significant progress on the code, it has been a very simple case of editing land detection. I am not sure how the module will be controlled by Qground control yet, if someone could provide some in sight into how this is done that would be great. Otherwise for first test I will rely on execution via the terminal.
@Ethan_Bond would be happy to help if you can open a pull request against PX4/Firmware with your changes.
Having looked at my code for ages, I am going to scrap it, and integrate the logic into the commander loop as previously suggested, it was hideously overly complicated as I took modifying the land_detection too literally. Shouldn’t take more than a day or so.
I did a lot of modifications to the program again, came up with something that essentially performs the hold mode when thrown, using acceleration in z as the trigger. The only issue is it doesn’t like being thrown above 0.5m, it begins to break the fall, do attitude correction, then kills the thrust out to 0, then back to 100 then back to zero and so on randomly until disarmed. If you have any ideas I would love to know.
Here are my test results with regards to throw height didn’t manage many before an ESCs got fed up, I performed the tests on a 250 racing quad with pixhawk cube 2.
What you need to do is let the land detector back off from disarming for a couple of seconds after you armed the system via the commander. Are you updating the system status to armed? I think at this point a pull request and logs (http://log.px4.io) are required. That will make it easy to have a technical discussion.
