@Scott_Nunan we get a high proportion of our testing for new releases done by users of this cheap hardware. That happens as people willing to test beta or latest releases tend to be ones willing to risk their vehicles, and that tends to be users who don’t invest as much money in those vehicles.
Henry and I are not proposing that we recommend these boards - we don’t know enough about them to know if they are any good or not. We should however understand them so we can more easily attribute issues discovered in testing to software or hardware issues.
2 Likes
Is there not money donated to ardupilot that is not from partners? I for one have donated and wouldn’t mind this by helping root out issues. So lets not just keep partners in mind as others do donate. This by no means is an endorsement to use these but will help limit issues that could arise for folks that still do use them. There are still people on here using APM 2.8. @tridge if you need more funds to cover let me know!
2 Likes
I’ve purchased some 8-10 pcs “Pixhawk 2.4.8” off Banggood and eBay over the past 6-7 years. IIRC, there has been an issue with the barometer / pressure sensor chip where the MS5607 has been used instead of the original (better and more expensive) MS5611. I could live with the lesser precision, but the real issue, is that the 5607 signal scaling is different by a factor of 2. You can identlfy the problem when looking at the value of “press_abs” in the “Status” tab. Instead of a value near 1013 (or whatever the current weather dictates), you’re getting 506 or so (again IIRC). Since the use of data is for a relative altitude, we may not pick it up, but since the conversion from pressure to altitude is not linear, a significant error can mount.
EDIT: I found my old post on it here: RC Groups - View Single Post - Ardupilot on Planes
1 Like
Hi mike_0
You should be able to use latest stable firmware and set BARO_OPTIONS,1 to pick up the changed barometer. That should solve the altitude issues. I believe you would use the “Pixhawk1” firmware.
3 Likes
To me it looks like there’s actually two kinda separate points here that are getting conflated:
1 - the idea that the funds shouldn’t be spent on things that don’t benefit partners. I agree with you that that’s really bad and that the funds should also benefit the general users, for the reasons you’ve mentioned.
2 - the idea that we shouldn’t spend funds to benefit clone manufacturers’ “race to the bottom” as James put it. This I strongly agree with.
So, instead of trying to improve support for clones, I think we should be directing users to FCs at a similar price point such as Matek’s ones and the Holybro Kakute ones. I know from my own experience when I got into this that it can feel like the Cube Oranges are the only option as they’re pushed so hard. Just making users more aware of the cheaper options that some of our partners and other reputable vendors have would make a huge difference.
As far as dealing with the support problems caused by the clones, if it’s possible to identify when the fmuv2 firmware is flashed onto a clone, perhaps we could add a GCS message warning about that which is printed out once on every boot? Thus the user can ignore it and keep using the board, but they would know they’re running on perhaps dodgy hardware and would be less likely to blame AP for issues. It also means that devs or anyone else looking at the logs would be able to know this too and check for symptoms of hardware issues. Of course, I don’t know how easy/hard it is for the firmware to figure out if it’s a clone… Detecting at least some of them should be possible though, given they’ve swapped IMUs or other components, right?
2 Likes
The thing is that reputable vendors, including some of our partners, actually sell FCs at a lower price than these clones. From a quick google search, the cheapest pixhawk clone I could find was AU$149. Holybro sells an F4 FC for about AU$48…
Completely agree with James. The no name bunch of chips inside a Pixhawk name is just a pain to set up.
Perhaps we should pursue, instead of the race to the bottom, implement a Tested/Works with kind of certification.
my 2c
In my opinion those kind of boards should be locked once they try to load AP. Dangerous for users and people around them. Let alone spending money on them.
So someone looking to implement a cheap, ride along data logger should be subject to the potential destruction of their purchase by moral-high-ground-seeking firmware devs? That’s a bit much…
5 Likes
we’re not going to drop support for these boards, and we certainly are not going to “lock” them, whatever that means.
Once the boards arrive we will know more what sensor changes have been made. I suspect the LSM303D has been replaced with another sensor based on some logs I’ve seen. I’ll also be interested to see what bootloader and firmware they ship with. It may shed some light on why such a high proportion of our user community install the fmuv2 firmware, which is meant to be for boards that have the 1M flash flaw in the F427. I’ll be quite surprised if these boards have a F427 chip revision with that flaw as ST stopped producing it a long time ago.
3 Likes
Have you checked the downloads in relation to the IP addresses? I can imagine that many downloads come from only a few IP address …
1 Like
@Target0815 there are a lot of duplicate IPs, but it is about the same proportion for each. With duplicates removed fmuv2 is still the most popular.
“Lock” means do not give them the possibility to load a firmware that could be malfunctioning. It could cause injuries or worse. I am sorry i do not have the skills in english you have, still my english is probably better than your second language 
IMHO we will never be able to cover all those clones. I got like 4 on my desk, all are pixhawk 1 but all are differents … (brought long time ago, so probably no sensors different). 1 got the 1M issue.
I suspect those are using refurbished chips
In general I don’t think we should put in lots of effort (beyond enabling existing drivers) to adding features/functionality to such boards where it has been lost due to a change by the manufacturer. However I do think we should warn users that the hardware is not performing as expected due to missing sensors.
At least we should give a pre-arm warning if we did not find the expected two IMUs. To fix/bypass the user could flash a different build with more drivers or disable the missing IMU with the mask.
2 Likes
FWIW I have a genuine pixhawk 2.4. I’ve opened this up and on the rear it says STM32F427 VIT 6 3.
QGC notes this as an FMUv2, while it does let you choose which revision you will go with, most likely people will choose fmuv2.
missionplanner either lets me choose whatever, or automatically selects FMUv2 (if an FMUv2 firmware is installed) when trying to update firmware. from what i understand these are fmuv3 boards. This might also be where some FMUv2 downloads are coming from, its why i had fmuv2 firmware on these boards that i now understand should have firmware for fmuv3s. There’s no indication from the GCS that the board is fmuv3, if anything fmuv2 is pushed.
I’ve bought a clone 2.4.8 from ebay some time ago, that apparently has also shipped with the rev3 f4 chip. I could look into it but i don’t know about the rest of the sensors as of now.
not sure if its useful in any capacity to what you guys are investigating, @hwurzburg and @tridge but its something I noticed.
I’ve got two of these open source 2.4.8 clones. With the support of Ardupilot, they fly just fine. If it had not been for the low cost Aliexpress, I would still be wobbling around with an old ( now unsupported ) APM 2.8.
3 Likes
@ohitstarik if the board is capable of running fmuv3 and you have 4.3.2 or later firmware installed then if you check the messages tab in MissionPlanner you should be seeing messages like this:
do you see those messages? We added them to try to encourage users to switch to fmuv3 but maybe they aren’t working for some reason
1 Like
Both of the “Pixhawk 2.4.8” boards have arrived. I’ve put some photos here:
First Board
This board ships with a single IMU, an MPU6000. They have replaced the 2nd IMU (normally a lsm303d/l3gd20 combination) with an IST8310 compass, so it still has a builtin compass. The barometer is a MS5611, not the MS5607 substitute that we’ve seen others get.
It comes installed with ArduCopter V3.6.12 (cb570c06) on top of NuttX.
The most interesting thing about this board is it comes with clear documentation stating that the user should install “fmuv3” firmware:
They also have links to a website, which also points users at fmuv3:
http://pix.rctoysky.com/
the website has some incorrect information as well, such as saying updating the bootloader is dangerous (I updated the bootloader on mine with no issue) and incorrect information about flight modes (I think the issue they are alluding to here is that flight modes don’t show if the FRAME_CLASS is not setup).
I think the rest of the website is largely copied from a very old version of our docs.
2nd Board
The 2nd board has the full set of sensors of the original Pixhawk1. The MS5611 is not a MS5607 substitute.
Interestingly, it comes installed with ArduCopter V3.6.7 (38b8af17) fmuv3 firmware, ChibiOS based. Note that for 3.6.7 we did have a dedicated “Pixhawk1” firmware which would work fine on this board but they chose to install fmuv3 (which also works fine).
This board doesn’t come with any instructions at all, just the basic cables.
Neither of these two boards help explain why we have so many downloads of “fmuv2” firmware. The first tells users to install fmuv3 and the 2nd comes pre-installed with fmuv3, so why do so many users end up on the feature reduced fmuv2 firmware?
When I use MissionPlanner to update the firmware I see this:
so the fmuv3 firmware is being correctly detected to match the currently installed firmware (this is with the 2nd board)
Both of the boards have recent STM32F427 MCUs which work fine with 2M of flash
2 Likes