APM vs. PX4 – what to get? - Discussions

Noth666 March 12, 2013 at 2:05am

Will be starting on the blog bit this afternoon, in the meantime a small update/tip if you run win7 and get stuck in the bootloader part not being detected when flashingnin eclipse, there is a trick to make a micro SD that will wipe firmware and force it to stay in bootloader until a new firmware is flashed. Found under the answers section for 'force bootloader'.
Anyways all my gear seems to be in perfect order, havent tested the IOAR board yet as I need to solder in the power cable and various headers. But was able to run px4flow fully in QGC and was able to build and flash latest release of px4fmu firmware onto the board and it responds as expected.

Noth666 March 11, 2013 at 3:31pm

I got the px4flow, got it up and running in QGroundControl in calibration mode with mavlink, and I am getting the picture as well into the HUD view so it's def working OK. Had to manually force win7 to install the driver though. It appears as a standard mavlink device, and exposes all kinds of settings direct in QGC plus of course feeds back all the gyro rates, sonar distance and also flow/camera angle and a bunch of other data that I didnt yet dig into. Good thing it also gives the sonar by default so we can use it directly for altitude hold when low enough.

The DF13 6pos to 5pos was included in the PX4FLOW baggie, so it will connect to UART5 on the PX4IOAR straight with that cable - nifty.

2 slight downers sofar, the M3 nuts for attaching the whole thing to the AR drone cross were missing so I havent got it all mounted yet, and for some reason I am not able to get any action other than LED's on the PX4FMU sofar. I think I need to flash it first but I would have expected some version of the firmware to be on it for testing at factory, but maybe they put something else on for that.

I will be making a blog of the general 'build', got tons of unboxing pics also ready.

But yep Gary, we seem to be some of the first on here to jump on the PX4 bandwagon so I will let you know anything I find of use for the flow to add to wiki, and also for the fmu itself. It will take a few weeks I guess for the FrSky stuff to get here so I can't get it up in the air just quite yet.

Noth666 March 11, 2013 at 5:28am

@Gary,

I think the rubber standoffs are included in the PX4IOAR package rather than the PX4FMU package, I will confirm or not in a few hours when I get to unboxing my kit.

Did you also get the PX4FLOW? I see you did add some info about it on the wiki. Still slapping myself for forgetting to order the 6 pos cable, but I am not 100% how to connect the two together... I am guessing some kind of custom Df13 6position to DF13 5pos + power is needed, but I can't seem to work it out from the documentation, did you figure this out yet?

Noth666 March 11, 2013 at 4:57am

I just recieved my px4 package. I will be going with the px4 native rather than the arducopter port, on an AR drone.
I also got the px4flow at the same time.
Will be adding some infos as I get it up and running, still need to wait for the frsky stuff to come from HK before I can try to fly it.

Gary McCray March 10, 2013 at 8:36pm

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

Greg March 10, 2013 at 6:14am

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.

Gary McCray March 9, 2013 at 8:14pm

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.

Jethro Hazelhurst March 9, 2013 at 8:02am

+1 @ Gary McCray
Lorenz, the PX4 looks to be a well engineered piece of technology. Clearly allot of thought has gone into it's design by people who know what they are doing.

Developer

Lorenz Meier March 8, 2013 at 7:59am

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

Stefan Gofferje March 8, 2013 at 6:39am

About the safety, I have a design flying around which I wanted to blog somewhat soon. I started drafting it after reading the heated discussion of dronesavant about 3DR staff flying to close to spectators and stuff...

The idea is to have a board with (solid state-) relais that - when RC-activated - physically and unoverrideable cuts the power to the motors and requires to be reset by a button on the device itself (i.e. impossible to reset via RC). It could additionally have an output to trigger a parachute if necessary. The idea is to have some kind of panic button just in case the 3, 4, 6 or 8 meatmincers come too close to anything living.

Discussions

APM vs. PX4 – what to get?

Replies

Activity