Help With new (first) TX/RX purchase (budget)
by John Kwasky [ http://diydrones.com/profile/JohnKwasky on ]
DIYDrones.com
May 16, 2012
Can someone tell me if THIS [ http://www.hobbypartz.com/79p-th9x-r9b-9channel-radio.html ] and THIS [ http://www.hobbyking.com/hobbycity/store/__14349__FrSky_DJT_2_4Ghz_Combo_Pack_for_JR_w_Telemetry_Module_V8FR_RX.html ] will work together and is this a good choice for failsafe and reliability on my first quadcopter.
Thank you,
2:22am
by John Kwasky
May 16, 2012
Yes I saw that but he was not using the THIS [ http://www.hobbyking.com/hobbycity/store/__14349__FrSky_DJT_2_4Ghz_Combo_Pack_for_JR_w_Telemetry_Module_V8FR_RX.html ] right ?
8:11am
by Jake Stew [ http://diydrones.com/forum/topic/listForContributor?user=2egm7fj1oj7qk ]
May 16, 2012
I haven't got my firmware flashed, but I can tell you the stock firmware is pitiful. It was seriously written by non-english speaking retards.
I got the Turnigy 9X TX/RX from hobbyking for around $55. I'm pretty happy with it overall. That's what I'd start with.
It's easy enough to add another TX module in the future. They've run the coax through the unit, so you have to cut the coax, remove one screw in the antenna and pull it out. If you want to save the TX module you'll have to then resolder the coax to the module. There are several youtube videos on this.
You just can't beat the price on this unit. Even buying a new TX module and RX it's still probably the cheapest 9ch out there.
8:51am
by John Kwasky
May 16, 2012
Or I could just use THIS [ http://www.hobbyking.com/hobbycity/store/__17205__FrSky_DHT_8ch_DIY_Telemetry_Compatible_Transmitter_Module.html ] ....
So you recommend the Turingy over the FrSky ?
9:05am
by Jake Stew
May 16, 2012
Not sure how that gizmo works. The details look pretty sketchy on implementation.
I just use the Turnigy 9X transmitter and the TX module and RX that comes with it. I'd start there before dumping money on other modules.
The new 3DR radios (Si1000/HopeRF module based) work pretty well and are light years ahead of any of the 2.4g crap that's out there. If/when I replace the stock TX module it will probably be with a Si1000 based radio chip. I'd imagine there should be some of those out in a year or so. It's a shame HopeRF didn't expose more pins from the Si1000 or I'd already be working on using one of their modules as a TX/RX. They're only $10 each, and have more processing power than the APM2 so it really is a shame they wasted all that on a simple transparent serial connection.
9:59am
by Vernon Barry [ http://diydrones.com/forum/topic/listForContributor?user=3dfg3qf41yghy ]
May 16, 2012
I just use the Turnigy 9X transmitter and the TX module and RX that comes with it
We know the stock receiver will continue to send the last outputs to the APM when the radio is lost. This is the same thing that caused the new member in the other thread to have a complete loss of the entire heli. I' pretty sure you saw that thread and you STILL fly on that receiver?
The details look pretty sketchy on implementation
No, what's sketchy is flying with a receiver we know doesn't work with failsafe, but worse than that, has been known to cause flyaways and crashes.
I'm not trying to pick on you, or start something. I'm just saying I cannot believe what you just posted when I think you saw that exact combination caused a crash.
11:17am
by Jake Stew
May 16, 2012
That was a random flyaway, there's no telling what caused that. It's pure speculation to blame the receiver.
I'm not saying that wasn't the cause, but it could have just as easily been the ESC or APM.
I've used the 9X transmitter plenty with no problems. Millions of the transmitters have been sold under a handful of brand names. I haven't seen very many complaints online for how popular they are.
Believe me they wouldn't be selling like hotcakes and constantly out of stock if they weren't being used. People would be screaming like bloody murder all over the internet if the problem you mention was anything more than a 1 in 1000 hardware problem.
Production errors do occur, there's really nothing you can do about it. The soldering on my 9X is better than my 3DR radio or APM2, so it's not a poorly made product.
So I stick by my recommendation. Lot's of people far more experienced than me also recommend the unit.
4:41pm
by Zen [ http://diydrones.com/forum/topic/listForContributor?user=1npquptqvcifb ]
May 17, 2012
Ok, so hang on a minute...
You're telling me that the fly-away of my 2-day old quad was NOT due to the 9x I was using but rather an issue with the APM? Everyone busted my chops for flying with a 9x which doesn't have any failsafes and told me to drop some loot on a much better system w/ failsafes - even though folks have been using that 9x for years w/out issue, including the buddy I borrowed mine from. Granted I may not have tested properly, but if what you're saying is correct it wasn't even a function of the remote and failsafes would have done no good anyway.
Let's also add a point that my flyaway, after being high enough to barely see and escaping the multi-mile square park I was in, DID appear to cross paths with an airliner. Now, I don't live in CO, but this sounds eerily similar to my experience.
http://www.9news.com/news/article/268207/188/Mystery-object-nearly-causes-mid-air-collision
So I lost a 600$ quad because of the APM hardware? Not cool, at all. Now I have to rebuy and rebuild everything from scratch - a money maker for 3DR I'm sure, but when does profit overrun safety, and how many near collisions from flyaways do we need to have hit the news before something is done to not only improve the safety but sufficiently alert customers to the safety/failsafe mechanisms that exist?
Now that I'm building another quad, how safe do I feel in learning to fly it without the fear of a repeat incident? Maybe spending $10k on a mikrokopter for my photo/video endeavors isn't such a bad purchase after all...
8:04am
by Jake Stew
May 17, 2012
I wouldn't call the APM soldering "bad"... It's not the best but it's not any worse than most IPC class 1 boards.
5:07pm
by Dave
May 17, 2012
You're telling me that the fly-away of my 2-day old quad was NOT due
to
the 9x I was using but rather an issue with the APM?
Not quite. You reported total loss of control which could have been:
Regardless, someone needs to look at the APM.
6:55pm
by Dave [ http://diydrones.com/forum/topic/listForContributor?user=1z0zw2vim8uvd ]
May 23, 2012
I've done some further investigation. Turns out I was looking at old code the other day :-o
According to the doco for the current PPM code :
------------------------------------------
Failsafe mode
------------------------------------------
If a receiver servo channel is lost, the last know channel position is used.
If all contact with the receiver is lost, an internal failsafe is trigged after
250ms.
Default failsafe values are :
Throttle channel low (channel
3 = 900 us)
Mode Channel set to flight mode 4 (channel 5 = 1555 us)
All other channels set to midstick (1500 us)
So it will Failsafe on loss of all signals, but loss of just Throttle could be disastrous.
Turning to the standard Turnigy receiver, I did some more testing and it turns out that, on loss of the Tx signal, not all of the PWM channels disappear. For some reason that I cannot fathom, Channels 4 and 5 continue to hold their previous settings. This happens on both receivers I have. So, the APM would not trigger a Failsafe, but continue on as it was.
So, time to rip out the Turnigy stuff and install the Frsky modules.
6:50pm
by Jake Stew
May 23, 2012
For some reason you can't fathom? That's the most common sense default failsafe you could have. Obviously the throttle should go low or to idle. The most logical thing to do is hold the rest.
This is an APM bug. There's absolutely nothing wrong with the behavior of the Turnigy module.
8:01pm
by Chris Anderson [ http://diydrones.com/forum/topic/listForContributor?user=zlitezlite ]
May 24, 2012
I watched the first video and don't see a "bug". Failsafe works as expected. You then disconnect the throttle channel entirely and expect APM to autodetect that (despite the other channels still being connected and working) and somehow go into another failsafe mode. That may or may not be a good thing to do, but it's not the way the APM software was designed and there's nothing in the documentation that would suggest that it would do that.
If that's what you want and enough people agree, it's a perfectly reasonable feature enhancement to suggest. But there's a big difference between feature requests and bug reports.
10:30pm
by Chris Anderson
May 24, 2012
Maybe your idea is a good one, but as far as I know you're the first person in ~10,000 users to ask for it. There are an infinite number of "safety enhancements" that could be added to APM, anticipating any number of things that could possibly go wrong. You've come up with yet another -- one of the RC channel connectors comes loose.
Perhaps that is a high enough likelihood to deserve being considered by the dev team; I don't have a good way to calculate that. I also don't know what the best action in that case would be. (I could make just as good a case for holding throttle where it is so the craft can be brought home, as it currently does.)
At any rate, if this is a high priority for you, I suggest you work with the PPM encoder team to consider implementing it. But as I say, it just hasn't come up before.
11:35pm
by Jake Stew
May 24, 2012
Has nobody bothered to actually test the APM unit out properly? This should have been caught in beta testing, well before the 1.0 release. Seems kind of strange that I find several bugs in the first few days of playing with it.
The failure to properly manage the throttle is a major bug and safety issue. You really need to add a warning to the pseudo-wiki and to the documentation.
"I turned off the signal, but the 3DR product continued to accelerate towards the daycare playground on it's own accord," is exactly the sort of thing that will end up in a multi-million dollar lawsuit being won against you.
It's one thing to tell people who want features or enhancements or changes to jump in and do it themselves, but it's really difficult when the existing code was written with major design flaws and nobody seems too concerned.
11:55pm
by Zen
May 25, 2012
I'll have to pipe in and apologize for all my previous posts as being a little hot headed, but my expectation when purchasing from diydrones is that I could build a quadcopter by following the directions provided, learn to fly it well enough to attach a camera to it, and then offer flight photography/videography services for my customers (pending future law changes) as well as personal use and fun.
Now, I realize being completely new to the world of RC means that I have a lot to learn - lot's of "pro-tips" as it were that simply do not exist in the documentation at all. Things that only an RC expert would know. Following the instructions led me to a perfectly flyable quad the first time - no hiccups, no adjustments. However, I did have quite a bit of help from Mr. Finisterre who has been building these exact quads for at least a couple years that I know of. So in that sense I was able to do exactly as I set out to do and began the "learning to fly" portion of my expectations.
Like the ~10,000+ users you mentioned I ended up with a standard Turnigy 9x, borrowed from Kevin who to this day has yet to experience an issue with them, and on my 3rd battery the quad locks throttle and flys so far away that recovery was not possible...
Now, was I pissed at the time, yes, and did we know exactly what happened? No. Through considerable discussions both in this thread and mine I think the issue has been fleshed out enough to consider it a strong possibility that this "bug," "feature enhancement," or whatever you want to call it was a direct cause. It could have been a Turnigy issue, it could have been a shady solder-job on my part (which wasn't really THAT bad), or it could have been a vibration that disconnected something mid-flight. Whatever the case may be, the APM blasted off at full-throttle with no hope of recovery or shut down. (believe me, I tried everything as I was running full-tilt across the park chasing my hardware and getting laughed at by all the bystanders)
My initial gripe was that I lost 600$ in parts because of an unknown issue, now it looks like I've lost 600$ in parts because of a "bug" in the APM that will launch your shit into the stratosphere. I paid close attention to the news for about a week afterward hoping that my quad didn't crash land on some kids head, or a car, or a house - a 5lb object falling from >2000 ft could conceivably do some damage. My next thought was what if this throttle "bug" happened while I was banking left or right? I was in a MASSIVE field, mostly uninhabited, but there were a scattered few people, kids, parents, etc playing soccer, baseball, football, hanging out, in other parts of this field. If that specific scenario played out my craft could have been mere feet off the ground and accelerated non-stop horizontally and taken out any number of people.
When I posted my experience people on this board jumped my shit because I didn't know a thing about RC, wasn't aware of any specific safety features as I didn't purchase my rx/tx gear, and failed to follow some undocumented pre-flight testing procedures. As it turns out they may have been partially correct, and now I know, but that doesn't absolve whomever built and/or programmed this hardware from acknowledging the fact that there is a serious, and very repeatable, "bug" that could get someone very injured, or killed.
From my perspective as an uninitiated newb your website leads me to believe that I can build or buy, then fly. That's what I did. Then my quad accelerates uncontrolled and is lost with the potential to have hurt people regardless of whatever safety features I could have used. This, to me, seems to be a pretty major concern, and it's even more disconcerting that you seem to gloss over it as though it's no big deal and should be considered a "feature enhancement."
In my very humble opinion I believe this hardware to be geared specifically to the RC electronics hobbyists and code monkeys out there, NOT to any "normal" person that happens to stumble onto your site and decides to build a quad. Proper, and complete, documentation is very lacking, proper warnings are very lacking, and it would seem that despite following everything to the letter the hardware does things that are completely unexpected! (even for folks that have been working with these for years) I guess luck would have it that some major event hasn't occurred before now, and I'm glad that my incident and subsequent rant pulled all of this out of the woodwork because apparently it IS a big deal, IS repeatable, and has happened to other less vocal customers.
The bitch of this situation is now that I have another nearly assembled unit do I try to fly it or not? I can say with 100% certainty that I am very leery of doing so. DEFINITELY not with a stock 9x, maybe with FrSky, but more than likely I'll need to double my investment and get the Spektrum gear. It also looks like I'll need to do a lot of extra work in researching geo-fencing, get some telemetry gear, and ensure that all the failsafes are in place. Oh wait, even then my quad could STILL fly away uncontrolled. Blerg.
Thanks for listening.
5:58am
by Chris Anderson
May 25, 2012
Jake: I will simply repeat: it was a design decision, not a bug. You may not have made the same decision. (Indeed, your contributions on this site seem to consist almost entirely of complaining that you disagree with our decisions on everything, from the wiki to forum software to PPM encoder design. Fortunately there are lots of other communities and autopilots, so you can choose another one that makes you happier.)
For the others, let me explain a little more more how the PPM encoder works. First, it runs on the 32U2 chip, not the 2560, so it's loaded at the factory and can only be changed with an AVR programmer. Second, because it's running on a different chip the same PPM encoder code applies to all platform software, from ArduCopter to ArduPlane to ArduRover, etc.
What is the correct throttle response with the signal is lost on Ch 3 for all of these platforms? We thought that holding the last signal was the best choice, given the range of vehicles that are supported. Obviously that's the best choice for planes, so you can bring it home. It's arguably the better choice for copters, given the alternative: falling out of the sky wherever it happened to be when this happened. And it might not be the best choice for rovers, but that's the least common usage.
Again, it's perfectly reasonable to run through the logic above and come up with a different strategy. That's the beauty of open source code. You can change it for your own taste.
But it's not a bug, it was tested, and it's not stupid: it's simply a design decision made by a team who thought hard about all the options.
BTW, switching into auto or RTL gives throttle control back to the autopilot and should bring it back safely, even if the RC control is lost, assuming it has been set up properly.
7:47am
by Chris Anderson
May 25, 2012
Kevin: We are planning to have the Mission Planner detect which version of the flight software you are using and ask you to upgrade if there's a newer version available (as it already does with its own software). But the I2C bug was fixed last year. This is an open source project and evolves very quickly. Like all open source projects we don't promise perfection, but we do promise constant improvement. Regular updates are part of the deal, and we expect users to keep up (in part because we only support the latest code). The alternative is a $6,000 commercial autopilot that has passed mil-spec test standards, which is certainly a fine choice for people who want that but not our approach.
As for your point about autodetection of aircraft type, please re-read my comment earlier today [ http://www.diydrones.com/xn/detail/705844:Comment:870252 ] about how the failsafe code is on the 32u2 chip, not the 2560, and cannot be updated by the Mission Planner or even by the user at all unless they have a AVR programmer.
1:07pm
by Chris Anderson
May 25, 2012
The 328 on APM 1 requires an AVR programmer. The 32u2 on APM 2 can be updated via USB through a somewhat convoluted process described here [ http://code.google.com/p/ardupilot-mega/wiki/APM2Encoder ]. This means that if anyone wants to customize their PPM encoder software they can, but we can't realistically push an update to everyone the way we can with flight software.
If the consensus of the community and dev teams is that they want smarter failsafe software going forward, that's best sync'd to the next APM hardware release (perhaps the ARM version in Q4) and loaded at the factory with new boards. In the meantime, people are free to develop and distribute derivatives of the existing PPM code that add what they want, but it won't be officially supported.
1:30pm
by Jake Stew
May 25, 2012
When the APM gets NO THROTTLE SIGNAL it continues to put out a throttle signal. That is a BUG. You can't spin that any other way.
Why not just admit you have a bug and fix it? Sounds to me like a very minor code change. Certainly not worth trying to argue that it's supposed to be that way. Nobody is buying it.
Sure, I complain a good deal... but I don't see anyone even trying to argue that any of my complaints/suggestions aren't valid. I'm amazed how great the APM is in so many ways, but equally amazed that some of the most easily fixed and basic issues seem to remain. Seems like most of the hard stuff has been done well, but the easy stuff is ignored.
4:28pm
by Jake Stew
May 25, 2012
The 9X has a perfectly reasonable failsafe when it goes out of range. It drops the throttle signal and freezes or drops the other channels. This is the most logical behavior I can think of.
I still don't understand what people expect it to do. As a basic TX/RX it does exactly what you would expect a basic system to do.
The bug, design flaw, or whatever you want to call it is entirely in the APM. A large company would certainly initiate a product recall or at the very least mail a letter and email every customer that purchased the unit a warning notice. There's a HUGE liability here. Somebody WILL get hurt by this sooner or later.
The most similar thing I can think of is the Toyota brake issue. That cost them many millions, but they didn't even consider any other option than recall. It's the same as if your cruise control fuse blew and the computer held you at 70mph while disconnecting the brakes.
4:42pm
by Chris Anderson
May 25, 2012
Jake: I'm not going to bother responding anymore. You either don't understand open source and liability or are intentionally not listening to anything I've said. At any rate, I suggest you move on to another community that works the way you'd like it to.
5:16pm
by Jake Stew
May 25, 2012
You cannot have a craft crash under power. If you have a system you know does this it is "reckless endangerment" to operate it. If all else fails you HAVE TO PULL THE PLUG!
In the issue we're dealing with ALL control is lost. In that situation your only option is to pull the plug. To do anything else is simply reckless. You just can't legally risk people and property to try and save your gear.
If you had some better option it that would be great. But if you loose control you must still always have a kill switch or "deadman" type switch. It's very simple to implement. Anyone can understand that if you are getting no signal you should not be holding the throttle on.
If control of the craft is lost it MUST be shut down. To legally operate the APM it must always:
#1 cut throttle when it's not getting throttle signal (in the absence of any better auto pilot control method kicking in).
#2 cut throttle when any lockup or freeze of the system occurs.
The long and short of this is that it must have a deadman type kill switch that operates in all circumstances. I write this because I have seen enough liability lawsuits to know exactly how this will go in court. The prosecution will come up with dozens of examples where this is considered a basic safety feature (lawnmowers, etc., etc.) and they will have a programmer testify that they could do it in 10 minutes with a line or two of code with a watchdog timer. They will then present evidence that this is a known bug/design flaw (this and the other threads here) and that nobody made any effort to mitigate the danger. They will say it was reckless to operate a craft without this most basic, and easily understandable, safety feature. It's just the same as the Toyota brake failure issue or a lawn mower that didn't shut down when the handle is released. Lot's of people don't like these sort of safety features or disable them, but defeating them or not having them exposes you to tremendous legal liability.
Believe me, this is how it would go down and they would quite easily get a large judgement against both the pilot and 3DR. There are lot's of ways to mitigate both the danger and the liability, but ignoring it or pretending it's not a bug is not one of them. You'll hear "So you KNEW about this bug/design flaw/possibility/danger," so many times you'll be sick of it by the end.
I bother to type these posts because I want to see the hobby do well with minimal regulation. I'm also now unfortunately placed in a position where I am very wary of operating my APM knowing that it could easily be painted as reckless endangerment.
If my plane were to crash under power, and I knew this could happen, and I did nothing to prevent it, and I operated the craft anyways, and it killed someone... I'd be guilty of manslaughter and facing 5+ years in prison. That's the simple way of looking at it and it's easy to ignore this remote possibility. But even if NOBODY gets hurt it's still reckless endangerment just for risking it.
If I pull the plug and it crashes unpowered that is taking reasonable precautions to mitigate the danger. A reasonable person would assume that a styrofoam plane, traveling at a relatively low speed, with a relatively low weight, unpowered, with reasonable safety features shouldn't be expected to kill someone. Even if someone was killed I'd face little or no criminal prosecution for it.
5:35pm
by Jake Stew
May 26, 2012
Just an aside to Chris for an earlier post lost in this thread where he suggested I don't understand open source software or liability...
#1 I'm not a lawyer, nor do I play one on TV.
#2 I don't have any idea about the idiosyncrasies of CA liability law.
#3 I point this shit out not to argue with you, but because I don't want to see my current autopilot platform go down in flames.
Despite this, I have the basic common sense of a reasonable person.
#1 You have designed, make, and sell a hardware platform that you suggest is suitable and capable of being an autopilot. (warranty of fitness for a purpose)(express warranty)
#2 You show videos and post descriptions of safe operation of this device (further express warranty)
#3 You 100% control the documentation that people follow to use this device. (the pseudo wiki)
#4 When people buy your hardware, follow your instructions, and operate the device as shown and described it is known to maintain the throttle despite removal of the throttle signal.
#5 This behavior has the documented potential for loss of equipment and property damage.
#6 A reasonable person would believe this behavior has the real potential to cause property damage, injury, or even death.
Please consult with a lawyer and see if this set of facts exposes you to legal liability. I think you already know the answer to this. You might also mention that you also have 100% control over the software that you instruct the users to load, despite the fact that's it's open source.
You can ignore me, argue with me, or change things up. Consider which option might be the most constructive and beneficial to the project, or which might be in your own best interest legally. That's all I ask.
2:29am
by Dave [ http://diydrones.com/forum/topic/listForContributor?user=1z0zw2vim8uvd ]
May 26, 2012
Jake, take a calm pill and go have a lie down.
All this legalistic mumbo jumbo is just way, WAY OTT. We're not talking about a B747 flight control software bug. It's not even a bug, but a known, planned and documented reaction to an input condition.
Sounds like it will be reviewed for future boards, but changing existing boards is not simple - not everyone has the ability to reflash their board. However, if someone was to come up with an alternative PPM firmware that, say, in case of loss of signal, sent a Failsafe level on the Throttle line, I'd be confident there'd be space for it on the site somewhere.
So, instead of all this negativity, how about working on a fix.
5:21am
by Jake Stew
May 26, 2012
Not trying to be negative, just confused why so many people refuse to admit that ignoring control signals and maintaining power in a complete loss of control situation is acceptable behavior.
Like I said you have to be able to pull the plug at any point. If you lose control or the ability to pull the plug it HAS to shut down automatically. Anything other than this is reckless.
It doesn't really matter what you think, and in some circumstances that I can't really see you may be right. This is because the legal standard is the "reasonable person", not what you think. And I can guarantee you that you won't be able to convince ANY of your 12 jurors why it was OK that you couldn't cut the power when you saw your chopper heading 40 mph at a small child. No reasonable person will understand why you would think it wasn't reckless to have no kill switch on a motorized vehicle with exposed rapidly spinning blades.
Actually try and think on that a few minutes. Maybe ask someone who isn't a RCer what they think. "If I see my craft is heading towards a child at high speed under full power and I have a radio problem do you think it's OK that I have my gear setup so that it won't stop."
Or tell them that ordinarily my 9X would kill the throttle, but I have inserted a device that disables this safety feature and maintains power to the motor even if I ripped the wires out.
Essentially the APM disables the safety failsafe of the 9X system and maintains power despite complete disconnection of input. Any time someone is injured because you disabled a safety feature on any sort of device you are 100% liable. The discussion between the lawyers will START at how much punitive damages you'll be paying in addition to covering the actual damage.
3:15pm
by Richard [ http://diydrones.com/forum/topic/listForContributor?user=1ez8jzxosvksy ]
May 27, 2012
Jake, please stop diverting the thread away from the actual issue.
The fault has been discovered and described, and some solutions have been proposed.
The fault is that the APM simply doesn't get told about certain kinds of loss-of-signal events, thus cannot do anything.
Selecting an appropriate behaviour for a given airframe is a different matter, and there is no single solution.
It may be safest for a large and heavy copter to make a controlled powered descent or RTL, a small one to just kill the motors, there might be a parachute to trigger...
It is entirely down to the operator to examine their airframe and airfield and select an appropriate response to loss-of-signal.
It is not the place of Jake Stew, myself, 3DR or DiyDrones to make that decision, and this was never about what the APM should do on LoS - it was that it didn't do what an operator wanted it to do.
6:55am
by Zen
May 27, 2012
"It is entirely down to the operator to examine their airframe and airfield and select an appropriate response to loss-of-signal.
It is not the place of Jake Stew, myself, 3DR or DiyDrones to make that decision, and this was never about what the APM should do on LoS..."
I wholeheartedly disagree. My logic says that the APM should ship with some sort of default failsafe, one that can be overridden by the user, clearly, if they deem a different method more appropriate for their particular situation. However, for an autopilot capable "brain" for lack of a better term - a piece of hardware that is receiving data from multiple built-on sensors and has the capability to act on its own, there should be some expected out-of-the-box functionality and failsafe.
From Chris Anderson:
"... let me explain a little more more how the PPM encoder works. First, it runs on the 32U2 chip, not the 2560, so it's loaded at the factory and can only be changed with an AVR programmer. Second, because it's running on a different chip the same PPM encoder code applies to all platform software, from ArduCopter to ArduPlane to ArduRover, etc."
That description by itself sounds like a huge design flaw. How I think I understood that is the APM cannot make any failsafe decisions because the PPM encoder operates independently and is not flashable through software/Mission Planner. This means that the same code running on that independent chip applies no matter what platform you're running on. That would also mean that there is no communication between that system and the APM, or that the communication is bad/damaged/whatever ultimately making it unusable, thus the APM cannot make any decisions. With all the other sensors on the APM I would think information pertaining to the communications/control signal quality would be good info to have. If we have the hardware to fly autonomously and make a certain level of decisions then let it do just that no matter what mode you're flying in.
The second reason this statement screams design flaw is because the same failsafe code has to be used on every platform. Rarely in life does one shoe fit all, and technology, especially NEW technology, is no exception.
If I were flying a plane I would think that upon signal loss preventing safe control of the aircraft it would be best to throttle up, circle (gps hold), and beep that fancy init/startup buzzer like it's life depended on it - hopefully alerting you to the fact that there is a problem that needs your immediate attention and give you some time to fix it.
If I were driving a boat, rover, or any other "land" based platform I would absolutely not want it to throttle up, in fact I would want the opposite. If signal loss occurs for too long I want your ass to STOP. A runaway gas powered rover throttling up to 60MPH can cause some serious damage, injury, or who knows what. STOP, BRAKE, BEEP. Alert me that there is a problem so that I can correct it.
If I were flying a single, quad, hex, etc al chopper I wouldn't want it dropping from the sky, that's unsafe, and I sure as shit don't want it to throttle up and fly away! In my case there was a 3-4MPH crosswind so it climbed vertically and horizontally. This thing is supposed to know where it's at spatially as it's packed with sensors and designed to self fly... Why not do an Altitude + GPS hold and beep? No matter what it's doing, once failsafe kicks in it will auto stabilize, STOP, BEEP, and hold position even if there is a crosswind. The pilot could then say "hey, my craft is not responding to my controls, and it's beeping... hrm, I need to fix that." Regardless it wont fly away and it wont come crashing to the ground.
If you wanted to get fancy the failsafe code could change its actions should the battery reach a certain depleted state. In the case of a plane it could auto-spiral down still staying GPS locked. In the case of a land vehicle same result - STOP. And for a chopper it could slowly descend to the ground. It could also include a beeping signaling low/critical battery.
I know this particular discussion is played out and that we're not discussing failsafe actions as much as the fact that the APM currently cannot act on the data it would need to determine a failsafe action, but in an effort to make an autonomous craft actually useful AND SAFE, I believe a certain level of functionality should be possible and defaulted. You play this DIY shit as pretty plug and play, as well as relatively safe (by lack of documentation to the contrary), when the truth is it's far from that.
In trying to make your product better, safer, and more intelligent I think some attention needs to be paid to monitoring the quality of the only signal that's telling this thing what to do. If I wanted a "dumb" chopper I wouldn't have bought into your autopilot autonomous drone shit and just bought a chopper. Same goes for every other platform. I bought into smart hardware so that it would make flying easier and more foolproof. Truly I was flying within minutes - I bet I couldn't pick up that quickly on any normal craft.
You have all the data, use it. If you don't, then add the sensor you need. I listened to your talk at the Maker Faire and your explanation as to why you started down this path - auto. pilot. - you thought that with all these sensors you could create something that was a little smarter, and you have, but the decision to ignore the biggest safety sensor you have -- the controls -- puts people, possibly your kids, and ours, at risk when they buy & fly your kits.
I just want to see this taken care of for everyone's safety, but also so I can feel confident in flying your equipment without the fear of losing my gear or chopping something/one up. Wonder how this would have turned out if your demo at maker faire failed the way mine did.
12:33pm
Copyright 2012 http://diydrones.com/forum/topics/help-with-new-first-tx-rx-purchase-budget