Over the last few years, the engineers at the company have invested both their time and sleepless nights in formulating a process for the development of Machine learning algorithms that will satisfy real-time constraints with minimal RAM usage. This is quite a tall task as per default, that would force one to do their development directly in C language. Although that seems like the right choice, the downside is the direct correlation of the debugging time with algorithm complexity.  Such a time could have been rather used in optimizing the algorithm within the MATLAB environment which has excellent tools for the analysis, plotting and debugging. So it was decided to rather learn the Code generation process with the hope that future algorithm could be designed in a similar fashion without the hassle of the compiler-specific run-time issues. The development of this machine learning algorithm would eventually be implemented in a 32bit, 160Mhz speed, 260KB RAM microcontroll...

The objective for this milestone was to integrate the same model functionality developed and analyzed within the Matlab/Simulink environment into a mature environment that will be able to test most functionalities of the Flight controller software that will be flashed for real-flight testing. The decision was to either migrate the Ardupilot (in this case ArduCopter ) software into the Matlab environment or integrate the highly nonlinear quadcopter model with flapping dynamics into the Ardupilot environment. The former option would mean no easy integration with Mission Planner and the real-time sofware-in-the-loop ( SITL ) testing tool (which also includes the infrastructure to communicate with the Flightgear 3D visualization environemt, while the later with make use of singular environment although the software development effort would quite tedious and error-prone. It was chosen to go with the first option as this was thought to be lead to more mature verification method prior...

Don't get me wrong. I like Mathworks products, specifically MATLAB and the suite of control toolboxes. But for curse of being a super monopoly software is that, in order to make profit to drive software updates (which is now expected to be at least twice a year on most toolboxes), the focus is on the popular user requirements. This is often based on academia and research houses which often doesn't deal with hardware or firmware. In so doing, a large percentage of professional engineers productivity is directly coupled to the level of expertise of the analysis tool rather than the process upon which the product is based. Consequently, the poorer or bloated the tool, the slower can an engineer develop a product at lower cost. Unfortunately, the reliance on more powerful machines is the way to circumvent to problem. Just run the bloated simulation fast enough that's it's on longer noticeable to the designer. But is that engineering design? Is not the whole point to i...