3 3
df8m1

New AAD made in USA

Recommended Posts

yoink

***
If I were looking to buy an AAD, I would look for a unit that would not fire in a plane or get confused, and I would be curious as to how it was able to do that.



It's an interesting exercise that people should try... What are your priorities for an AAD?

Personally, my first one is that is must not fire when it shouldn't. Second is having no unsafe failure modes.
Third is firing when it should...

those are mine. What are yours?

One of my priorities is the ability for ME to set the activation altitude above a minimum. I can't understand why stock units are set to fire at 750 ft. The Vigil II+ can be set higher as I understand. My lowest opening was at 1200 ft way back when. That was pretty damned scary.

Share this post


Link to post
Share on other sites
katzas

******
If I were looking to buy an AAD, I would look for a unit that would not fire in a plane or get confused, and I would be curious as to how it was able to do that.



It's an interesting exercise that people should try... What are your priorities for an AAD?

Personally, my first one is that is must not fire when it shouldn't. Second is having no unsafe failure modes.
Third is firing when it should...

those are mine. What are yours?

One of my priorities is the ability for ME to set the activation altitude above a minimum. I can't understand why stock units are set to fire at 750 ft. The Vigil II+ can be set higher as I understand. My lowest opening was at 1200 ft way back when. That was pretty damned scary.

You can set the altitude on a Cypres also.
Don't know about M2.

Share this post


Link to post
Share on other sites
df8m1

This unit, like it's military counterpart, will be intelligent, and will not fire in the aircraft regardless of descent rate and altitude, or to say it another way, it will not arm until after exit from the aircraft.



I'm a bit leery of this function. Seems to me that there is a very narrow window between a descent in the plane and a quick clear & pull. Especially for parachutes which open relatively quickly, such as dircect-bag Static-line systems and CReW canopies.
I'd be worried that the AAD couldn't tell the difference.
"That formation-stuff in freefall is just fun and games but with an open parachute it's starting to sound like, you know, an extreme sport."
~mom

Share this post


Link to post
Share on other sites
lyosha

The thing is it doesn't take a whole new AAD to do a really simple job - measure barometric pressure and fire when it detects enough speed at low enough altitude.



If that is all an AAD had to do then yes, it would be simple. It is all of the exceptions that make it complicated.

For example, what is "freefall" speed? We have wingsuits and canopies flying with each other now. It's complicated.

Share this post


Link to post
Share on other sites
peek

***The thing is it doesn't take a whole new AAD to do a really simple job - measure barometric pressure and fire when it detects enough speed at low enough altitude.



If that is all an AAD had to do then yes, it would be simple. It is all of the exceptions that make it complicated.

For example, what is "freefall" speed? We have wingsuits and canopies flying with each other now. It's complicated.

Good point - I would want the ability to change my freefall speed. When I wingsuit, I may not reach the ~80 mph required. Honestly, I've been thinking of switching the thing to student mode for wingsuiting, but would really prefer ~50 mph.

The other thing that I want to be able to do is to download the data from the unit - see what it sees.

Share this post


Link to post
Share on other sites
lyosha

******The thing is it doesn't take a whole new AAD to do a really simple job - measure barometric pressure and fire when it detects enough speed at low enough altitude.



If that is all an AAD had to do then yes, it would be simple. It is all of the exceptions that make it complicated.

For example, what is "freefall" speed? We have wingsuits and canopies flying with each other now. It's complicated.

Good point - I would want the ability to change my freefall speed. When I wingsuit, I may not reach the ~80 mph required. Honestly, I've been thinking of switching the thing to student mode for wingsuiting, but would really prefer ~50 mph.

The other thing that I want to be able to do is to download the data from the unit - see what it sees.are you sure you understand how your AAD works ?:o
scissors beat paper, paper beat rock, rock beat wingsuit - KarlM

Share this post


Link to post
Share on other sites
piisfish

***

