Dear reader,
We are now live at www.skycat.pro. The development project continues, and updates are added to this blog in random intervals.
We have parachutes launchers available in many weight ranges; optimal 1 - 6 kg and these could be extended with higher impact level up to 11 kg. For larger up to 23 kg multicopters we have XL - series with pilot chute principle.
For those who wants to digest all information available of products, we have left this blog as it is. This blog follows closely main steps we have gone through while developing parachute launcher. Blog might feel like Do It Yourself kind and to be honest, in the beginning it was.
After hundreds of hours thinking, designing, prototyping and testing our patent pending launcher turned to be the most reliable parachute launcher for professional use. We have searched all possible boundaries of technology and from this blog you'll find results of these successful tests but also not so successful tests.
You never know where The final limit of technology is without experiencing it. That's the reason why we have done tests for scenarios which might not be even realistic on flight.
For production versions of Skycat we could proudly to say that we have experienced zero mishaps, never failed a single eject and parachute has deployed every time. This includes rescue scenarios with every imaginable scenario copter could face in air. Check this out as one sample of our test sessions!
Skycat parachute launcher has been tested beyond all imaginable abuses copter possibly could experience in flight. We have sink it to water, it has been heated hours to 90°C and exposed to extensive moisture, we have frosted, defrosted and frosted it again, it has been in mud and snow and still it has worked. Same overshooting tests we have done also for electronics. This is not promise you can use our products outside of submarine but we have tested it so :)
This blog will still be updated as well our Facebook pages www.facebook.com/skycat.pro and Twitter at https://twitter.com/skycatpro
Fly safe - Let's keep our copters flying!
Henri
Skycat.pro
DJI Inspire 1 / Skycat X55-CF parachute integration by www.remotevision.ch:
Other documentary videos:
OPENTX for parachute eject and 6POS switch
DUAL spring loaded switches - single RC channel for parachute eject, OPENTX
Ground eject demonstration in slow motion
Aerial test No 2 for Opale Paramodels 2.5m^2 parachute
Aerial test No 1 Opale Paramodels 1.8m^2 parachute
Manufacturers contributed to this project:
- http://www.opale-paramodels.com/
Replies
hello, you already finished the hardware of deployment system?
Hi Stefhan,
Original summer 2014 deadline sounded long in the beginning but now it looks close to realistic. First mechanics to be finished is for 2.5m2 / 4.0m2 / IFC-60-S parachutes.
Original goal, mechanics for larger copter/parachutes requires a lot more testing and iterations.
Reliability target is set really high here.
Some updates,
While studying Taranis and OpenTX a little deeper I found with help of Kilrah few useful functions for this project. These are useful especially for those who doesn't use flight controller with parachute support. And is compatible with servo or I/O trigger.
In nutshell it is like this: When copter is out of control, pull front finger switches up and parachute is ejected and motors shut down. That's all.
Some details what happens:
- eject parachute using dual switches.
- if only one switch is active, radio gives "parachute switch warning" at interval of 5 sec as long as switch is cleared. This warning sound is in use because another switch is not spring loaded and could be left accidentally to active position
- when both switches are active (front finger switches here) starts following steps along with "Parachute ejected" voice
1. Throttle to zero ( force PWM range to -100)
2. Force flight mode to stabilize (force PWM to -84) from any flight mode selected with 6POS switch
3. Timer of 30 secs for allowing flight controller to unarm during descent before 30 sec delay is over
This is tested dozens of times from any imaginable mode on table since yesterday implementation and drop tested three times; once from ALThold and twice from Loiter. So far it looks really good and I'm planning to use it with all drop tests until APM is ready for testing.
Video for setting this up is going to be uploaded to Youtube some day in near future.
There is new video on a header. It represents steps needed to setup two spring loaded switches for one RC channel for parachute eject using OPENTX firmware. This is meant to lower a risk for accidental eject in human error.
NOTE, consider twice setting double switch up if your flight controller is not able to shut down motors in case on parachute eject from any flight mode and any flight situation.
I know from experience; any extra step might be too much in real situation even you have practiced dozens of times and you are well prepared and you know eject to be happened within seconds.
Switching panic switches must be based on reaction on low altitudes.
The AP_Parachute library is now in master so it will go out with AC3.2. All feedback welcome!
The chute will be automatically triggered if all the following are true (it can also be released manually – see ch7/ch8 options below):
a) The CHUTE_ENABLED parameter is set to 1
b) Vehicle’s desired roll or pitch angle are off from the actual angle by at least 30degrees for 1 second
c) Vehicle is above the CHUTE_ALT_MIN
d) Vehicle is not landed
e) Motors are armed
f) Mode is not ACRO or FLIP
When the chute is triggered, it will play a short trill for 0.5seconds and then the parachute will be released. A message is sent to the ground station (which appears on the HUD in the mission planner) and an event is written to the dataflash logs.
To set-up the chute to be released via a Relay:
CHUTE_TYPE : 0 = First Relay, 1 = Second Relay, 2 = Third Relay, 4 = Fourth Relay
Then set the RELAY_PIN, RELAY_PIN2, RELAY_PIN3 or RELAY_PIN4 parameter to the appropriate pin. So to associate “First Relay” to an APM2’s Pin A9 set the RELAY_PIN parameter to 13. We will need to fill out the parameter descriptions for these to make it easy for people to select the pin.
To set-up the chute to be released via a Servo:
CHUTE_TYPE: 10 (means trigger via Servo)
RCXX_FUNCTION : 27 (where “XX” is the servo number, ie. RC10_FUNCTION)
CHUTE_SERVO_ON: the PWM position that the servo should be when the parachute is released
CHUTE_SERVO_OFF: the PWM position that the servo should be when the parachute is in its resting position
The chute can be activated using Ch7/Ch8 switch by setting CH7_OPT or CH8_OPT to one of the following:
21: parachute enable/disable. This simply enabled/disables the auto-release of the chute.
22: parachute release. The chute will be released when the switch is put high.
23: 3-position parachute disable/enable/release. Low will disable the chute, medium with enable the auto deployment, high will release the chute.
Just made quick view and it looks good!
How long output is kept HIGH when parachute is triggered or is it adjustable?
1 sec waiting time might be something that needs attention. My copter experienced 150m fall and it took about 7 seconds. Copter flipped if I remember correctly 11 times during the fall because copter tried to stabilize and one propel was missing. So it wasn't beyond the limit over 1 sec at all.
I managed to do double switch trigger using a single receiver channel on last weekend. Both switches are now spring loaded so accidental hit to cameraman jacket or any obstacle and switch doesn't eject a chute if only one switch is activated.
Instructions for 9XR are coming to youtube some day. Instructions applies to OPENTX and perhaps ER9X as well.
Henri,
The output is kept high for 1 second. It's possible to change the check so that the counter ramps down to zero when the desired angle and actual angle agree. This would mean that it wouldn't need to be one consecutive second of bad control but rather 1 second over 2 seconds.
I've tried to add checks that will stop it from releasing unless it's in the air including the min-alt check and the landing check. The nightmare scenario is it going off in someone's face someday.
Hi,
I believe that Henri was asking was only related to the parameter AP_PARACHUTE_RELEASE_DURATION_MS. And since I had a more than exepected deep look into the great job you did.
Maybe i'm wrong, but I think we could change (a little) the logic in AP_Parachute::update(). I don't like the AP_PARACHUTE_RELEASE_DELAY_MS and I think it should be removed because you already take a delay in the crash_check.pde with parachute_check() in case the copter looses control. The PARACHUTE_CHECK_ITERATIONS_MAX is doing this job in crash_check.pde.
For the manual_release, I did not find what part of code is casting parachute_manual_release(). Maybe we can send the gcs message as soon as the CH7/8 is activated and make a counter similar to what is done in crash_check?
It is of course not a good idea to shoot a parachute to someone's face, but some people will need to check that the parachute Servo is on the proper position to release a parachute, or at least to check PWM values for the ON/OFF position with a disarmed parachute.
Thanks again Randy!
Remark:
in crash_check.pde (94), the comment should not say "or pilot throttle above 0".
Manu,
Thanks for reviewing the code and providing feedback.
The manual_release code can be found in control_modes.pde. It's a badly named file, I'm planning to rename it to switches.pde. Try searching for "PARACHUTE" in that file.
I agree that there are a number of delays in the system:
a) one second delay in parachute_check() while vehicle figures out if attitude is bad
b) 0.5 second delay in AP_Parachute's update() while it plays the alarm tone
c) actual delay in physical parachute deployment.
For a manual release the GCS message and warning tone should happen as soon as the pilot moves the switch. (a) is skipped because that's only for the auto-detection of a loss of control.
For the auto-release, I have been thinking about sounding the alarm sooner than 1second. So perhaps after 0.5 seconds of bad attitude. That might lead to false alarm tones but would also give the user a bit more of a warning.
(c) is controlled by the parachute release manufacturer so there probably isn't much I can do about that unless there is a good interface (like I2C or serial) so that the flight controller can send it a message after (a) and before (b). Maybe we could allow removing (b) if the physical release mechanism takes a long time.
Ok, I found it!
I like the idea of fast alarm when attitude is bad, not only for the parachute reason. What I propose is to remove (b), so we can get. Instead, we can add a boolean like parachute.ManualReleaseHigh set to true when 2/3 pos switch are checked in control_modes.pde. Then, in crash_check we can add a counter to check if ManualReleaseHigh stays high for a "manual iteration max", and then trigger the parachute.release, and we can send immediately (let's say 3 iterations) the message. This is more or less equivalent to what is done faster for the radio throttle failsafe.
If we do so, in the AP_Parachute, the releasing action which is in update() should then be in release(), and update() be only dedicated to switching back relay/servo to non-release position.
In any case, I think that the delay (c) is not a problem here, the ejection system should be design to act as fast as possible (pyro/servo/gaz/whatever), but we cannot change the time it will take for the parachute to completely deploy.
-
15
-
16
-
17
-
18
-
19
of 26 Next