Ok, I'm just going to cut to the chase here... I bought into this gear because of what I thought it would/could do and as everyone should know by now I lost my quad on day-2.
My intentions for building this thing in the first place was that I wanted to do FPV flying while simultaneously recording HD video. Clearly I needed to build my gear, learn to fly, and get comfortable with FPV first, but the desired end-state is the same.
The gear I ended up with was:
My plan was to later include hardware to extend my range (amps, tracking, ground-station, etc), telemetry, and probably a laptop/ground-station setup running Mission Planner.
After losing my gear to what we thought was a problem with my shoddy solder job I posted here, and after a bit of noob bashing it was my cheap radio equipment that was to blame, or so we thought. Based on the comments we later determined that it was a "bug by design" in the APM that more than likely led to my quad pulling a Houdini.
Since then I have purchased a small cheap laptop to run the MP, another 3DR kit, and more batteries. However, there has been a LOT more discussion, bashing, blaming, banning, and general covering up of the fact that the APM may actually be responsible for serious safety issues, fly-aways, etc.
The bitch of it all is that I'm sitting here wondering WHAT if ANY hardware could be used to make this thing (relatively) safe to fly, let alone accomplish my initial desired end-state. Some suggested spending some loot on a nice Spektrum rx/tx, but we've clearly determined that even it's failsafes do not work in certain scenarios, which was the whole point of bringing this APM bug to light. Having demonstrated a properly working failsafe on an expensive radio apparently being blocked by the APM PPM encoder behavior, could someone please explain this to me because I'm confused - this demo is in direct contrast to all the bashing I have received lately.
So despite all of this, low and behold patches are being developed and released to address this issue, but where does that leave me?
Based on my observations on this board for the last few weeks I don't see any way around this issue. It would appear that no matter what gear is used a fly-away could still be experienced. The patches mentioned above wont do anyone any good if they don't have the knowledge or the hardware to flash the PPM encoder. I've already lost 600$ in gear and I have purchased another 600$ in gear to help mitigate a problem that I apparently cannot solve. If a fly-away is still possible I don't even want to attempt flying this gear.
So another observation that I have made is that a lot of people seem to be doing exactly what I would like to do. How is it that their gear isn't flying away? Are they just taking the risk or are they truly safe? Do they even know about the issue? Are they even using diydrones gear?
So time for the BIG question for all the "experts" in this community... What gear would you recommend to ensure that this type of thing doesn't happen again?
I would like to see more than just a preferred list of gear; I want to know WHY you think it's better than any other. Price/budget is a factor so don't just toss out all the expensive shit because it's "better."
My plan of action included the FrSky modules for the Turnigy9x that I already have, a 2.4ghz amplifier, a directional/tracking antenna and ground station, a laptop with a ground station module for the use of MP if all else fails, long distance telemetry gear, et al.
I would also like to make the APM loiter (gps/altitude hold) if radio signal is lost with the option to auto-land exactly where it's at if control cannot be regained. Hopefully this wont be an issue with MP active on-site.
So post em up, lemme know your thoughts on enabling me to fly without the fear of hardware failure, and the possibility of losing more money and gear. (related safety issues aside)
I think there is somewhat of a problem the way APM went with the design. There really should be a basic and a stable branch.
A lot of the difficulty seems to have come from the fact that there never really was a basic stabilization period of development. As I've said before, the APM has a lot of bells and whistles that work great, but some of the basic things aren't mature yet.
The PPM encoder flaw is a perfect example. The devs never worked out the very first step of the whole system correctly. So we have a great GCS, good navigation, sonar, optical flow, current/voltage sensing, GPS, loiter, FBW, multiple flight modes, takeoff, landing, etc., etc. But the damn thing still can't properly pass PWM in one side and out the other!
Nobody even seems interested in working this out all the way either! It took a very heated thread that actually got a member banned for anyone to even admit there was a problem.
JB coded a workaround that will probably work great for most people, but it still will not faithfully pass PWM from one pin to another.
Maybe the way it's done is for the best, BUT... if someone bought our ultra-fancy APM, with all it's bells and whistles, and actually needed it to faithfully pass PWM through they'd be out of luck!
Perhaps with the upcoming 32-bit ARM processor switch we can go through everything again with a ground up philosophy. I haven't seen much discussion on this, so I can only assume the dev team is working on this in secret, which is another big problem with this project. Without input from everyone a lot of things get missed and better ideas fail to be brought up until it's too late.
Last September, when I suggested building a radio around the Si1000 chip (now known as the "3DR radio") only one other member even replied to my thread. Instead of discussing it openly the 3DR team started working on the project in secret. When the 433mhz version turned out to have a major design flaw it was a total facepalm for me! Had they bothered to ask me I would have told them to put the TTL converter in the cable, or just use an off-the-shelf one, right from the get-go. Instead, I only found out the radios even existed when a friend from the open pilot project emailed me, "Hey DIYclones stole your idea!"
Throwing a HopeRF module on a carrier board is not some brilliant idea you have to hide from others and develop in secret. But because of the current culture they paid the price and are now sitting on a bunch of garbage boards they can't sell.
Hopefully that, and the PPM encoder flaw, will prompt the powers that be to adjust their philosophy a bit and open things up to everyone so they can reap the benefits.
So Jake, are you volunteering to create and maintain a stable branch? It will be a LOT of work, but I think you're up to the challenge.
If I thought I had the time to do it justice I sure would give it a try. But, I don't have the time and my coding skills are fairly weak as I've only had two college level programming classes quite a few years ago and haven't done much since.
I will volunteer to help with the software engineering though!
I don't really think it would be all that hard to strip out everything but the basics then spend a month or two testing and tuning it until it works perfectly.
As easy as it is to load firmware on the APM, I would think a lot of people would be interested in stabilization only firmware, at least to run some of the time. A stabilization only firmware could run faster and probably do a better job at certain things.
A "back to basics" branch would also be the perfect opportunity to implement new features since it would be a good test bed to vet new code on and easier to work with. Adaptive control loops, a RTOS, or other features could be implemented easier on a basic branch, tested, optimized, then moved to the full feature branch. With more speed and memory it would be easier to get things working and debug them. Even a whole debug branch might be nice since you could more easily add debugging code.
I understood it was experimental. BUT I think most people get mislead by the features list and the versioning of the software. I was really surprised at the PPM issue.
If it was version 0.98 beta... I would wonder if the PPM encoder might still have some bugs to be worked out. But with version 2.34 I expect that all the basics are worked out and fully stable.
I think people also expect that with all the advanced features advertised the basics must be rock solid.
I don't fly quads, but I've noticed quite a bit of bitching about the APM on other RC forums. Many seem to suggest that the more basic stabilization boards do a better job of stabilization. I would think that we would want the stabilization to be at least on par with the cheaper boards, and would work almost exclusively on that until it is.
I like the APM and it really does have a lot of features I need that can't be found anywhere else. These are just my thoughts on how the engineering process could be focused more effectively and why it might be good to have a basic core version of the firmware.
How many times must I repeat that the design flaw was known from day one, and decided to be at an acceptable level since the weird/unstandard FS behavior of the 9x was unknown at the time. In practical engineering you must balance the features you want with the capability of the hardware available. Would you be happy if the failsafe was 'perfect' detecting any and all possible problems, but as a result stick movement would be jerky and move all over the place?
I posted this before I noticed your reply in the other thread.
Maybe I just don't understand things well enough, so you'll have to forgive me for not fully comprehending everything right away. I'm just throwing out my thoughts and ideas.
One thing that would be helpful is a more thorough and technical descriptions of the way things operate.
My understanding was that the "PPM encoder chip" in manual mode takes the PWM inputs and does whatever it needs to do, but was supposed to re-output them the same to the outputs.
This has never been made particularly clear in my reading. I'm guessing that it takes the PWM, then encodes a PPM signal that it passes to the main chip, then the main chip outputs the final signals?
As far as i know thats how it works, but also goes back to the encoder chip for output too i think. this is my understanding
8xPWM in from RX --> Encoder --> 1xPPM(8CH) out to main CPU
this gets mixed with all the other sensors with all those PID numbers we muck arround with then output back to the encoder
1xPPM(8CH)In from main CPU --> Encoder --> 8xPWM out to ESC's or servo's
Its also possible to flash the encoder to accept a PPM input. but there must be more than 8 inputs and outputs, because you can have an octo with camera servo's. but they are lower speed refresh on those PWM outputs so they may be software
Close, but the PWM output signals are made using dedicated pulse hardware located in the main chip. So the control signal chain looks like this:
8x PWM input signals -> PPM Encoder -> PPM signal -> Main CPU -> 8x PWM output signals
I'm guessing you mean hardware timers when you say "dedicated pulse hardware"?
The failsafe info here...
Has a picture of the old APM1. Is this info still valid?
If so is the actual scheme then...
8x PWM input -> PPM Encoder -> PPM signal to Main CPU (& MUX chip) -> MUX chip -> 8x PWM output signals
Which processor controls the MUX chip?
Also, if all the PPM encoder is doing is encoding 8 PWM channels to one PPM channel... WTF? That should be easy. Why all the talk like it's a difficult to get good enough performance? 8 channels at 50hz? Are you pulling our chains or what?
right you are John, im confusing myself. the first 4 PWM outputs from the main CPU go through a Mux before going to the output pins, inputs 1-4 can be connected straight thru to outputs 1-4 or something (hopefully it doesnt happen on my quad!)
Have these known issues been resolved in new firmware?
Don't you just love it when a thread dies when someone asks a good question? The "Developer" must be watching and hoping nobody would ask.........