Good point - I would want the ability to change my freefall speed. When I wingsuit, I may not reach the ~80 mph required. Honestly, I've been thinking of switching the thing to student mode for wingsuiting, but would really prefer ~50 mph.

The other thing that I want to be able to do is to download the data from the unit - see what it sees.

are you sure you understand how your AAD works ?:o

I assume lyosha is talking about either a loss of altitude awareness wingsuit flight, when the pilot passes below 750ft in full flight, or in a "where's the hacky" fumble position where the descent rate will be higher, but not 78 mph. What were you thinking he meant?
It's flare not flair, brakes not breaks, bridle not bridal, "could NOT care less" not "could care less".

Share this post


Link to post
Share on other sites
Skydivesg

OK yeah I've heard of that. Both Cypres and Vigil have had those problems but usually fix them very quickly.

Those are electronic component problems which usually manifest themselves during boot up.

My question is about the unit being "confused" as to what it was sensing and then just froze up. I believe that is what df8m1 meant in his post.



Yes you are correct in what I am referring to. That "deep thought" is mainly based on the operational principals that a system, solly based on barometric reference, will have the tendency to do if it is pushed beyond its settings. And as I said, with device that can kill you, if it screws up, and does not know where it is, it should stop.

There is a good discussion, although totally hypothetical given only a hand full of people really know the code that the other AADs run on, about how the single channel AADs make decisions, and determine if it needs to fire. After the "incident", Airtec adjusted some values to try and keep the Cypres code from getting confused, however they would not have abandoned the code that is susceptible to this problem.

Not to say that a multi channel platform could not also have its issues, as every device that will ever be built will have, but having the ability to cross reference other channels greatly bolsters the awareness.

The trick is keeping the complex as simple as possible. That being said, a single channel platform is as about as simple as you can get, and I tip my hat to the manufacturers that have figured out a way to get the AADs that are on the market to work as good as they do, and I mean that sincerely. It is a lot easier to make informed decisions when you have more information to work with, but it is easy to dround in information after a point. There is a balance.

Share this post


Link to post
Share on other sites
lyosha

***Their unit will be the first of a totally new generation of AAD's which over come all of the processing and firing issues that we have seen up till now.



This scares the shit out of me. The reason I don't use a Cypres and instead use a Vigil is because of Cypres's "trust us, our black box knows best" attitude that's certifiably gotten people killed already. At least with a Vigil I know exactly what the behavior is, and adjust settings as I see fit.

The thing is it doesn't take a whole new AAD to do a really simple job - measure barometric pressure and fire when it detects enough speed at low enough altitude. So why do I need to know that my AAD just recalibrated? Are you solving a problem that doesn't exist?

Often a drowning person will overcome their rescuer and they both end up drowning... now and then I will get messages from newer jumpers, (at sea level), after they receive their new altimeter, saying that it is a piece of crap because it reads 11,000Ft and not 0, ( I am at 980MSL). They rant and rave saying they are going to tell everyone yada yada.. I take a breath, and start to enplane how the altimeter works and that it was zeroed at 980 MSL and that they are very close sea level, so the altimeter is indicating a loss of 900+ft (+-) weather...

The response is usually... Oh!..... sorry... I did not understand how it worked.... thank you so much for your patience...

Share this post


Link to post
Share on other sites
SethInMI

******

Good point - I would want the ability to change my freefall speed. When I wingsuit, I may not reach the ~80 mph required. Honestly, I've been thinking of switching the thing to student mode for wingsuiting, but would really prefer ~50 mph.

The other thing that I want to be able to do is to download the data from the unit - see what it sees.

are you sure you understand how your AAD works ?:o

I assume lyosha is talking about either a loss of altitude awareness wingsuit flight, when the pilot passes below 750ft in full flight, or in a "where's the hacky" fumble position where the descent rate will be higher, but not 78 mph. What were you thinking he meant?

If even that. I have more than one friend that believes their AAD will not fire in their medium to big wingsuit because their descent rate will not be fast enough if they are unconscious. Because I feel that's the real issue AADs are trying to solve, not altitude awareness.

