We are curious as to what the cheap clone guys are really shipping as “Pixhawk 2.4.8” since fmvu2 firmware downloads dominate on the firmware server…what sensors are really being used…this project would entail buying a couple of the cheapest Pixhawk clones on aliexpress and seeing what they ship with, what sensors are actually being used now, what bootloader vintage they are, etc…perhaps we should be recommending fmuv3 for ArduPilot installs now?
I fear you may be simply taking a brief snapshot of what’s available at the time of purchase. I suspect (but cannot confirm) that these clone boards use whatever hardware is most readily available for some period and then change it up as supply changes.
depends what you mean by work. A log was posted for a “Pixhawk1” clone last week that showed only 1 IMU. I suspect the 2nd IMU was not the LSM303D expected for a Pixhawk1. So the board booted and would fly, but likely has an undetected 2nd IMU that would be detected if fmuv3 firmware was loaded.
that is the sort of thing that led Henry and I to think that getting some of these boards is a good idea
the fmuv3 firmware includes a wider range of IMU drivers in the build, as it does IMU detection instead of having a list of expected IMUs, so it is quite possible that loading fmuv3 will give more features for some of these boards, but we won’t really know till we try
2cents
It could also be that some of those cheap 2.4.8/clones are actually missing the part too, or it’s soldered so bad or positioned wrong so the part is not connected properly and non-funtional.
Some look like they have the parts but they just dont work.
I’ve seen all that in some of them.
I’ve seen where a 2.4.8 cheap clone was almost impossible to tune reasonably (not even close to being acceptable) and going back to the old 3DR Pixhawk1-1M made a world of difference.
Thankfully such a swap is a drop-in replacement.
You almost need a build that just enumerates all the components so you know whether to choose Pixhawk1 or FMU2 or 3
If its like the rip off memory cards the volume can be labelled to read an advertised memory capacity but physically its not all there so if you try to write files to the drive which fill it to more than about 10% you will be left with corrupt files without knowing. Then if you try to use this drive to do a FW update for example you brick the device you were updating. Awesome thanks china
This is a terrible, horrible, no good, very bad idea. Let’s not support this endless race to the bottom, but support users by guiding them to trusted vendors.
Yes, there are enough issues with getting open source systems working as it is without adding to the doubts in your mind by using questionable fake hardware that could be the reason for half your issues. Theres is no harm in learning what hardware shortcuts they have taken by tearing one down for research, but nobody should be encouraging this fake manufacture through purchasing the rubbish
oooo! loving that these things actually get looked at!
we apparently get quite a few people having issues with the fact that so many boards share the Pixhawk board id and get presented a long list of boards including the fmuv2/3, the Cubes, Pixhawk1 and 1-1M, etc. when trying to load firmware upgrades…which is what stimulated requests to make the wiki clearer…
also the fact that the largest number of firmware downloads, by far, are fmuv2,… apparently for clone Pixhawks…
but I intended to add to the wiki a photo of that dropdown box with all the firmware choices along with a a caution that loading ArduPilot on non-partner Pixhawk clones might result in operational issues…so we are definitely not promoting clones, just the opposite…but trying to reduce the number of support calls and bad “ArduPilot” experiences by understanding what the current shipments of floor sweepings are is worthwhile, I think
Or we could explicitly not support them and put the responsibility back on the manufacturer. I’m not going to spend money contributed by Partners to improve support for cloners and bad actors.
I agree with @james_pattison on this. I think partners should not support/pay for supporting the race to the bottom by other vendors who cut corners.
The risk of a crash running fmuv3 on rev1 silicon from 8+ years ago is dwindling to near zero. The risk of supporting fmuv2 may be starting to outweigh that risk. Perhaps a better solution is to sunset fmuv2. The silicon rev can be detected by the bootloader, right? Maybe we insert some update-bootloader/FW spam in there as a first step?
I’m with @MagicRuB and @james_pattison on this. Simply looking at this represents a kind of endorsement which I think is a bad precedent. I’m sure partners do not want us to spend their money on investigating.
you are arguing that team funds should only be spent on items that benefit partners. That is absolutely and fundamentally wrong. Team funds do not just come from partners, and the idea that team funds can only benefit partners is to me absolutely reprehensible and a complete abrogation of the funding commitees role to oversee the ArduPilot projects funds
it completely ignores that a huge number of the ArduPilot users, which are supposed to be the primary priority of the ArduPilot project, use boards like these. These users are both important in themselves, but also provide a very important set of testers for the project, which is one of the most fundamental resources the project has.
This decision makes me wonder if you 3 actually understand what the funding committee is for and why it exists. It is not supposed to be representative solely of the ArduPilot commercial partners, it is supposed to represent the interests of the whole project, including the wider user community.
I am extremely disappointed in this decision
One can certainly have different opinions … myself I tend more to that of @tridge.
But what I wondered if " since fmvu2 firmware downloads dominate on the firmware server" in Henry’s start post should be the only criterion and of course if the numbers are correct? A number of downloads doesn’t really say much, more important would be if these downloads all come from different IP addresses.
you can push to proper vendors all you like, and as good as the prosumer FCs are many of the casual users arent willing to put down $250 for a flight controller, $90 on a gps, etc etc when they can spend $50 on a clone & $25 on a gps. pixhawk 2.4.8 clones has flown a lot of projects in this community just fine.
I know what you’re saying @tridge, but how many valuable hours of support have been wasted trying to address supposed ardupilot issues that end users are having when the real cause is not a bug in code but a manufacturing shortcut made by crook faker manufacturers?
You have to start with known hardware thats why there’s a hardware standard specified.
If end users have wasted their money buying rubbish controllers it’s just going to add to the laundry list of issues they have getting a working fc and add to the frustration for them trying to use ardupilot and muddy the waters further in regard to which issues are code issues or hardware issues.
Using known hardware is in my opinion the single most important requirement for the success a new user of ardupilot
