There's a lot of debate around the economic suitability of drones for the delivery of the goods as a direct competitor to traditional trucks and delivery vans. There's an article written by Flexport which highlights two crucial factors that makes drones delivery of general goods not feasible, even in the near future: (1) route density and (2) drop size. Route density is the number of drop-offs you can make on a delivery route and drop-size is the number of parcels per stop on that delivery route. Given the strict airspace regulations on drone size and weight, it has become quite evident, particularly in the African context, that the delivery of general goods will not be an economically viable option even though the obvious need might say otherwise.  However, further analysis and demonstration have shown, from companies like Matternet and others, that the transport of the time-sensitive and high-value parcels (legal-documents, medicine samples, high-value spices...

Over the course of the past 2-3 weeks I decided to take the plunge of learning a new training algorithm which had quite alot of attention in the academic community but was also well constructed for easier implementation. The work by Peng et al on developing the Continuous Forward Algorithm (CFA) was my subject of attention. The overall premise behind implementing this algorithm was to investigate less memory-intensive machine learning algorithm that will not sacrifice accuracy or robustness. The ability to have a real-time learning system for low-cost electronics (such as the Teensy 3.6 ) has huge implications for the commercialization and affordable access of intelligent drones specifically for developing and even under-developed economies. The far-reaching impact of having technology leveraging efforts of farmers, herders, game rangers, biologists is the next wave of industrialization. This is the essence of this blog. The journey is very exciting and eventual results even mo...

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...