Come out with "wingsuit" mode for an AAD and I feel you have a niche market.

Share this post


Link to post
Share on other sites
Baksteen

***This unit, like it's military counterpart, will be intelligent, and will not fire in the aircraft regardless of descent rate and altitude, or to say it another way, it will not arm until after exit from the aircraft.



I'm a bit leery of this function. Seems to me that there is a very narrow window between a descent in the plane and a quick clear & pull. Especially for parachutes which open relatively quickly, such as dircect-bag Static-line systems and CReW canopies.
I'd be worried that the AAD couldn't tell the difference.

Yee of little faith lol... Would you be surprised to know that the first test jumps I did were clear and pulls? On average, it has taken from 1/4 to 3/4 of a second to detect an exit, for the sake of everyone in the plane, I hope you are not pulling that fast lol...

This is not our first Rodeo, we are jumpers with probably close to over 40 combined years in the spot and around 6000 combined jumps, over 3000 tandems, and not sure on how many AFF and Video jumps.

We have designed and build data collectors specifically for parachute operations, and have studied the data from many different types of exits, including static line. We have fulfilled a contract with the US military to build some prototype Static Line AADs for Paratroopers exiting at 525Ft AGL. We are currently ironing out the details on the next phase of the process.

The "Exit Profile" as we call it, is a very specific thing. Can't go into more detail than that at.

Share this post


Link to post
Share on other sites
df8m1

After the "incident", Airtec adjusted some values to try and keep the Cypres code from getting confused, however they would not have abandoned the code that is susceptible to this problem.



Thank you for your explanation. Make no mistake - I am glad that you have decided to get into the mix and if you can come up with a better AAD then I for one say go for it. I'm not your typical "naysayer"

You reference the "incident".

Is it safe to assume it was the "C-130 incident"?

Please excuse me for being so focused (I often have a very simplistic mind) but it bugs me to watch news interviews when the reporter asks a question and then allows the interviewee to talk about everything but never actually answer the question.

My very simple question is:

"When is the last time an AAD got confused and locked up"?
Be the canopy pilot you want that other guy to be.

Share this post


Link to post
Share on other sites
lyosha

*********

Good point - I would want the ability to change my freefall speed. When I wingsuit, I may not reach the ~80 mph required. Honestly, I've been thinking of switching the thing to student mode for wingsuiting, but would really prefer ~50 mph.

The other thing that I want to be able to do is to download the data from the unit - see what it sees.

are you sure you understand how your AAD works ?:o

I assume lyosha is talking about either a loss of altitude awareness wingsuit flight, when the pilot passes below 750ft in full flight, or in a "where's the hacky" fumble position where the descent rate will be higher, but not 78 mph. What were you thinking he meant?

If even that. I have more than one friend that believes their AAD will not fire in their medium to big wingsuit because their descent rate will not be fast enough if they are unconscious. Because I feel that's the real issue AADs are trying to solve, not altitude awareness.

Come out with "wingsuit" mode for an AAD and I feel you have a niche market.

Got it covered, and no special mode needed either lol.. Wing suits are of interest to the Military as well.

Like I said, there is a lot that people do not know yet and in due time.. I watched the video of the BPA seminar that Tom Nonnan put on, and as I listened to him describe the limitations of the AADs on the market, I was checking the list of operational features this AAD will have..

Lee has a lot more information that anyone else aside of the military, and we did not tell Lee everything lol...

Share this post


Link to post
Share on other sites
Skydivesg

*** After the "incident", Airtec adjusted some values to try and keep the Cypres code from getting confused, however they would not have abandoned the code that is susceptible to this problem.



Thank you for your explanation. Make no mistake - I am glad that you have decided to get into the mix and if you can come up with a better AAD then I for one say go for it. I'm not your typical "naysayer"

You reference the "incident".

Is it safe to assume it was the "C-130 incident"?

