This is a discussion for the 1MB flash limit issue so that we can consolidate any discussions and concerns about it in one place.
To give some background, all Pixhawk (and compatible) boards use STMicroelectronics's STM32F427 as their main CPU. This CPU is advertised as having 2MB of flash space (flash is where the ardupilot software is held) but we have discovered that early revisions of this CPU (RevA, RevY and Rev1) have a hardware problem and can actually only hold 1MB and if we use more than that they start exhibiting USB communication problems.
Now currently APM:Copter-3.4 is 0.9MB so it's under the limit but as we add new features it grows and if it grows above 1MB users will find they can't reliable connect the ground station to the board using a USB cable (wireless would still work) which could make it very difficult to configure the board, download logs, etc.
We think many boards (perhaps most boards) out there are the early revisions (A, Y or 1) which suffer from this problem. All the boards on my desk have this problem and you can check your board by following the instruction also shown in the video:
Some very recent boards do not suffer from this problem. For example all Solo's are fine as are the XRacer (aka PixRacer) boards.
Before panic ensues I'd like to say that although APM:Copter-3.3.2 is already 90% of this limit, remember we've just done a release and we will put effort into keeping the code size under 1MB. So for example, I can guarantee that APM:Copter-3.4 will fit and hopefully Copter-3.5 too.
Still, when you're shopping for your next Pixhawk you may consider asking the manufacturer if they are using the latest Rev3 STM32F427 processor.
I agree completely as well.
The higher level processors are general purpose devices, and this field is evolving very fast. Every 6 months, there's a new faster SBC coming out. If we want to use this on a UAV, it needs sensors, which invariably ends up meaning we have to wait for somebody to cut a brand new sensor board. Also, most of these will have no way of generating PWM signals. Nor will they have CAN transceivers. While we may get to the point of serial comms direct to ESC's on multirotors, we will need PWM for planes and helicopters to run the servos for a long time to come. And CANbus is a better physical layer than multiple Serial comms for all the other sensors which must be distributed (GPS, Mag, Power monitor, etc).
So every time somebody releases a new SBC, we have to wait for somebody to make a new daughterboard with sensors, PWM generation, CANbus transceiver, etc. Makes no sense at all. Especially when you consider how quickly that market moves. Older SBC's are obsoleted almost immediately after the new version comes out. This will create a constant churn of daughterboards having to be designed, debugged, sold, then discontinued.
Also, with every revision of this hardware, new mounting schemed have to be developed, with perfect vibration isolation (not too hard, not too soft).
Or... or... we just keep using a stable system like a Pixhawk-class device. Establish comms system to whatever SBC you want to use. And we're done. No need to rewire the aircraft to simply change the SBC. The flight control is stable, widely used (less debugging). The vibration isolation can be perfected. The SBC can then be installed on very soft isolators if desired, it won't matter to the gyros/accels.
The flight controller already has everything we would need on a daughterboard. And is no bigger than a daughterboard that would be added to an SBC.
IMO, the ONLY justification for the concept of integrated systems, is on very small quadcopters with integrated cameras, etc. But even then, the STM32 is such a small chip anyway, and is useful at least for it's ability to generate PWM... why not just integrate it directly on the SBC which will be custom designed for the quadcopter?
I would note that in general, the trend toward higher levels of integration in complex systems (not just avionics systems) is driven by the fact that the single most common point of failure in more distributed systems is the interboard/sensors communications interfaces themselves, both the hardware (cables, connectors, etc.) and the complexity of underlying supporting firmware and protocols that can have "interesting" lockup and other failure modes. Connectors in particular are a nightmare in flight systems that must deal with vibrations, and where a failure can drop a heavy object out of the sky onto vulnerable objects.
While it's true that new SBCs appear nearly every day, it's not so clear that they necessarily bring much of value to the table in our context except at much longer intervals where there are significant changes that bring genuine performance or reliability aspects to the table, when used with the application software at hand. Short of that, their main "benefit" is to take up developers' time as they try to learn the idiosyncrasies of new hardware and work to get their existing codebases running effectively on them, and dealing with the bugs that not infrequently appear in early (or even not so early!) steppings of new CPUs -- sometimes only discovered years after introduction.
Which of course is what started this particular thread in the first place!
My sentiments exactly. Why not make it even easier and use a iMX7 (or even iMX6solo) that have a ARM M4 processor (same as is used in the STM on the PXH) that can run Nuttx/APM, and also includes a dual A9 core CPU for running Linux as well, all in the same IC package? You don't need a SBC at all, or if you do you can opt for a Jetson X1 for really high performance instead, without needing to burden it with the relatively mundane tasks of networking etc.
Take the $49 Udoo Neo that runs the IMX6 version of that chip for example. Even has wifi and 9axis gyro/accc/mag onboard. Beauty is that both processors can access the peripherals, with a high peed inter core bus etc eliminating even more PCB/electronics used for interfacing, all at a low price point. You can then run both APM in RTOS on it's M4 core and Linux APM on the CPU core at the same time using the same sensors. Who wants to help port APM to that? ;-)
The other alternative is to use a $55 snickerdoodle FPGA board. With that we could have SDR radio included for under $100 as well as the above. Let alone run the APM stack in FPGA...porting it is an issue, but at least the tool chains are free now. You can even run up to 4x HD cameras with this for OpenCV.
My point is that the hardware processing power cost is so LOW it's nearly fool hardy not to have some $5 CPU integrated running Linux ,even if it is only used to maintain networking or camera inter-connectivity. Configuration and mission planning could be as simple as running a webpage on a server on the aircraft.
The super low cost of processing now means that "everything" can afford to have linux embedded as well as RTOS on a ARM M. My view is there is simply no reason to not have a Linux CPU onboard.
FYI, I've just received a bunch of new Pixhawks from 3DR and they're RevC (i.e. 2MB limit which is good) so I think this means that at least any very recent Pixhawks from 3DR are good.
Just verified three Pixhawk kits purchased from uav store (germany) and they are all good (rev C). UAV store had purchased them from 3DR a few days/weeks before.
what is your opinion about Qualcomm`s Snapdragon Flight product? Did you see it yet? Its 801 CPU is quite a good one, in my opinion, and should be faster than one pixhawk currently uses.
Or is this Snapdragon Flight for now nothing more than a red herring?
Does the pixhawk not have 2 MB Flash? Was that just false advertising?
I just went out and bought a new 300$ pixhawk after APM was no longer supported and now your telling me this?
What is 3DR going to do? Are they going to replace these faulty boards?
2MB flash right on the page: http://copter.ardupilot.com/wiki/common-pixhawk-overview/
You can probably get one in RMA if you ask nicely.
Yes, there is 2MB of flash in all of these, and the developers have already made it clear that there shouldn't be any significant problems in normal usage with the units that have certain limitations in accessing the top 1M under certain specific conditions. They're going to be supported. Really, don't worry about it.
It's perhaps fair to view 3DR (and other manufacturers) as a victim like everyone else. ST Micro is the one that made the original error and didn't recall the chips so there are still huge quantities of them floating around on the market.
I'd say the manufacturers are only behaving badly if they know about the problem but don't tell anyone and continue to sell boards with the earlier rev chips.
Would it be possible for someone with the required soldering ability to swap out the chip for a later revision or do the chips need to be pre-programmed in some way.
It's at least theoretically possible. We'd need to burn the bootloader onto the chip but that's done after the chip is soldered to the board using the square group of 8 or 10pins that can be seen on the top of the board (I think, I've never personally done it). The bootloader is open source as well of course and we've got it somewhere in the ardupilot repo I think.