APM vs. PX4 – what to get?

by Mike Mac [ http://diydrones.com/profile/MikeMcLaughlin ]

DIYDrones.com

February 21, 2013

What are the advantages and disadvantages or each?　

The PX4 looks like the very old days when APM had many boards and no case. Just looking at the advertisement I have no idea why I would want to trade in my APM 2.5+ for a PX4?

1:10pm

by Jake Stew [ http://diydrones.com/forum/topic/listForContributor?user=2egm7fj1oj7qk ]

March 1, 2013

The problem with the APM is that they use a weak old processor instead of a cheaper and much faster modern one in order to make the programming easier. Then they even used old analog methods like PPM for stuff it's not intended for like inter-processor communication so that they could borrow code from Paparazzi.

To their credit, they made it work. But what you have is a slow, old processor using old and inefficient analog techniques to do it's job. Pile that on top of using a programmer's "training wheels" system like Arduino and you have the APM.

I like my APM, and it works alright, but it is certainly a legacy device and not a modern design. It's certainly not the future of autopilots. They took the easy path to getting an autopilot on the market and now the growing pains will certainly be the death of the APM as we know it today. You can only take old processors and analog thinking so far, and waiting for Atmel to catch up to the rest of the processor market has already left them in the dust.

The PX4 is a bunch of upstarts that rather rudely forked from the OpenPilot project, so I have no special love for them, but I imagine they have their reasons and if OP can't kick down the hardware then I suppose there's not much else you can do.

9:07pm

by John Arne Birkeland [ http://diydrones.com/forum/topic/listForContributor?user=06y3ki3y983p5 ]

March 2, 2013

This is my personal view and nothing official. APM has had a very good relationship with Arduino, and much of the early success came from that union. But even at a very early stage Arduino code was stripped out and replaced with faster equivalents to make our application possible. Today there's pretty much nothing left of Arduino, beside pin layout and using the .pde files to make compilation with the Arduino IDE possible.

But still there was a valid reasons for sticking with Arduino. So 3DR and APM devs waited a long time for Arduino to come out with a ARM based solution, so that we could continue that relationship. But sadly even to this date, the Arduino Due isn't really all there and the choice of ARM (Atmel SAM3X) is far from optimal for our needs. So when the PX4 was announced, we jumped. I do not know details about the next 3DR APM3, but I would not be surprised if it is an evolution of the PX4 hardware.

@Jake, good luck with trying to remove PWM and PPM support. That would cause a shit storm like no other, stripping away support for 99% of the receivers in use today. And PPM is actually extremely resource efficient as a one way communication between two chips. Requires much less resources then decoding a serial bit stream.

5:25am

by Lorenz Meier [ http://diydrones.com/forum/topic/listForContributor?user=2pkdktuy9yghv ]

March 5, 2013

I think I have to wrap up some of the speculations here and set some records straight, plus I think I've got a good answer for Mike.

@Mike: The APM software runs already on PX4, and in this mode you can't tell if its APM 2.5 or PX4 as a user (same MissionPlanner interface, same behaviour). This is in beta testing, but works great so far for the APM devs, and we're jointly targeting a release, at which point you can flash your PX4 board like you're used to flash your APM 2.5. This is deliberately not supported right now, to not tease you into becoming a beta tester if you don't explicitely want to.

APM on PX4 will benefit from the bigger processing performance in being able to support better filters and controllers and running at higher update rates. The ArduCopter codebase is by now maxing out the AVR and could do more with more processing. So I recommend to stick with APM 2.5 as long as you don't see official MissionPlanner support for PX4, but its not something that would be planned, but something that is actively test-flown now.

Plus you have the option to run the PX4 native stack, which is right now still targeted towards developers and researchers, but this will gradually change. The gut feeling I have on your use case is however that you will want to wait until a PX4 with case and MP support shows up, which will indicate when the dev team feels its end-user ready.

As for the hijack aspects on this thread: There is much speculation here still and little knowledge, and unless familiar with GIT even the provided links are not obvious at all. So let me start from scratch with a way simpler explanation in plain english:

• PIXHAWK is a research project of the Swiss Federal Institute of Technology. Although the people in it contribute to PX4, its not the same thing, and PIXHAWK has its own codebase (called imu_autopilot), which exists since 2008. MAVLink exists since the same time, and I hope this makes it obvious that both is original work. PIXHAWK won 2009 the European Indoor Autonomy competition and we learnt a lot from Paparazzi, which clearly are the shoulders (and the only ones, since the other projects did not exist in a relevant shape in 2008) we're standing on.
• We were at some point in 2011 considering to contribute a board + software to OpenPilot, but eventually (and we're still good friends with the OpenPilot dev team) decided, for purely technical reasons, that we want some things differently and started from scratch. We did contribute the Cortex M4 infrastructure to OpenPilot, which you can find here: STM32F2/F4 change set [ http://git.openpilot.org/changelog/OpenPilot?cs=3388843fb5a575f90b26f5c408f9d57f1b35d0f3 ], we however did not take any code from OpenPilot into our repository.For said technical reasons, work stopped there completely, we started from scratch and based our new effort on the NuttX OS, the codebase for this can be found here: PX4 Firmware [ https://github.com/PX4/Firmware ]
• Completely unrelated to PX4, QGroundControl uses the really great OPMapControl library, which is (feel free to check that the credits are there for a very long time) clearly attributed here: QGroundControl Credits [ http://qgroundcontrol.org/credits ]

So despite that I think OpenPilot is a great project, calling PX4 a fork is just completely wrong, in every single aspect. You will not find any OpenPilot code in PX4, and since PX4 uses a completely different operating system, different middleware, different controllers and different communication protocol just shows that whoever makes that claim did not bother to quickly look at the two source trees (here [ https://github.com/PX4/Firmware ] vs. here [ http://git.openpilot.org/browse/OpenPilot ]), because if it were a fork, it would have to show some similarity. Just compare the two and check if you can find any remote similarity.

As a last point I'd like to add that there is an established, respectful and good relationship between the developers of the various projects and the wild speculations and fights are amongst the fanboys, and we're not going to join this.

3:18am

by Lorenz Meier

March 8, 2013

Time to bring this thread back to the original question and wrap up some relevant facts: PX4 is not just yet another autopilot platform, instead we did some things quite differently.

Some general remarks on PX4:

• PX4 consists of two parts - the PX4 platform, and application level software like estimators or controllers. There is a sharp and clear separation of the two. e.g. APM runs on top of the OS / platform and does not use the application level software.
• PX4 builds on standards and Ecosystems instead of building yet another one. The NuttX OS is following largely the POSIX standard (if you know the industry-standard VxWorks RTOS, you will love NuttX), communication is done via MAVLink and the platform will continue to align to standards.
• The software API is simple, and much simpler to use than most other embedded platform, as it really abstracts the hardware and builds on common programming / API standards. Developers need to handle PX4 like a 'normal' operating system and should not attempt, as on bare metal designs, to understand and mess with every aspect of the system. Instead PX4 allows the developer to focus on flying. This getting started tutorial [ https://pixhawk.ethz.ch/px4/dev/hello_sky ] nicely illustrates how simple it is to write a new estimator, and it shows that a normal C/C++ background is sufficient.
• It is MUCH harder to kill than existing systems on the electrical and failsafe level. If you really closely look at PX4IO you'll notice that its a fully functional failsafe device, which satisfies to a great degree, if not completely, the outback challenge rules (more details below).

On robustness:

• PX4IO is completely independent from PX4FMU, but loads the RC config and mixer at boot-time. This means that the pilot retains control even if the autopilot fails (can be switched with a configurable RC channel between manual, assisted and auto), and the system can be disarmed (killed) at any time. The huge benefit of this over generic failsafe devices is that non-standard airframes like flying wings still have the correct mixing, and that the mixing in manual and auto mode is the same (as in contrast when de-mixing the RC-mixing, which is done on some systems).
• PX4IO has its own BEC that supplies FMU and IO. The power to peripherals on the 5V and 3.3V rails is limited, so that a short-circuit in the payload can not brown out the core autopilot. It needs an extra BEC for servos, this is just for the autopilot, the autopilot however can also draw power from the servo BEC, so the supply is redundant. This eliminates an important source of failure due to insufficient BECs on other systems.
• It does NOT support multi-PWM inputs, which has been a major source of sadness on other systems. Only PPM-sum / CPPM, Futaba S.Bus and Spektrum satellite systems are supported. This eliminates one potential source of failure.
• All power inputs are reverse-polarity protected
• All power outputs are current limited
• All relevant logic inputs/outputs are ESD protected

Some comments on RTOS aspects:

• The POSIX interface of NuttX makes it very convenient for anyone being familiar with VxWorks or a non-RTOS *nix inspired system like GNU/Linux.
• The RTOS and tasks in PX4 and the scheduling with priorities does not any more require the full knowledge of the main loop. Instead a task can wait (without consuming processing time) until new sensor and attitude data is ready and execute then.
• The overhead for the RTOS is really low, a context switch is in the range of a tenth of a millisecond
• As mentioned on this thread its always a better idea to go with something that is used and tested elsewhere than to roll your own. The benefit of NuttX over FreeRTOS or ChibiOS is its more complete hardware abstraction and adherence to standards (POSIX, which brings things like pthreads, poll(), read(), write()).

 8:59am

by Gary McCray [ http://diydrones.com/forum/topic/listForContributor?user=0hh8v9wxe73oc ]

March 9, 2013

Been working on adding PX4 stuff to the Wiki to get this ball rolling.

The below is copied from my PX4 discussion in the ArduPilot Developers Discussion section.

There are now PX4 sections in the Old ArduCopter Wiki assembly sections:

• Here: https://code.google.com/p/arducopter/wiki/PX4board
• And here: https://code.google.com/p/arducopter/wiki/PX4RC

I am currently only covering the simplest hardware format namely QuadCopter with PX4 FMU board only not using the PX4 IO board.

I have however included the possibility of using the 8 channel PPM encoder with a standard receiver. (Hope that works).

The illustrations are preliminary (as is the text) but for the moment they seem a good start.

I would greatly appreciate interested or responsible parties (Andrew and Lorenz might be good) taking a look at my current progress and commenting on it here, on the comment list there or direct to me.

I am kind of shooting in the dark here and would like to not go to far afield.

Randy kindly forwarded me Andrew's initial description of how to load and flash the PX4 to a Mission Planner compatible state which I understand will now work properly with only a USB connection.

I am seriously hoping this process can be made a bit less daunting in the near future for those interested only in loading the most current Mission Planner oriented PX4 ArduCopter version.

Help greatly appreciated.

In any case I am going to attempt to follow the supplied instructions and if successful will produce a step by step procedural for the Wiki.

I also notice that data is provided on using the PX4 to flash the PX4 IO board.

The last I heard, the IO board was not yet in use.

Has this Changed?

And if so, what is now supported and what are the Associated pins in use?

If there is support I will produce a hardware wiring diagram and appropriate Wiki entries.

9:14pm

by Greg [ http://diydrones.com/forum/topic/listForContributor?user=3r5j7sm61nflz ]

March 10, 2013

So I have couple of of questions and observations from the technical specifications and build manual Gary has been putting in the wiki for PX4. There is mention of improved availability with PX4 over APM but what troubles me is you now have a multitude of interboard connectors which look to be more single points of failure? Also I see mention already of having to use special vibration isolators to mount the PX4 which brings another concern. Are we going to have another board which is too sensitive for the typical vibrations and noise encountered even in a well balanced multirotor platform? I think we have grown to accept APM 2 requires quite eloborate isolation techniques compared with the APM1. Dont't get me wrong but for now the APM2.5 suits my needs and I do not want the added burden of trying to mechanically and electrically isolate up to 4 individual boards which will be very close to each other due to the interboard connectors.

Also unless I misunderstood, to use the existing APM code on the PX4 it must be run in an 8 bit emulation mode for now making the performance gains very limited compared with a native 32bit port.

6:14am

by John Arne Birkeland

March 10, 2013

Greg,

APM1/APM2 before the 2.9.x upgrade was pretty much the only ones not needing good vibration dampening. The reason for this was the simplified method used for leveling and loiter positioning. To get as good performance as the commercial ones from DJI/ZeroUAV etc. we have started using more advanced inertia based leveling and positioning. This makes it MUCH more sensitive to vibration, but not more then any other solution out there. This is why DJI and ZeroUAV use fancy internal sensor dampening systems in their solutions. But even so you often have to use external vibration dampening on top of that, to get the best performance. Even on nicely balanced copters.

6:25am

by Gary McCray

March 10, 2013

Hi Greg I'll take a shot at responding to your very reasonable questions too.

As far as vibration damping, the requirement for the PX4 is pretty much exactly the same as for the APM.

Prior to inertial stabilization, it was pretty much unnecessary and ignored for the APM so nobody bothered.

But now that we have vertical inertial stabilization and soon to be horizontal as well it has gone from irrelevant to priority one.

The vibration isolators that have been used with the PX4 board are the double stud and sleeve type and are available from 3DR here: http://store.diydrones.com/M3_Vibration_Damper_p/hw-ac3dr-20.htmtype

They are not provided with the board as I had incorrectly stated but must be purchased separately. Sorry that will be corrected immediately (I saw them in use on the PixHawk web site and thought they were included, checked my assorted PX4 bags that I just received and found they weren't).

I will get a set, but mostly for evaluation as I am not convinced they will be at all adequate for these boards, probably way too stiff.

The Naza is very well designed and adequately vibration isolated internally and they have been using inertial compensation from day one. Interestingly, Parrot too.

At this point we need to externally provide adequate vibration isolation ourselves and this is still a work in progress.

I use the O-ring suspension method which is generally adequate, but really a kludge. I am working on testing several other methods and expect to have something adequate that is easier to use soon.

The special connectors are actually a good thing very high quality small connector with excellent self retention characteristics.

That said you are probably going to be best off getting some pre-wired cables (at least on one end) from 3DR because these are definitely not designed for home assembly.

I am going to have to order the large "Multi" connector to individual wire cable from 3DR but it is under $3.00.

I will complete a BOM "bill of materials" for the little weird stuff on the Wiki PX4 section in the next day or so. As it says this is a work in progress.

Right now they are just trying to get the PX4 to do exactly what the APM does and it is a major development job to accomplish this, but once it is accomplished, the advantages of the PX4 will rapidly displace the APM.

Basically, for ArduCopter at least the APM is approaching the end of its life cycle.

(3DR probably would prefer I didn't say this and it is just my opinion).

It is out of memory and out of performance.

Right now everything they add has to be shoe-horned in by clever developers weeding out unnecessary bits of code as they can.

That is the classic case for switching microcontrollers.

And the PX4 has a ton of memory and a really powerful microcontroller pretty much x 10 in both cases.

We will be able to do some really interesting stuff with the PX4.

Is it time for most people to buy a PX4 - not today, but it is definitely the time that if you can wait for a month or 2 to do so and then buy a PX4.

10:47am

by Gary McCray

March 10, 2013

I have now included introductory Overviews of the PX4-IO board here: https://code.google.com/p/arducopter/wiki/PX4IOboard

As well as the PX4-FLOW camera boards into the Arducopter Wiki here: https://code.google.com/p/arducopter/wiki/PX4FLOWcamera

8:36pm

by PX4 [ http://diydrones.com/forum/topic/listForContributor?user=0063vwxqp3gy5 ]

March 11, 2013

Thanks Gary, this is much appreciated and of great quality.

@Greg: Can you provide a bit more detail, measurements, papers, industry standards, application notes on your connector argument?

4:19am

by Greg

March 12, 2013

Sure. Firstly and purely for example I am talking about these style IDC connectors here when the flexing female contact is tin and used with gold pins: http://store.diydrones.com/Jumper_cable_5_pin_to_5_pin_female_15cm_p/ca-0001-50.htm

Tin is a good alternative to gold, but there are cases where you should not mix gold and tin in connector applications. Predominantly pressure or flexing contacts. If you want a good starting source Intel have published several industry papers on this. This metal mixing can cause accelerated corrosion, which results in bad connections over time. What happens is small Tin wiskers form from the contact flexing. Sometimes referred to as fretting. Fretting occurs when tin comes in pressure contact with gold or any other metal. Tin debris will transfer to the gold surface and oxidize. Mixing gold and tin leads doesn't always cause an immediate problem. The problem usually occurs over time and can be abated by cleaning contacts.

I do not want to tie up this thread with a debate on the subject by the way. In all matters like this there are varying schools of thought. There are other industry sources and good papers about mixing gold and tin. In some cases you can also get a thermocouple effect from the pressure contact, which can generate a tiny micro voltage which could impact highly sensitive electronic applications. A quick search on the internet, especially memory OEM's will yeild plenty of information.

I was just asking Gary to look out and try an source connectors for gold on gold application. For the most part the APM and I am sure the Px4 using only gold plated pins. It also comes down to personal preferences. In some of my orders I have received some gold edge connectors and some tin plated. There is nothing wrong with the mixing provided you keep an eye on oxidation and not singling out any specific source the female connectors do weaken if you are taking apart your electronics. Again just be aware these do need more maintenance. I have not seen the PX4 multiconnector cables yet. I hope there are gold plated options for people who want to use them. It is certainly my preference as I do not like mixing the two metals in pressure or sliding contacts as explained.

Of course no one would debate gold is better conductivity and has preferable durability properties. Its just more expensive :-(

Hope this is what you are looking for.

3:42am

by PX4

March 14, 2013

For all interested in running APM on PX4 hardware, as announced by Andrew Tridgell its part of the official build and the APM plane / copter / rover builds for PX4 can be downloaded here (including support for PX4FMU standalone or PX4IO):

http://firmware.diydrones.com

Upload support to mission planner is trivial, but will only be added once the overall documentation (to which Gary is greatly contributing) is complete. If you feel like an early adopter, use the console instructions (Windows, Mac, Linux supported) here to upload the build:

https://pixhawk.ethz.ch/px4/users/flash_px4fmu

To flash PX4IO, just put the 'px4io.bin' file into the top level directory of the microSD card and keep the arming button of PX4IO pressed while powering up.

After flashing, PX4FMU will behave like APM 2.5 regarding operation and Mission Planner usage. Thank Andrew Tridgell for putting this in place and making it already quite accessible.

ONE WARNING: The linked builds are daily builds and represent the current work in progress. Its not the same as using a release version.

1:01pm

by Greg

March 15, 2013

Can you explain what you mean when you say "PX4FMU" will behave like APM regarding operation and Mission Planner usage". This is a little vague (no offence meant by the way) but appreciate it is early days and good work is being done between the PX4 and 3DR Robotics groups. :-) What exactly is runing here after flashing the PX4FMU. I am aksing to understand better. Is this a full port of APM to run native and if so is it taking full advantage of the PX4 32 bit architecture? Or is this only an 8bit implementation runing as an RTOS instance? I am leaning more towards the Virtual Robotics / Multipilot 32bit platform at the moment (since there is no sign of APM3 hint hint) which has a full 32 bit version of APM code up an runing and they have a new generation board now which is very compact and robust in design.

Its hard to choose the right direction at the moment So many good choices. To be honest I have gotten use to coding in Ardunio and the PX4 does not seem to offer any future direction here. I am sure the design environment is great for new and expeienced developers. I have gone from Virtex FPGA to Ardunio so firmware level coding and portability of ardunio was the big atraction point. Hence my question of what PX4 can really offer someone coming from the Arduino IDE?

12:07am

by Lorenz Meier

March 15, 2013

Obviously APM on PX4 is utilizing the full resources of the platform, which means 32 bits and FPU. Note that PX4 is officially supported by the APM developers and 3DRs main 32bit platform, plus you get a real failsafe mode in the spirit to what e.g. the outback challenge requires (if you want to).

You can log to the microSD card (e.g. at 100Hz almost unlimited) and you can store parameters on it - something many users find particularly helpful.

APM runs in this mode as high-priority thread as single application.

The real benefit for you as APM user is that you get all the driver level testing and robust electronic design that went into the PX4 platform and official support from the core APM dev team.

You can program PX4 in the slightly adapted version of the Arduino IDE by Pat Hickey if you want to, and the APM code looks the same as it always did if you go down that route. Yet you still can benefit now from far better environments, such as building in Eclipse (which gives you syntax / command completion and single-stepping with JTAG through your code).

12:19am

by Gary McCray

March 15, 2013

Check out the PX4 Wiki now almost done with step by step system load for ArduPilot PX4 Firmware https://code.google.com/p/arducopter/wiki/PX4_First

Some of it could undoubtedly be skipped and its not pretty but you also install the development environment at the same time.

And it does use a few interesting tricks to overcome some of the "found" problems.

Please review this and let me know what is incorrect and what could be done better.

9:13pm

by John Mulligan [ http://diydrones.com/forum/topic/listForContributor?user=2mtza3tz6h2i4 ]

March 15, 2013

Gary it might just be my browser IE9 but the link to the px4fmu file can not be saved from the link and has to be selected one level up in the directory http://firmware.diydrones.com/Copter/latest/PX4/ to save

9:57pm

 by Gary McCray

March 16, 2013

Yeah that will work too Mike.

However by tricking it a bit it can be saved from the file itself.

You have to open the file by going to it which displays it then you have to right click in the middle of it and select "Save As" then change the File Type to "All Files" and save it to the PX4 location I mentioned.

Apparently you managed to do it from one level up.

That might be a better method.

I will play around with it and if it looks good put that (and the correct link) in the Wiki instead.

10:08am

by martin keilloh [ http://diydrones.com/forum/topic/listForContributor?user=17zh19x9zne2e ]

March 16, 2013

Hi Gary,dont no if this is the right place to ask this,will the PX4 ever become like the APM where you just plug it to mision planner,many thank's,Marty.

10:33am

by Gary McCray

March 16, 2013

The PX4 will eventually completely displace the APM.

and as Lorenz says sooner rather than later it has way more memory and way more processing power than the APM and all the same capabilities plus new ones.

Right now behind the scenes and driven largely by AndrewTridgell the PX4 is very far along in the process of becoming one hundred percent compatible with the APM.

And that is just the starting point on the PX4's journey.

The PX4 will almost certainly be "released" within a month or so (either assisted by or in spite of) my best efforts to get it out there for early adopters now.

And when it is released, it will be just as simple to use as the APM.

Because it will be a brand new release there will still be some PX4 specific problems, but my best guess is they will be pretty much laid to rest over then next couple of months.

From there on the potential is nothing but up.

PixHawk's Optical Flow camera is a very sophisticated device with some truly remarkable capabilities and with all the extra performance and memory, ground referenced mapping and navigation will be feasible and that opens a whole new arena.

11:16am

by Greg

March 17, 2013

Gary, you said "The PX4 will eventually completely displace the APM." This pretty much conclusively states there will be no more Arduino based APM devices devleoped by 3DR robotics i.e APM3 One of the primary reasons I have stuck with the Diydrones forum for the past 2 years is the open software roadmap of the code development was on Ardunio hardware making it easy to move from one new arduino platform to the next i.e freedom of choice from the broad range of arduino devices available. It has become increasingly clear from this discussion our forum is starting to be displaced by the PX4 group and this project. I wonder if the main body of APM supporters realises that this direction away from Ardunio has been made in order to move forward with PX4. In other words how long before development of the APM code stops as we know today in favour of native code on PX4.

Perhaps I have this wrong but, I think the two groups should stick to their own forums. Its ok and great 3DR Robotics are offering the PX4 as well as the existing APM2.5 But I object to the Arducopter forum being used as a repository for a non-arduino code and documentation for PX4 People who want to change direction and move to PX4 can go to that groups website. The Arducopter wiki is only for Ardunio based APM.

7:41am

by Rob_Lefebvre [ http://diydrones.com/forum/topic/listForContributor?user=2ah4ml3io2sp6 ]

March 18, 2013

Greg,

First, I don't think Gary's comments should be in any way assumed to be any kind of official direction coming from 3DR vis-a-vis future hardware.

That being said, I have the same heartache you do with regards to leaving the "Arduino" platform. I think the ONLY reason I have been able to contribute to this project is because of it's Arduino underpinnings. I am not a computer programmer. I taught myself C++ in the last year, mostly because of the way Arduino makes it all accessible for beginners.

However... I also know in my head that the Atmel 2560 has taken us about as far as is possible with thing. It's pretty amazing what we have done. The APM is doing things on a little 8-bit processor that others struggle do to on a 32-bit platform. But it's really, really just running out of potential for growth.

I would be quite happy to take the next release for Arducopter as the final feature release, and then just go to bug-fixes for AVR after that. If "development" stops on the AVR line, I don't think anybody could possible be upset by that. The APM2.5 delivers what was promised. Finally.

I will continue to look to the future however, and that will be on a 32 bit platform. I'm not sure if I'll be able to contribute, but I'll try.

Sure, I'd have liked it if the next board was similar to the APM2, that being a single board, based on Arduino Due, specialized for UAV use. The problem is, however, that Arduino did not choose the processor we would have liked for Due. The floating point processor of the F4 is really important to us.

We may see an APM3, which is more like the APM2 than is the PX4. And maybe it will still be programmable by Arduino IDE. I don't know. But please note I have absolutely NO insight into future hardware at all, zero. So this is just a guess for me.

12:31pm

by Gary McCray

March 22, 2013

Hi again all, PX4 is Up and running in both modes.

Two entries in Wiki:

PX4FMU Only is here: https://code.google.com/p/arducopter/wiki/PX4_First

And PX4FMU plus PX4IO board is here: https://code.google.com/p/arducopter/wiki/PX4FMU_PX4IO_First

Please, get in there, kick the tires and give me feedback.

4:37pm

by Lorenz Meier

March 22, 2013

Gary,

Thanks for putting all this effort into this. I propose you split out the developer guide from both pages, since the really required steps are much simpler, I think I can cover both boards in just one short post:

Prerequisites:

• Download a recent Mission Planner installer, install it. Open the directory, look for px4uploader.exe, right click it and drag it to the desktop. Select "Create Shortcut" from the context menu that opens.
• Download a recent 'px4io.bin' file from here [ http://firmware.diydrones.com/PX4IO/latest/PX4IO/ ]
• Download the Windows driver (the APM version currently registers itself with a different ID than the native PX4 version) and install it (driver [ http://firmware.diydrones.com/PX4_Windows_Driver/ ])
• Download the firmware version for plane / copter / rover from here [ http://firmware.diydrones.com ]

Thats really all needed on the downloads side, just Mission Planner, binaries and driver. Then flashing is also very easy:

• Make sure to remember where you put px4fmu.px4 (e.g. into your Downloads folder)
• Double click the px4uploader shortcut from your desktop. Point the uploader to the px4fmu.px4 file, click upload and reset the board, wait for the upload to complete - done.
• For PX4IO, put the px4io.bin file into a microSD card in the top level directory. If you want to flash this version, keep the arming switch pressed down WHILE you power on (via USB or via battery). Wait ~10 seconds until the red led on IO stopped blinking and the blue is solid or slowly blinking.

What I've described here is the complete APM@PX4 setup from an "empty" Windows machine to having APM running on the board. Gary, you might want to correct details, this is from the top of my head and I'm not running Windows. You've done a wonderful job on the wiki, but now thats its running I propose to strip as much complexity out as possible. Please start a dedicated developer page for the dev instructions, and I can probably help there as well to strip them a bit down.

As Gary already said, while the APM team is moving along with their software testing, they will probably make the setup process similar to APM 2.5 HW. Its just in general a good idea to take small steps.

5:05pm

by Gary McCray

March 22, 2013

Hi Lorenz,

I know you are right, I will work on setting this up as you suggest.

I was just following what to me was an ensured process and I felt that having the PX4 Toolchain installed and becoming familiar with it might be a good idea.

However, I am really only using it as a file repository for the PX4FMU and PX4IO files, so it really is superfluous for this use.

Putting the two PX4 files the USB driver file and the Px4Upload shortcut in a folder on the Windows desktop would seriously reduce the number of steps.

That is probably the way to go.

I do think it is worthwhile to maintain local backup of the files in an easily accessible spot.

Doing that and getting rid of the PX4 Toolchain will remove quite a few steps.

I do feel it is necessary to provide a "complete" walk through for any possible users including those largely unfamiliar with Computer operations, so even without the PX4 Toolchain it is still likely to be a bit "wordy".

I have already thrown together the start of a dedicated Developer page (Totally a work in progress) Here: https://code.google.com/p/arducopter/wiki/PX4DevEnv

Also, at the moment I am concentrating on the 2 firmware object load pages and on the new hardware page for the PX4IO wiring I am working on right now.

I will definitely strip out the PX4 toolchain part of the process and try to make the process a bit more linear.

Truly, thank you very much for your input.

6:40pm

Copyright 2013 http://diydrones.com/forum/topics/apm-vs-px4-what-to-get