Please excuse me for being so focused (I often have a very simplistic mind) but it bugs me to watch news interviews when the reporter asks a question and then allows the interviewee talk to about everything but never actually answer the question.

My very simple question is:

"When is the last time an AAD got confused and locked up"?

Yes again :), I am not sure if the, what I call the "incident" lol, where the Vigils fired and the Cypres units shut down I think, was at the WFFC or the record attempt. I recall issues at both, just not sure of the order of progression. I also recall issues at the WFFC, specifically with the helicopter ride causing AADs (do not recall if it was just one manufacture or not) to lock up or shut down because they saw parameters outside of their logic values.

I would have to guess that the record attempt was the most recent of the events that I am aware of.

I did not mean to imply that has happened recently, only that it is a characteristic that the AADs have demonstrated they are capable of.

It is the "potential" for a problem that I have to keep focused on. If I dismiss that "potential" just because its chance of occurring is low, then I open the door to it happening, and should it happen then the results are not something that I am comfortable with personally.

During testing, on occasion, we see a situation that we did not expect to see, and could not duplicate again if we wanted to, but, after it occurred, we have to address it, even if odds are that it will never happen again. I am sure the other AAD manufacturers have a similar mind set.

By recording the data that we do, we have a record of what happened, and we can rerun that data through our simulation program and make changes to address it, and then rerun all the other normal data to be sure that the change we made to address the strange event, did not negatively affect the operation of the device in any way.

How an AAD addresses the "potential for" situations is what separates it from just a device that "measures pressure" as a previous poster implied that is all an AAD needs to do. Not to knock him, not many people truly know about how these things work, let alone develop one..

No need to apologies about being focused lol... I think Peer review is a critical aspect in product development. If I can not properly address a question or concern, then I have a problem that I need to address lol..

If I do seem to be "avoiding the question" it is usually because I either do not understand the question as the poster intends, or I am having a difficult time trying to articulate my thoughts in a manner that thoroughly address the concern posted.. Should that take place, please feel free to point that out and I will take another stab at it. :)

Share this post


Link to post
Share on other sites
Can you comment on the sensor types you will be using in your multi-channel approach? I think accelerometers are most likely, and GPS unlikely? How about a 3 axis gyro?

One problem that accelerometers may address is the burble issue. Overcoming the difference in firing heights between belly and other orientations would make people more comfortable about increasing their firing altitudes.

Using sensor fusion could also prevent/reduce two-outs by realizing that the characteristics of a deployment sequence were already in effect, and ignoring or delaying the activation sequence (still have to fire in a bag lock). I think this would also make people more comfortable in increasing firing altitudes.

Seth
It's flare not flair, brakes not breaks, bridle not bridal, "could NOT care less" not "could care less".

Share this post


Link to post
Share on other sites
The last WFFC on the jet IIRC.
Prior to them understanding the way the pressurization of the aircraft would work, which was quickly followed by seeing a LOT of folks sporting the t-shirt "Cypress rocks, Vigil pops"
:D:D:D

Share this post


Link to post
Share on other sites
df8m1

Lets see if I can fill in some gaps that I have created...

***

I've heard about some of the things they are doing on their military unit and if they include the same technology in the civilian version it will leave all of it's competitors behind in the dust.



yoink


But equally there has to be a cost / benefit cutoff. Already an AAD is often seen as a 'nice to have' bit of kit because of its price point. If cutting edge technology for only minor benefits drives the price up you may see it being difficult to get a large uptake.



The purchase price for this unit would be equal to the Cypres, even with all the additional internal sensors and such. What goes on under the cover will be very different however, with the processor looking at 10 channels of data at a sample rate of about 4 times faster that the Cypress or Vigil, not sure what the Mars sample rate is.

The cost of service is TBD. I see that as a double edged sword in that, like with your reserve that has to be repacked by a rigger, and most of us have to pay to have that done, the manufacturers of the rig don't cover that. And, at the same time, seeing the units ever 4 years allows us to catch problems and address then before they become a problem, and that I think is something that benefits us, so why should the customer have to pay for our quality control program?

