Orange V5 Pixhawk clone (fmuv3) - INS: unable to initialise driver - possible fake/mismatched IMU?

Hardware Pixhawk family
1

Hi all,

We’re a student team using an “Orange V5” Pixhawk clone, flashed to the fmuv3 target.

We’re getting a constant, unrecovering error since first boot:

Config Error: INS: unable to initialise driver
Config Error: fix problem then reboot

This repeats every ~5 seconds indefinitely, right from the first boot log line, no other sensors involved.

What we’ve tried (no change in any case):

  • ArduRover 4.6.3 and 4.2.3

  • Board type set to both “Cube/Pixhawk2” and “Pixhawk1”

  • Different USB cables and ports

  • Full reflash / chip erase + reflash

  • Confirmed no SITL or UDP autoconnect interference (dmesg shows no USB disconnects during the error)

The board is correctly detected at the bootloader level (correct serial, correct flash size, fmuv3 identified), but the INS driver never initializes.

I just found this recent thread about a DakeFpv clone with the exact same symptom, which turned out to be a fake/mismatched IMU chip not matching the hwdef.

Is there a way to confirm which IMU chip our board actually has (without desoldering), or a recommended diagnostic to distinguish “wrong IMU chip” from “genuinely dead IMU”? Any help appreciated — we’re on a competition deadline.

2

Never heard of this. What’s it look like? Where did you buy it from?

3

You could try opening the case and reading the text on top of ICs.

4

I’m really curious to know what an “Orange V5 Pixhawk clone” is that is supposed to use fmuv3 firmware. I don’t recall seeing anything like like even on Aliexpress where all kinds of junk can be found. There are Orange Cubes, there are V5 Cubes, there are Pixhawk “clones”.

Of course.

5

We bought it from a Turkish retailer called F1 Depo, listed as an “Orange V5 Pixhawk clone” for fmuv3. Here’s the product link: https://www.f1depo.com/urun/orjinal-v5-orange-pixhawk-ucus-kontrol-karti

We contacted the seller and they confirmed this is a known issue with this board. They’re going to help us resolve it on Monday, so we’re waiting until then.

6

Yes, they confirm that right on the webpage :rofl:

"Pixhawk V5 is fully compatible with the latest official APM firmware as well as PX4 customized firmware. Users need to select the fmuv3 version of the file when programming.

Good luck with that. From the boards available on that website I would have chosen the Matek F405-WTE*. And while I would never suggest anything form Radiolink the Pix6 has proven to be OK and unlike other Radiolink product is supported by Ardupilot.

*Well, this is probably a clone also being discontinued from Matek.

8

Open the case and make a list of the sensors you see and match it to exisiting fmu/pixhawk/cube firmwares. If no match is found, maybe you could try a custom hwdef?

Look at this line on the website @dkemxr @Aysenur_Bayramoglu :
Since the sensor is customized, users need to flash the corresponding sensor parameters after programming to identify the software

Basically, its a generic board so there’s no guarantee if the sensors on it - as far as I understand.

9

Yea, I saw that. If Fmuv3 or Pixhawl1 don’t work it’s an unsupported board. And what’s up with this V5 nonsense? There is an actual FMUv5 standard that the old HolyBro Pixhawk4 was built to. But this Orange thing is not that. Or, maybe it is but they don’t know it if they are suggesting FMUv3.

10

Yeah, fair enough. Switching boards isn’t really an option right now, we’re too close to the deadline. Seller confirmed it’s a known issue and said they’d send the correct sensor params on Monday, so just waiting on that for now. Will update here once we know more.