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:
- Ensure your Pixhawk (or compatible) is loaded with a recent version of ardupilot (like APM:Copter-3.3.x)
- Connect with the Mission Planner
- Go to the Terminal screen and select "NSH" on the drop-down on the left, then push the little green connect button beside the drop-down
- type "ver all" and press Enter quickly into the terminal (the "Overtime in task 19" causes the MP some troubles)
- look for the "WARNING! Revision Y has a silicon errata".
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.
Replies
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.
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.
So why not use a distributed processing solution where there is a physical separation between the flight controller with its attached sensors (PXH derivative) and a higher performance processor such as the Pi or BBB? Both types of processing platforms (flight controller and "big brain") are at a good price and by NOT using a sensor board on the big brain you allow for rapid evolution (software and hardware) on the high end processor without needing to keep upgrading the flight controller software which could then become more stable and less complex.
The key to making this happen would be a reliable network link between the high end processor and the flight controller, perhaps CAN or USB. Oh well, maybe one day….
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?
Rob,
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?
Rob
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.
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!
L
I share this viewpoint too because everything around this community such as regulators, customers, governments are pushing for maximum safety and flight reliability. To get to the level of safety demands, my personal opinion is that we will need to separate and isolate the flight controlling part from the functional processing. This will allow to get a flight controlling layer that can be independant from the functional processing layer(s). And indeed we would be then free to use whatever small board computers for higher end processing without impacting the pure flight controlling layer; and thus without having to wait for a flight controller development-evolution every time the processing hardware changes/evolve.
After all if we look at how networking technology has become so easily accessible to everyone and everything, independently of any hardware or other techonologies, it is mainly due to the 7 OSI layers model where every layer is independant of the others with stable and standardized interfaces & protocols between layers.
Just an opinion.
Completely agree Hugues and Laserdev!
Divide and conquer!
Resilience through diversity is a key component of sustainability and survive-ability in nature, and you can't beat billions of years of natural evolution to find solutions, even in programming.
If possible I'd take the "networking" component to the next level where the layers don't even have to exist on the same silicon or vehicle. That would allow individual process layers to run on one vehicle or be split across vehicles or even the ground station etc. A type of mesh processing. That way one would have maximum flexibility with integrating swarming type vehicles to share sensor and processing results, and optimise vehicle navigation and placement to achieve the best, and fastest results for multi-perspective 3D (possibly realtime) terrain mapping. It also allows for potentially "disposably cheap" flying sensors, where each "smart sensor" pre-processes data for consumption by the hive.
From a hardware perspective I can see silicon like the iMX7 blurring the lines of what needs to be run where as the cost of processing goes from $100's to just $1s. So keeping the layers separate would seem to make even more sense with a potential onslaught of cheap and available processing coming through the pipelines in the next couple of years. That way one can choose the level of functionality ie just sensor data collection and transfer or onboard processing, as is required for the desired application.
Wow! Hardwired for the LAN and wireless for the WAN? This reduces wireless bandwidth. Three primary on-board nodes: flight, brain(s) and wireless router.
-
1
-
2
-
3
-
4
-
5
of 9 Next