The units will be put through a rigorous validation process every time they are sent in, and that will take some labor and ware and tare on the equipment, which could be argued as the cost of doing business, and with any cost, it would be passed on to the consumer. Lets just call this TBD :)

yoink


Take the data logging for example - is that really necessary? Or is it a function with only limited benefit to the user but will increase the cost? Personally, if I had the option not to have that functionality and decrease the cost I'd probably go for that...



The black box is not for "data logging" as traditionally understood. The jumper will not have access to the SD card as it will be packed in the reserve container. This unit will use the data recorder to provide it self with the senses needed to determine the conditions it is in, which we call "Situational Awareness". With it being situationaly aware, it can make decisions based on the conditions it is sensing.

One example of situational awareness is having to land in the plane. Every AAD on the market will fire if the pilot descends to fast (provided exceeded the arming altitude). Because my AAD is/will be, aware that it is still in the plane, or more correctly stated, it knows it has not exited the plane, it will not fire when it detects the high descent rate at the magic altitude.

The data that is stored will be useful for post accident analysis, and will provide us with a record of its operation between service intervals.

AADs are meant for a specific purpose.. I have data recorders if anyone wants to "collect data".

yoink


I like my AADs simple. Simple to set up. Simple to use. Simple when they function...
My requirements are probably very different from the military ones.



The military wants them to be simple too lol... Your requirements are different than the military, that is why there will not be any WiFi to download the data. There also won't be a self destruct feature...

yoink


I'll be really interested to see what David and his team come up with.



Personally, I am very reluctant to do anything non Government, but I am confident enough in this unit that I have let several people of whom I greatly respect convince me that the liability can be mitigated.

A bit confused by this since CYPRES handles a large amount of military contracts. They also deal with those very specific demands.
Life is all about ass....either you're kicking it, kissing it, working it off, or trying to get a piece of it.
Muff Brother #4382 Dudeist Skydiver #000
www.fundraiseadventure.com

Share this post


Link to post
Share on other sites
The events to which you are referring happened almost 9 years ago. It is my understanding that both companies have since updated their firmware.

As I stated, I'm glad to see and welcome more evolution in our sport, be it EPs, flying techniques or gear. But I believe we more experienced jumpers owe it to our newer younger jumpers, to be more careful when we post on public forums.

I do a lot of load organizing around the country which means I often hang and jump with newer jumpers at grass roots DZs - many of these people started jumping in the last 3-5 years. It is shocking to hear them talk about things they "heard from someone". It is often stuff that is totally false or something that happened years ago, even decades ago, (especially gear related) and has since been resolved.

I encourage intelligent civil debate but let's not forget the many newer jumpers who read this stuff, may not realize or can't differentiate the context, and then suddenly start questioning the reliability of their chosen gear.

For everyone with less experience or knowledge; I suggest you read these forums with a grain of salt and choose your mentors carefully. And don't be afraid to question their advice. If they are a decent mentor they will not take offense but instead be willing and able to convey how they came to their conclusions.
Be the canopy pilot you want that other guy to be.

Share this post


Link to post
Share on other sites
Quote

During testing, on occasion, we see a situation that we did not expect to see, and could not duplicate again if we wanted to, but, after it occurred, we have to address it, even if odds are that it will never happen again. I am sure the other AAD manufacturers have a similar mind set.

By recording the data that we do, we have a record of what happened, and we can rerun that data through our simulation program and make changes to address it, and then rerun all the other normal data to be sure that the change we made to address the strange event, did not negatively affect the operation of the device in any way.



This is very interesting to me as ultimately AADs come down to the software logic that interprets data and then executes functions based on parameters being met to trigger the action. In large part, having a big enough data set to be able to pattern the "possible" scenarios is a pre-req to having software logic that can be written to operate in that environment.

