<<< etheli.com Home Page

PX4MINIAIO / MINIPX4 Flight Controller



The PX4MiniAIO is an ArduPilot / PX4 / Pixhawk compatible flight controller manufactured by Airbot.

Listing page:  http://www.readytoflyquads.com/rtf-px4miniaio-v1-3

Discussion thread:  http://www.rcgroups.com/forums/showthread.php?t=2500796

I've been flying PX4MiniAIO boards with ArduPlane and ArduCopter firmware with good results.  See below for firmware files, issues and fixes for these boards.

Update 7/2018:  This board has been discontinued, but I have a couple of builds still using it and have been able to upgrade to the latest ArduPilot versions.  The one issue I ran into is that the telemetry radio on UART2 stopped working.  I figured out a fix and posted a GitHub-PR-patch here.  For firmware files patched with this fix, see the 'px4_etPx4v1UartDFix' directory here.


Note:  Most (if not all) of the issues and fixes below have been addressed in later releases of ArduPilot.


Firmware files

These are various firmware files for the PX4MiniAIO board that address the issues described in the sections that follow.

ArduCopter v3.3.3 release build with mod to make all compasses external.  This build also features a modified startup script ("rc.APM") that will check access to the SD card and reboot the board if the check fails.  This can work around an issue where the bootup sometimes fails with a steady-white LED.  (Full source for this build is here and here.)
Quad:  ArduCopter_v3.3.3rel_rcApmAllCompExt_20160428_px4v1_px4.zip
Hexa:  ArduCopter_v3.3.3rel_rcApmAllCompExt_20160428_px4v1hexa_px4.zip
Tri:  ArduCopter_v3.3.3rel_rcApmAllCompExt_20160428_px4v1tri_px4.zip

ArduCopter v3.3.3 release build with mod to make all compasses external and RSSI_CHANNEL parameters (see here for info) and modified startup script ("rc.APM").  The RSSI_CHANNEL parameters are implemented in the current ArduPlane release and will be implemented in a future ArduCopter release.  For this firmware I've applied the changes for the RSSI_CHANNEL parameters to version 3.3.3.  (Full source for this build is here and here.)
Quad:  ArduCopter_v3.3.3rel_rssiChRcApmAllCompExt_20160501_px4v1_px4.zip
Hexa:  ArduCopter_v3.3.3rel_rssiChRcApmAllCompExt_20160501_px4v1hexa_px4.zip
Tri:  ArduCopter_v3.3.3rel_rssiChRcApmAllCompExt_20160501_px4v1tri_px4.zip

ArduPlane v3.6.0 release build with a modified startup script ("rc.APM") that will check access to the SD card and reboot the board if the check fails.  This can work around an issue where the bootup sometimes fails with a steady-white LED.  With this version, if a second compass is installed the COMPASS_EXTERN2 parameter should be set to 2 for "forced external".  (Full source for this build is here and here.)
ArduPlane_v3.6.0rel_modRcApm_20160625_px4v1_px4.zip

To use the above firmware builds, extract the '.px4' firmware file from the '.zip' and upload it to the PX4MiniAIO flight controller using the Mission Planner (under "Install Firmware" | "Load custom firmware").

Note:  These firmware files should be considered test releases and are to be used at your own risk.

Boot Fail with Red LED Issue

When I load the "APM:Copter V3.3.3 Quad" firmware via the Mission Planner and run it, the bootup consistently fails with the steady red LED -- same as others are reporting.  (BTW, when this happens, the error message via the NSH serial console is "looking for microSD... / nsh: mount: mount failed: No such device.")

However, I've found that if I build the same AC 3.3.3 version from source ("make px4-v1"), the resulting firmware boots up much better; I never seem to see that error.  My best guess is there's something different about the PX4Firmware / PX4NuttX sub-modules on my development system vs. the official release.  (My development system is a Windows 7 machine; reported versions are:  cc.exe (GCC) 4.6.2, GNU Make 3.81, Python 2.7.3)

Note that if the PX4MiniAIO board is booted without an SD card installed, it will exhibit the same boot fail with red LED, so be sure that a working SD card is installed.  Sometimes formatting the SD card on a computer can fix issues (do a "full" format, not "quick").

Hopefully there will be an official fix for this at some point, but in the meantime, links to my builds are above.


Battery Monitor

A power module (like this one) can be attached to power the PX4MiniAIO board and provide voltage and current readings.  The wiring of the "Voltage input" and "Current input" lines should be checked to make sure they match on both sides.  These are the settings I've found work well with the power module:

BATT_AMP_OFFSET,0
BATT_AMP_PERVOLT,7.2
BATT_CURR_PIN,11
BATT_MONITOR,4
BATT_VOLT_MULT,1.78
BATT_VOLT_PIN,10
[set BATT_CAPACITY to about 75% of battery mAh]

The values for BATT_VOLT_MULT and BATT_AMP_PERVOLT can be different depending on the power module used.  The BATT_VOLT_MULT value can be calibrated by measuring the battery voltage with a meter and adjusting the BATT_VOLT_MULT value until the reading in Mission Planner matches the meter reading.

Calibrating the BATT_AMP_PERVOLT value is trickier and tends to have more variation.  I've done it by attaching a Watt Meter to the copter, displaying "current" in the 'Tuning' graph in the Mission Planner, flying the copter briefly in a hover, and then comparing the maximum-amperage reading on the meter vs. the peak reading on the graph.  After a few iterations of this I can get it at least in the ballpark of an accurate reading.

(To display the 'Tuning' graph in Mission Planner, click the 'Tuning' checkbox at the bottom of the main screen.  To show live battery current, double-click on the graph, uncheck any selected items, and select the "current" item.)

See here for ArduPilot documentation on power module configuration.


Compass

There's an issue with the PX4MiniAIO board where, when a compass is connected to the IIC2/GPS connector, that compass is always forced to be "internal" in the configuration.  This is problematic because then a compass orientation cannot be configured.  The above firmware builds have a modification that makes all connected compasses be set to "external."  In future, official firmware releases will have COMPASS_EXTERNAL settings support a value of 2 for "forced external" -- see here for more info.

See here for a post on compass orientation.  The pic below shows how I have mine mounted, and I have "COMPASS_ORIENT,8" ("Roll180") in my settings.  I'm using a GPS that does not have a compass, and I've had good results with this setup.



If you're seeing "Compass Variance" messages, these indicate a mismatch between the compass reading and the other sensors (accelerometer, etc).  If the compass is mounted properly, the heading in the Mission Planner should track the vehicle.  If it's not working right you can try doing another compass calibration, or moving the location of the compass (and redoing the calibration).  See here for info in the APM docs.

MinimOSD and Telemetry

If you connect a MinimOSD board to UART2 -- all four wires, and without a telemetry module also connected -- you can get it working with these settings:
SERIAL2_BAUD,57
SERIAL2_PROTOCOL,1
SR2_EXT_STAT,2
SR2_EXTRA1,5
SR2_EXTRA2,2
SR2_EXTRA3,3
SR2_POSITION,2
SR2_RAW_SENS,2
SR2_RC_CHAN,5

(If you also have a telemetry module connected to the same port then the TX pin on the MinimOSD should be left unconnected and the above settings are optional.)

If you're connecting MinimOSD or Telemetry (or both) to UART2, you also need this setting (otherwise the output tends to fail on first boot after being off for a while):
BRD_SER2_RTSCTS,0

Bootloader SBUS/PPM-In Stuck Boot Issue

There is an issue with the PX4MiniAIO (and other PX4-V1 boards) where the bootup can get stuck when a receiver connected to the SBUS/PPM-IN pin (PA10) is not receiving data from a transmitter.  If that PA10 pin is pulled low at startup, the bootloader code goes into a "wait" mode and stays there until the pin goes high.  It seems that only some receivers work this way.  When I tested with an OpenLRSng-DTFUHF receiver, its PPM output was not pulled low when not receiving data.  Others, however, have reported the issue where the PX4MiniAIO board will not boot up when the transmitter is not turned on.

In the bootloader code, this functionality is described in the comments as "forcing the bootloader."  Interestingly, there is a similar functionality for the PX4-V2 (Pixhawk) boards, but it was disabled in response to PX4-Bootloader issue #46.  It seems reasonable, then, that this functionality should also be disabled in the PX4-V1 code.  (This is accomblished by commenting out the "#BOARD_FORCE_BL..." lines in the "hw_config.h" file, as shown here.)

Here is a modified bootloader file, compiled from the "diydrones/Bootloader" code (with the updated "hw_config.h"):  px4fmu_bl_bin_diyd_NoV1ForceBlPin_20160207.zip  (extract "px4fmu_bl.bin" file from '.zip')

The full modified source code may be found in this diydrones_Bootloader_NoV1ForceBlPin_20160207.zip file, and here on github:  https://github.com/ethomas997/diydrones_Bootloader/tree/NoV1ForceBlPin

