Replies to This Discussion

Permalink Reply by Jake Stew on June 5, 2012 at 3:22pm

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.

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on June 5, 2012 at 3:41pm

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.

• ▶ Reply

Permalink Reply by Jake Stew on June 5, 2012 at 4:07pm

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.

• ▶ Reply

Permalink Reply by Jake Stew on June 5, 2012 at 5:17pm

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.

• ▶ Reply

DeveloperPermalink Reply by John Arne Birkeland on June 6, 2012 at 12:03am

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?

• ▶ Reply

Permalink Reply by Jake Stew on June 6, 2012 at 12:25am

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?

Permalink Reply by Chris Huitema on June 6, 2012 at 3:10am

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

• ▶ Reply

DeveloperPermalink Reply by John Arne Birkeland on June 6, 2012 at 3:22am

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

• ▶ Reply

Permalink Reply by Jake Stew on June 6, 2012 at 11:44am

I'm guessing you mean hardware timers when you say "dedicated pulse hardware"?

The failsafe info here...

http://code.google.com/p/ardupilot-mega/wiki/Failsafe

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?

• ▶ Reply

Permalink Reply by Chris Huitema on June 6, 2012 at 7:22am

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!)

• ▶ Reply

Permalink Reply by Harley Engholm on December 18, 2012 at 9:47am

Have these known issues been resolved in new firmware?

• ▶ Reply

Permalink Reply by Neil Flournoy on January 26, 2013 at 9:56pm

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.........

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page