One of the advantages I could see to a black box that tracks fine grain data points across multiple channels on an SD card is that when a unit comes in for service that data can be collected and added to The Database of all readings recorded by all known units. Even after just a few years the dataset would be absolutely huge and make it much easier for software analysis to identify the one in a million type events that may or may not be accounted for in the software program.

Is this already common place in the AAD market? Is this something that the new product in question would do? The big data nerd in me is interested in what kind of analysis one could do on that much information.

You could potentially move towards a type of solution that makes the AAD so smart that you wouldn't have to worry about setting it to different modes for different activities. Given software that is mature enough and real time data that is good enough, the AAD could look at when you're doing and then adjust itself accordingly. IE if you're swooping it should know what sensor data for a swoop looks like and follow AAD swoop logic. or [insert discipline here]. That would be a truly smart device!

edited to add: i come from a software background but don't have much insight into how the software for current AADs works so if all this stuff that is novel and exciting to me is old news to everyone else my apologies in advance lol

Share this post


Link to post
Share on other sites
3mpire

***Is this already common place in the AAD market?



I do not know about any other AAD but it is common for CYPRES. Data is recorded during maintenance and updates are made based on previous changes. This is another reason I am a fan of the maintenance CYPRES does and not a fan of not utilizing these intervals.
Life is all about ass....either you're kicking it, kissing it, working it off, or trying to get a piece of it.
Muff Brother #4382 Dudeist Skydiver #000
www.fundraiseadventure.com

Share this post


Link to post
Share on other sites
If your interested in the software and how these units work you would have enjoyed the lectures at PIA. Does any one know if they were recorded? The Vigil High speed unit lecture as an example was very good and gives a lot of insight into how the unit functions and the differences and limitations of the operating modes. Is there a document available from Vigil or a recording of the lecture on you tube or Skydive TV?

Lee
Lee
lee@velocitysportswear.com
www.velocitysportswear.com

Share this post


Link to post
Share on other sites
SethInMI

Can you comment on the sensor types you will be using in your multi-channel approach? I think accelerometers are most likely, and GPS unlikely? How about a 3 axis gyro?

One problem that accelerometers may address is the burble issue. Overcoming the difference in firing heights between belly and other orientations would make people more comfortable about increasing their firing altitudes.

Using sensor fusion could also prevent/reduce two-outs by realizing that the characteristics of a deployment sequence were already in effect, and ignoring or delaying the activation sequence (still have to fire in a bag lock). I think this would also make people more comfortable in increasing firing altitudes.

Seth



All instruments will be digital MEMS, 3-Axis Accelerometer, 3-Axis Gyro, 3-Axis Magnetometer, and Absolute Pressure, 10 total channels.

In a static application, an Accelerometer can be used to determine orientation, but in a dynamic application, as this is, it is extremely difficult to discern movement from orientation with only one 3-Axis Accelerometer.

A Magnetometer on the other hand is not influenced my inertial forces, but rather magnetic forces, so it will indicate orientation changes based on a magnetic reference (the earth in this case).

My “goal” is to reduce the belly to earth, vrs back to earth, indicated altitude differential to around +- 70 ft as apposed to +- 200 ish ft.

In regards to your two out due to a higher activation altitude... My philosophy is based on the idea of a "canopy over head" altitude, not an activation altitude.

I want to have a conopy over head by X ft, (which will be adjustable), and most of us know that it takes some time from pin extraction to canopy inflation, and given that, the distance the jumper will fall during that time is directly related to the speed that the jumper is falling. As such, given that I want a canopy over head by X and it takes X time for the canopy to deploy, then the AAD will need to initiate reserve pack opening at X ft at X speed. Now if the jumper is falling faster, then the AAD will need to start the process sooner in order to allow for a canopy over head by the desired altitude.

Now, lets say that "BUBA" is a rather large individual, and tends to fall fast. And he is a safty conchous jumper so he set his canopy overhead height a little higher to give him more time to deal with a new canopy prior to having to land it off airport.

