- Joined
- Nov 6, 2018
- Messages
- 1,103
- Reaction score
- 1,013
- Age
- 58
- Location
- DFW Metroplex
- Website
- orbisdroneservices.com
I'm thinking delete it off the post.
You should really delete your video on Youtube because it demonstrates how to do this exactly the wrong way. Anyone who watches and tries it will crash their H. I would feel a sense of guilt knowing that I mislead someone who watched it and crashed.
I think you titled it "ST16"I am confused. What video
Is misleading ?
I pretty much lean towards DCJ’s second to last paragraph. Its not difficult to imagine someone “exploring” their system and tapping “buttons” without understanding potential ramifications. They would not be aware they had done something wrong. Unfortunately, Yuneec does not provide any documentation about how to do it at all, the right way OR the wrong way.
I believe the vast majority of owners want to do things right and take advantage of everything their system can deliver. That becomes pretty hard to accomplish when a manufacturer withholds critical system info from the owners so the owners start experimenting. Some succeed in getting everything right but many, especially those without extensive previous RC transmitter experience, fail. It falls to forums such as this that help them work things out.
That’s largely why I said chit happens.
OkI think you titled it "ST16"
Was the video part of the OP's ordeal?
I passed over the video as no revelance, I hadn't read any reference video was associated to the OP's interaction... koolaid & popsicles.
If had stayed on topic everything would be cool. At minute 1:33 you opened Channel Settings and demonstrated the absolutely incorrect method of adjusting rates.It had to do with a potentiometer fix, by way of hot glue.
Keith
If had stayed on topic everything would be cool. At minute 1:33 you opened Channel Settings and demonstrated the absolutely incorrect method of adjusting rates.
@Sully53 sorry for your crash and praise for your spot on descriptions provided. Those can be touchy and as you've witnessed first hand can have a sour outcome.So to follow up with what happened, like I said I wanted to check to see if any of the contacts were sticking and went into the channel settings instead of going into the channel monitor screen. I hadn’t touch my ST-16 since last year....So I forgot where the monitor screen was. So I tapped on the channel settings tab and was looking for the yaw channel (J4).
I clicked on it to make sure it was the one I was looking for. Then I remembered we’re the monitor screen was and backed out of that menu, leaving on J4 on the throttle channel. I then cleaned the right stick with the spray. Checked the monitor screen and observed everything was good to go.
Upon taking off I noticed when I yawed left the throttle increased. After I was done taking a couple of photos I brought the H back down. I must have been holding the yaw stick to the left to spin the H around and the motors shut off.
At that point I pressed the red button to try to restart the motors but it was too late. I am not trying to hide anything. I understand it was my own error that caused the crash. Nothing with the software. Let my mistakes help everyone know of what not to do with their drone.
Agree with your comments except the lead in comments. Not sure of the attempt to touch... there wasn't any "sinister" suggested unless you're indicating a few comments earlier not related. The other comments were all normal structured on standard assumptions, logic and experience and my comments presented a question if something was overlooked based on the openness displayed by Owner... I fail to see where any of that could be construed sinister.The issue is solved. Nothing sinister or deliberate. It's altogether too easy to press the wrong button and cause a lot of grief. The channel settings are not a place to make changes unless you either understand how to do it or you are following good instructions of the procedure.
There is no point in continuing the commentary unless someone has something of value to contribute. Frivolous comments will disappear.
Despite the tragedy of a crashed aircraft there are some extremely good take aways in this thread that all can learn from.
Videos on YouTube often contain incorrect information. Well intentioned people providing “how to” videos can provide erroneous info that will cause losses when followed. This incident exposed an instructional video that should be removed from public view before it becomes the root cause of another crash.
When investigating a crash and providing post crash info, always be as detailed as possible with descriptions of what was experienced. List everything you experienced during the fateful flight and note any service work and processes followed prior to the flight. Don’t leave anything out as a small omitted detail may be the most important one. When performing service work, make notes of what was done. That helps with an incident investigation, trouble shooting, in creating maintenance logs to establish service procedures and timelines.
Always perform a post take off control check after lift off. Get off the ground and up 10’ or so and hover to verify all controls are functioning correctly. If we notice anything that seems odd or different, land immediately. The issue will not get any better by flying it longer. Locate and correct the issue before flying again.
Maintenance/service work is frequently a prelude to performance and failure issues. After performing service work or making repairs we should always anticipate problems will appear afterwards. Any service work demands a functional check flight be performed that checks system functionality before returning an aircraft to service.
The telemetry associated with this incident is a good example of things a manufacturer looks for in a warranty claim. Although not associated with a warranty repair request it shows why a claim could be denied. This thread provided considerably more post crash analysis causal information than a manufacturer would have provided in a claim rejection.
We learn from our mistakes. We may not be aware we made a mistake but leaving ourselves open to review we allow others to help us find what we may have over looked, and learn how to prevent making the same mistake again. Everyone makes mistakes and the only way to learn from them is by admitting, even if just to ourselves, that a mistake is always a possibility. Those that refuse to accept they can make a mistake are assured they will repeat them.
The OP deserves considerable praise for his detail and candor describing this incident. Thank you for being open to critique and providing complete and detailed information.
A great many incident description posts leave considerable incident details under the table. Sometimes those omissions are obvious, sometimes not, but those details can be the difference between a solved incident that won’t be repeated by a user and one that is never solved, only to happen again for the same reason.
Despite the tragedy of a crashed aircraft there are some extremely good take aways in this thread that all can learn from.
Videos on YouTube often contain incorrect information. Well intentioned people providing “how to” videos can provide erroneous info that will cause losses when followed. This incident exposed an instructional video that should be removed from public view before it becomes the root cause of another crash.
When investigating a crash and providing post crash info, always be as detailed as possible with descriptions of what was experienced. List everything you experienced during the fateful flight and note any service work and processes followed prior to the flight. Don’t leave anything out as a small omitted detail may be the most important one. When performing service work, make notes of what was done. That helps with an incident investigation, trouble shooting, in creating maintenance logs to establish service procedures and timelines.
Always perform a post take off control check after lift off. Get off the ground and up 10’ or so and hover to verify all controls are functioning correctly. If we notice anything that seems odd or different, land immediately. The issue will not get any better by flying it longer. Locate and correct the issue before flying again.
Maintenance/service work is frequently a prelude to performance and failure issues. After performing service work or making repairs we should always anticipate problems will appear afterwards. Any service work demands a functional check flight be performed that checks system functionality before returning an aircraft to service.
The telemetry associated with this incident is a good example of things a manufacturer looks for in a warranty claim. Although not associated with a warranty repair request it shows why a claim could be denied. This thread provided considerably more post crash analysis causal information than a manufacturer would have provided in a claim rejection.
We learn from our mistakes. We may not be aware we made a mistake but leaving ourselves open to review we allow others to help us find what we may have over looked, and learn how to prevent making the same mistake again. Everyone makes mistakes and the only way to learn from them is by admitting, even if just to ourselves, that a mistake is always a possibility. Those that refuse to accept they can make a mistake are assured they will repeat them.
The OP deserves considerable praise for his detail and candor describing this incident. Thank you for being open to critique and providing complete and detailed information.
A great many incident description posts leave considerable incident details under the table. Sometimes those omissions are obvious, sometimes not, but those details can be the difference between a solved incident that won’t be repeated by a user and one that is never solved, only to happen again for the same reason.