@Jetson-Nano Each host pc will be different depending on what peripherals you have plugged in. Run sudo dmesg -wH and plug in your flight core, you should see which port it enumerates on in the dmesg output

@Jetson-Nano It's not something we've tried. The easiest way is to load firmware through QGC.

@Jetson-Nano Unfortunately not given the state of the board

@Alex-Kushleyev I figured it why the orientation estimator wasn't running after reading through this post, where that user had the same (plus a few more) problems: https://forum.modalai.com/topic/1755/setup-problems-on-new-boards-sensors-and-qgc-connection-problems/18

Basically the problem is that the firmware as-shipped assumes you have at least one active mag, but that the built-in one isn't active. The documentation didn't say how to change the PX4 parameters to make it work without one. The default build does not start the built-in mag, so if you don't have an external plugged in (as in my use case), then EKF2 gets stuck while looking for the reading for one without any error printout, making it unclear what the problem is. I initially tried the version of activating it by adding the boot line to the etc folder of the sd card, and that worked once, but then it got deleted on the next reboot for unknown reasons. That is an easy enough fix with just a firmware rebuild where the magnetometer is started by default. That really is the version you should ship unless you are going to specify in your documentation that the as-shipped version will need an external mag to function. With the firmware as-is, you have to change two parameters on PX4 to make it work, specifically you have to turn off EKF2 magnetometer fusion and whether or not the system has a mag at all. Ie. EKF2_MAG_TYPE to NONE and SYS_HAS_MAG to Disabled. After doing that it will run.

Still haven't sorted out the issue with the telem lockout. I'll see if that got fixed with EKF2 now running normally.

@Vinny @Moderator Thank you for the response.

The reason why we suspected a power issue is that the Flight Core PX4 logs have gaps in data. My apologies as I should have included that info initially. Here is an example from manual setpoint data.

6b5c0659-91f0-424d-93ae-6f5fb178bcb8-image.png

Here is a scatterplot for throttle manual setpoint data to show that those straight lines on the line graph are indeed gaps in data and not inhumanly smooth setpoint changes.

bdc82181-0b10-4f33-a424-a91274f00989-image.png

These gaps are consistent across all the data in the log, which led us to hypothesize that power was lost during these instances. We are using a custom controller that employs SBUS joystick protocol through QGC. Let me know if this info sparks any other ideas or is reminiscent of another issue.

Hi @jacobcayetano1
There are still over 500k units in available distribution which we can access.
I would not worry at all at this time and I fully expect we can still build FCv2 as is for years to come.
Our parts sourcing expertise is top notch!
(not sure if you recall but during the parts shortage craziness of 2020-21 we were one of the few vendors who still had product in-stock and shipping!!)
If you had a large order in mind, any head's up is appreciated so we can be sure to have sufficient stock.
Thanks!

see https://forum.modalai.com/topic/3640/ardupilot-on-voxl2

@prawinsankar , can you please clarify which firmware you are talking about?

If you are referring to PX4 and drivers for RC, you have to look at the specific driver for the RC and see how the baud rate is passed to the driver, typically as a param or launch argument when the PX4 module is loaded.

Alex

Thanks for the reply! Good to know it was a known issue.

One thing, the links you sent point to modalai's fork of the px4 firmware, but alot of changes have been implemented in the mainline PX4 repository. I'd been building off the mainline repo, apologies if this has been answered before or is documented somewhere, is there a document that describes modal ai's release process so I can make sure im grabbing the latest iterations of code?

Hi Alex, I had and I still had the issue.

But once I built from https://github.com/modalai/px4-firmware/tree/voxl-fpv-dev and changed BAT1_SOURCE to power module (I originally had it set to ESC), when spinning the motors the current appeared correct and power draw updated correctly! Appreciate the help!

One interesting thing, with BAT1_SOURCE set to the ESC, when monitoring the battery_status mavlink message the current consumed and current battery values were invalid (both set to 0), I would've figured that mavlink message would still be valid irrespective of the source as its only coming from place?

Thanks

@Zachary-Lowell-0 Got it working. It seems we encountered a documented bug where the defaults were somehow getting incorrectly set to the wrong parameter for RC input protocol when we reset the board to firmware defaults. We were checking the COM_RC_IN_MODE but had always had the RC_IN set to Auto previously. This made everything look fine until it glitched and changed the parameter without us knowing.

In case anyone else runs into it, here is the bug: https://github.com/PX4/PX4-Autopilot/issues/22986

Appreciate the assistance on figuring this out Zachary, we can switch over to Flight Cores and VOXL Flights for this client now which they'll be happy about.

@Jetson-Nano It should be no different than with any other flight controller hardware running PX4. The PX4 documentation should be able to explain how to do that.

@TomP GPS on pins 2 and 3 is mapped to serial port 3 in ArduPilot. The RC port on pins 10 and 11 is mapped to 4. https://github.com/ArduPilot/ardupilot/blob/d977f318c68faf69b8afa9b5c1afe73932a1d946/libraries/AP_HAL_QURT/HAL_QURT_Class.cpp#L50

@TomP Oh, yes, this is all great news! Very exciting to hear! I will send an email to your account with some follow up questions.