3689545530?profile=original

The new PX4 Pixhawk module is an evolvement of the existing FMU and IO modules and completely compatible. The main difference is the target audience: While the FMU and IO stack is super small (the size of an average 8 ch RC receiver) but in some ways almost too densely packed, Pixhawk has more space, more serial ports and more PWM outputs.

As the above picture shows, there are two groups of servo connectors, one main group of 8 outputs which are wired through the backup processor, and an auxiliary group of 6 outputs directly wired to the main processor. The port labeled "RC" can take normal PPM sum or Futaba S.Bus inputs, the port labeled "SB" can read RSSI our output S.Bus to servos. A Spektrum satellite compatible port is on top (labeled SPKT/DSM).

The basic operation is the same, and the software is shared. Inside Pixhawk a FMUv2 and an IOv2 do their duties on a single board (and developers will find that the software will refer to FMUv2 and IOv2)

The main differences between old and new are:

  • 14 PWM outputs vs. 12 PWM (old)
  • All PWM outputs on servo connectors (old: 8 on servo, 4 on DF13)
  • 5 serial ports vs. 4 (with some double functionality, so only 3 in some configurations on old version)
  • 256 KB RAM and 2 MB flash vs 192 KB RAM and 1 MB flash (old)
  • Modernized sensor suite (latest generation)
  • High-power buzzer driver (old: VBAT driven, not as loud)
  • High-power multicolor led (old: only external BlinkM support)
  • Support for panel-mounted USB extension (old: not present)
  • Revised, improved power architecture
  • Better protection on all input / output pins against shorts and over voltage
  • Better sensing of power rails (internal and external, e.g. servo voltage)
  • Support for Spektrum Satellite pairing (needed some manual wiring work in v1, but also software-supported)
  • No more solid state relays on v2 (was not really used)
  • Connectors easier to disconnect in case, as the surrounding plastic helps to place the fingers correctly (more on this in a separate post)
  • Case prevents one-off failure operation of servo connectors
  • The new unit is consirably larger, has the same height, but offers in general more handling convenience.
  • External power supply similar to existing 3DR power brick (every unit comes with a free module)

Both generations offer the same backup / override processor that allows failover to manual if the autopilot fails in fixed wing setups. For software developers the differences are nicely abstracted in the PX4 middleware, and can be sensed / configured at runtime.

Pixhawk is available for pre-order here.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Lorenz:

    That doesn't solve the problem with the self-manufacturing, e.g. if you want to connect any type of own hardware.The question is also if the DF-13 are designed for frequent plugging/unplugging or are they designed to be basically low-cycle board connectors?

    It's surely a matter of personal preference, but I'd rather have a little bit bigger casing and in return plugs that are easy to handle in everyday-use.

  • Developer

    @Stefan: We can't fit the number of interfaces with 2.54 mm connectors. Completely impossible. The JST SH are only rated for 0.5A and are also out, so there is no way to get this density and a reasonable current capacity without having a connector in the 1.25 mm pitch range. I will post a video today how to unplug. The catch with DF13 is that they have been designed very smart to be convenient, but you have to know how to use them, and because they have been designed to be secure, just pulling is clearly not how to use them.

  • I absolutely agree with that!

    It is not rare that compass and GPS are mounted separately from the main AP and it's also not rare to take the AP out from an aircraft, e.g. to get access to the USB port.

    The connectors should be more robust and also a type which is available for easy self-manufacturing. Just the tool to crimp those horrible DF13 plugs costs well over $150, not to mention that everything is just tiny and not easy to handle manually. Normal Molex/DuPont style 2.54mm-spacing plugs would be ideal! They are robust, easy to source everywhere (e.g. I didn't find any source for this DF13-stuff in Finland), CHEAP and easy to crimp and the tools are cheap too.

  • Just checking.  I've seen too many companies turn to the dark side when they release a really big/important product.

  • 3D Robotics

    Seb: Of course! 

  • @Chris This new GCS software of which you speak... It will be open source, right?

  • Thank you for this post.

    With this post and the previous one I will start to put together a wiki page describing capabilities and interfaces to the PixHawk.

    As well as another page detailing comparisons and differences between APM 2.5/6, PX4 and PixHawk.

    Not that it isn't pretty clear at this point which way we are heading.

    I know you have 3 ADC in, are their any other accessible but not dedicated inputs available, analog or digital?

  • Moderator

    I think that is better to don't use i2c in safe design it's a very bad bus ... 

  • Admin

    @Lorenz,

    I am not talking about the combination GPS/Compass module, but the stand alone compass module. There are 3.3 vdc pull up resistors on the output of the Honeywell HMC5883L chip to the compass level converter. The level converter is provided with Vin which in this case is the 5vdc on the PX4 I2C connector. Therefore there is no way not to have 5vdc on the compass data and clock lines going to the PX4 I2C input which, according to the PX4 specs has the I2C clock and data lines pulled up to 3.3vdc.

    Regards,

    TCIII ArduRover2 Developer

  • Developer

    Hi Tom,

    Please consult the schematic again (at least for the current compass module). The pullups are on the 3.3V rail, which is independent of the power source selection safe to use. It will work with the 4-pos I2C connector on PX4 FMUv1 and v2.

    I will also check about the on-peripheral pullups. The normal setup is to have those exclusively on the device serving as bus master. That seems to complicate things a bit in general and might not be the optimal design pattern.

This reply was deleted.