One day he is really falling fast and gets lost in the beauty of the sun setting, losses track of altitude, and goes a little deeper than he normally does and pitches his main pilot chute. Now keep in mind that he has set his canopy over head altitude higher, and because of his higher descent rate, the AAD will initiate reserve pack opening sooner, so it is very possible that he may snivel right through the corrected firing altitude, resulting in a two out situation.

Fortunately for him, his AAD detected his main deployment soon enough, and delayed reserve pack opening to allow the main a chance to inflate, but, if his descent rate is still above X at the X hard deck altitude, it will initiate reserve pack opening in a last ditch effort to slow him down to a survivable speed prior to meeting the earth.

Like I said, this is an intelligent AAD or Smart AAD if you rather, that is Situationaly Aware throughout the entire jump. There needs to be a consciences amongst the instrumentation that an action is warranted, be it to fire or not to fire. With only one channel (pressure) it is very difficult to “confirm” that the conditions are what they are, and it takes time to create a history so to speak, that indicates the conditions. That is why rapidly changing events tend to “confuse” single string logic (just made that term up, but it think it describes what I am trying to convey).

I can get feed back from 10 channels every 20th of a second, allowing a fast, but more importantly confident reaction or lack there of depending on the conditions as a whole.

I was not going to go into that just yet, but since you brought it up I thought I would fill in a few more gaps..

Additionally and consistent with this train of thought, there is an internal debate here about if the AAD should fire directly after a cut away. That is, to fire before the jumper reaches the trigger descent rate. My personal opinion is that I am pilot in command, and if I start the main deployment sequence on my own, then it is up to me to make the proper decisions regarding emergency procedures. I do not like the idea of an AAD taking action when I have consciously decided to delay action for what ever reason. Now if I do not start the main deployment sequence on my own, then that is where the AAD can take action for me with my blessing, as I have not demonstrated that I am capable of action on my own.

Any thoughts?

Share this post


Link to post
Share on other sites
Thank you very much for your explanations
This Thread has to rank in the " Most Excellent " catagory............it's nice to enjoy a thread with out all the BS that the armchair designers do to Bill Booth and John Sherman...thanks again and good luck,,,i'll buy it.
smile, be nice, enjoy life
FB # - 1083

Share this post


Link to post
Share on other sites
Quote

My personal opinion is that I am pilot in command, and if I start the main deployment sequence on my own, then it is up to me to make the proper decisions regarding emergency procedures. I do not like the idea of an AAD taking action when I have consciously decided to delay action for what ever reason. Now if I do not start the main deployment sequence on my own, then that is where the AAD can take action for me with my blessing, as I have not demonstrated that I am capable of action on my own.

Any thoughts?



I think it's fascinating to have a smart AAD that can react to real time data in that fashion.

One of the benefits of having that is you have additional avenues open to you in terms of the AADs logic tree.

I think a user defined hard deck that can be overriden by software logic that detects a deployed main is great.

I wonder though about the last bit. It's one thing to take objective data and plot a course of action that is easy to infer like the sniveling past hard deck example.

But in the case of the AAD needing to take or not take action based on whether the jumper has "consciously" decided to take some kind of action that deviates from a "plan a" scenario, I wonder how accurately software could divine intention from raw data?

You have the data so you know what the sensor data would look like for these scenearious far better than I would.

But from a strictly code point of view, there is a danger in programming your way into a scenario labyrinth where the increasing number of facets in a tree create a logical problem big enough that your code is going to have to account for a LOT of things.

Perhaps given proper test cases and a large enough data set you could in fact reliably diving "intention" from data, but that seems like it would require very reliable data.

SO the question to you would be: How confident are you that the program could tell the difference between someone who is intending to do something and someone who is not? That could be a slippery slope....?

edited to add: thinking about it a little more, perhaps focusing on the data patterns that indicate a certain thing is happening and not caring about the "scenario" that caused it to happen would simplify things quite a bit. but the sticky bit of deciding whether that pattern of sensor data implies intent is still problematic in my mind.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account. It's free!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
3 3