APM:Copter 3.0.1... cannot connect PX4FMU to Mission Planner

I’ve reflashed my PX4FMU (v1.6) to v3.0.1 using Mission Planner and all appeared to work correctly (in that it erased, loaded and verified, with no errors or warnings). Disconnected the FMU, reconnected, checked COM port and baud rate… waited an appropriate time as advised in tutorial… and clicked Connect… nada… have tried this 6 times… all timeouts. Have tried different USB ports. It’s reporting no heartbeat packets detected, which sounds like the firmware isn’t running properly and/or establishing a Mavlink serial link over the USB port.

Am I doing something wrong? Is there something I’ve missed. I’ve scoured the wiki/tutorials and cannot work it out. Is anyone else having this problem?

Also, AFAIK my hardware is working just fine, as I had it running an early version of ETHZ’s PX4 stack based on pixhawk code earlier this year. I decided to shift to APM to give it a whirl on this hardware… pity it isn’t working. Suggestions welcome.

Thanks,

Tim

@Timkin,
I have found that a full up PX4 module, which includes a GPS, PPM R/C receiver, and external compass will not connect unless I use a powered USB hub. The PX4 module draws a lot of current and if you are using a PPM converter for your R/C receiver the current draw is even more. Apparently most PC USB ports cannot supply enough current to the PX4 so there is voltage droop which causes the PX4 not to communicate with MavLink.
I suggest that you try using a powered USB module to connect full up PX4 from your PC. Otherwise, I have no problem connecting when just using the USB connection to power the PX4 FMU/IO by itself.
Regards,
TCIII Admin

Thanks for the quick response and advice. I’m connecting only the FMU via USB to the PC, so no other current draw other than the board itself. I’ll investigate using a powered USB hub… I should have one lying around at work. I’d be very surprised that the board alone would cause a sufficient voltage drop as to not be sufficiently powered… but anything is possible and I’m willing to consider all ideas at this time.

Thanks.

@Timkin,
Do you have the micro sd card installed in the FMU and the speaker hooked to the FMU?
Also, I usually have success watching the leds on the FMU. The initial led pattern indicates that the FMU is in the boot loader mode. Then, when the red led stops flashing and the speaker beeps, the FMU is now looking for the MavLink connection. This is when I hit the connect symbol on the MP.

Tridge, our PX4 programmer, has recently increased the number of cycles the PX4 code will look for the MavLink connection and respond to that connection request.

Regards,
TCIII Admin

My FMU didn’t come with either a speaker or SD card… it was one of the first few released. I did purchase a compatible micro SD card as listed on ethz’s site (SandDisk microSDHC 8 Gb - class 4). I am getting what appears to be normal led behaviour (as described in tutorial)… blinking red which settles to constant blue.

I’ve checked the SD card contents as well. It contains
ArduCopter.stg (4kb)
boot.log (101 bytes)
logs (folder, empty)

The boot.log file contains the following information from last boot…

Starting APM sensors
Trying PX4IO board
No PX4IO board found
Starting ArduPilot
rc.APM finished

That would seem like a reasonable log file, although not being experienced with the boot process/code I’m only guessing.

I too seem to be having the problem. I have the FMU and the IO board hooked up. After flashing with the latest firmware, v3.0.1, i plug out and plug in again. The device shows up under the Device manager under ports fro the first few seconds. After which it disappears. Have I done something wrong?

I fixed my problem! Thanks!

…and this is now resolved. The problem is that the wiki neglects to remind you (as the previous firmware page did) to check the COM port settings on you PC. This is obvious to me now in hindsight, but when you’re sitting there wracking your brain wondering whether the firmware loaded and booted properly, you’re usually focusing on the FMU and NOT your PC as the source of the problem.

The issue was that the driver installs to default bit rate (9600), but requires equivalence with the MP setting. Both should be 115200, requiring manual setting on both sides of the connection.

For those unfamiliar with manually change COM port settings on Windows:

  1. Right-click on ‘Computer’ in your start menu and select ‘Manage’
  2. Select ‘Device Manager’ in the left panel.
  3. If the FMU is plugged in to the USB port, there should be an entry for it under ‘Ports (COM & LPT)’. Expand this menu item in the right panel and right click on PX4 FMU (COM?), where the ? will be an integer value. If there is no such entries, the USB port hasn’t made a connection. Try replugging it. If this fails, you probably have a firmware or cable problem.
  4. Select Properties from the pop-up menu and select the ‘Port Settings’ Tab.
  5. Ensure that the ‘Bits per second’ list box is set to 115200.
  6. In Mission Planner, ensure that the bit rate list box (top right of the application) is set to 115200 and that the COM port selected is the same number as the entry in the Device Manager list.
  7. Click connect. If you do not get a connection, again, this is likely a firmware failure. If you do, enjoy your PX4FMU!

I’m having the same issue, except I’ve gotten it to connect 2-3 times randomly when changing the Flow Control to Hardware or Xon/Xoff.

Tried powered USB hub, tried LiPo power, can’t get it to connect. Like I said, out of maybe 200 attempts I’ve actually gotten it to connect 2-3 times.

Full description:
diydrones.com/forum/topics/p … e=activity

@Timkin,
I have never had to adjust any of the PC Comm port setting to communicate with the PX4.
What version of the MP are you using?
I always click the connect image after the PX4 has gotten out of the boot loader sequence. At that point the red led has quit flashing and only the blue led is on.
Regards,
TCIII Admin

@Timkin,

it is very important that you start the connect only when the PX4 is completely up.
After a reset, the PX4 stay for a moment in Bootloader mode. In this moment the PX4 is listet in the Comports. If you connect now to this port, you are in the bootloader - that is not wat you want.
You have to wait for the Startup Melody (you need a speaker connected to your PX4), and take a look on the
onboard LEDs of the PX4 and wait until the red stops flashing.

Marco

This problem has returned and it’s definitely NOT the baud rate as it was previously.

I’ve decided to actually deploy my PX4 into a new copter build (it’s been sitting in a box for most of this year)… I’ve got a new setup on the PX4FMU+PX4IO and I’ve gone back over every stage to test everything is correct. I’ve stripped down peripherals to just the safety button and buzzer and tested both with USB power and battery power (I’ve checked I’m getting a stable 5 volts to the board). I’ve confirmed firmware is loaded correctly and I can power up the system and receive correct signal tone indicating the board is operating correctly.

I cannot connect from Mission Planner to the PX4… it times out and reports no heartbeat packets detected.

Yes, I’ve waited until after the board is initialised (I’m not that dumb). I’ve checked every aspect of the COM port settings against recommendations and triple checked baud rates on both ends. I’ve tried re-flashing firmware using Mission Planner… it proceeds and concludes without error and the board can be intialised correctly.

I’ve read recently that several other people are having this problem. Is there a known cause or just the usual speculations? Do any of the devs familiar with the PX4 HAL have any insight into this?

Anyone who has had this problem and found a solution, please take a moment to respond and let me know what you did to resolve the problem. Thanks.

@ Timkin,

Were you ever able to resolve this issue?

Thanks