I've posted a github issue on this in the PX4/Bootloader project:  https://github.com/PX4/Bootloader/issues/50

Note that if your PX4MiniAIO board and receiver setup is not experiencing this issue then there is no reason to update the bootloader.  The bootloader files posted on this page should be considered beta-test releases and are to be used at your own risk.

The PX4 bootloader can be updated using the 'blupdate' command via the 'nsh' console (see the PX4-bootloader page for general info).  However, when the ArduCopter firmware is running, the 'blupdate' command can fail because of not enough memory available.  (One workaround is to temporarily load the AntennaTracker firmware.)  This is a procedure I've found works well:

1. Power off the PX4MiniAIO board, remove the SD card and plug it into a computer.
2. Copy the modified "px4fmu_bl.bin" file to the SD card (top-level directory).
3. Create a file called "nostart" and copy it into the "APM" directory on the SD card.  The "nostart" file can be empty.  If there is no "APM" directory then create one.  (The "nostart" file will make the board boot into the 'nsh' console.)
4. Unmount the SD card from the computer ("safely remove hardware" on Windows), and plug it back into the PX4MiniAIO board.
5. Connect the PX4MiniAIO board to the computer via the USB cable.
6. Run the Mission Planner software, select the COM port (on the upper right) for the USB connection, click on the 'Terminal' button, select "PX4/PIXHAWK" in the pull-down on the upper left, and click 'Connect'.  You should see text scroll by as the terminal is connected to the 'nsh' console, ending with the "nsh>" prompt.
7. At the "nsh>" prompt, enter:  bl_update /fs/microsd/px4fmu_bl.bin
8. The response should be:
  bl_update: image validated, erasing bootloader...
  bl_update: flashing... bl_update: verifying...
  bl_update: bootloader update complete
9. At the next "nsh>" prompt, enter:  rm /fs/microsd/APM/nostart
  (This will remove the "nostart" file, allowing the board to boot normally.)
10. Click 'Disconnect' and unplug the USB cable for the PX4MiniAIO board.

At this point the PX4MiniAIO board should boot normally and the SBUS/PPM-input issue should be fixed.  If there was a problem with the bootloader update resulting in a board that cannot be booted or communicated with, the bootloader can be repaired using the "Upload via DFUse" option on the PX4-bootloader page.

Older firmware builds:

 ArduPlane v3.5.3 release build with mod to make all compasses external and modified startup script ("rc.APM").  (Full source for this build is here and here.)
ArduPlane_v3.5.3rel_rcApmAllCompExt_20160501_px4v1_px4.zip

ArduCopter v3.3.3 release build.  This build also features a modified startup script ("rc.APM") that will check access to the SD card and reboot the board if the check fails.  This can work-around an issue where the bootup sometimes fails with a steady-white LED.
ArduCopter_v3.3.3rel_modRcApm_20160404_px4v1_px4.zip

ArduCopter v3.3.3 release build with RSSI_CHANNEL parameters (see here for info) and modified startup script ("rc.APM").  The RSSI_CHANNEL parameters are implemented in the current ArduPlane release and will be implemented in a future ArduCopter release.  For this firmware I've applied the changes for the RSSI_CHANNEL parameters to version 3.3.3.  (Full source for this build is here and here.)
ArduCopter_v3.3.3rel_rssiChanModRcApm_20160404_px4v1_px4.zip

ArduPlane v3.5.2 release build.  This build also features a modified startup script ("rc.APM") that will check access to the SD card and reboot the board if the check fails.  This can work-around an issue where the bootup sometimes fails with a steady-white LED.
ArduPlane_v3.5.2rel_modRcApm_20160404_px4v1_px4.zip

ArduRover v3.0.0 release build.  This build also features a modified startup script ("rc.APM") that will check access to the SD card and reboot the board if the check fails.  This can work-around an issue where the bootup sometimes fails with a steady-white LED.  (Full source for this build is here and here.)
APMrover2_v3.0.0rel_modRcApm_20160423_px4v1_px4.zip

ArduCopter_v3.3.2rel_7f16e4d6_etBuild_px4v1_px4.zip

Here is a build for "traditional helicopter" using the same ArduCopter 3.3.2 code ("make px4-v1-heli"):

ArduCopter_v3.3.2rel_7f16e4d6_etBuild_px4v1_heli_px4.zip

Here is a build for ArduPlane v3.5.0beta1:

ArduPlane_v3.5.0beta1_eec1b95f_etbuild_px4v1_px4.zip


My ArduPilot patches may be found here.

Click here to contact me

Back to etheli.com home page


ET Heli