DIY: 3D-printing a quadrocopter (or hardware for IoT)

3D-printed quadrocopter/drone

Over the weekend I had the opportunity to get deeper into 3D printing. I got invited to Maker World 2015 in Friedrichshafen and to a workshop run by the guys of Construction Zone. The goal was to get an overview of 3D printing by designing parts for a small quadrocopter, printing them, and eventually assembling printed parts and electronic components to a flight-ready drone. Creating the casing for Internet-of-Thing (IoT) devices basically is the same.

The mini drone and its parts can be seen on the picture above. It has a printed body, a printed cover, a small board (in the middle of the drone), a battery pack, and 4 motors. The first step in getting the copter up into the air was to design the body and cover as seen on the picture below. Some attention needs to be applied to keeping the rotors in a safe distance to each other and to have space within the body to house the battery pack and the controller board.

Design process for a DIY quadrocopter

Once the design is complete, the next step is to create a STL file and/or G-code for the 3D printer. During that process the printing quality is specified. It is based, among others, on the number and thickness of printing layers. And that directly impacts the time needed for printing. What I learned is that patience is a virtue...

DB2 pureScale for the Masses

DB2 pureScale Cluster (nanoCluster)

It is almost four years since I wrote about my exciting tests with a DB2 pureScale demo cluster (see picture). At that time the pureScale feature was still fairly new and was supported on a limited choice of hardware/software. Since then the requirements to put DB2 pureScale into production have been reduced dramatically and at the same time many useful features have been added. Let me give a quick overview of why customers choose DB2 with pureScale for both scaling out systems as well as a consolidation platform. Today, DB2 pureScale really is something for the masses...

The following is an unsorted and incomplete list of features and good-to-know items that come to mind when talking about DB2 pureScale:

• License: One of my favorite pages in the DB2 Knowledge Center is the "Functionality in DB2 product editions and DB2 offerings". It shows that pureScale is part of or can be purchased as add-on (Business Application Continuity/BAC Offering) for almost all DB2 editions.
• Application Transparency: How about writing a pureScale-enabled application without knowing about it? There are no special needs to be considered when writing an application to be run on a pureScale cluster.
• Cluster Size and Scale-Out: You can start small and increase the cluster size, even online, depending on your needs.
• Availability: DB2 supports continuous availability of the pureScale cluster by its system design and by features like rolling fixpack updates. Depending on requirements the cluster can span data centers and it is then called Geographically Dispersed pureScale Cluster (GDPC or "stretch cluster"). Basically, if one data center becomes unavailable, DB2 databases continue to be available and are managed from the hardware in the second data center.
  Two pureScale clusters can be linked by, e.g., the built-in HADR feature where transaction logs are shipped to and applied to the standby-cluster, increasing availability even further.
  For increased availability network adapters on each machine and network switches can be redundant.
• Hardware/OS: DB2 runs on the POWER and Intel platform on AIX, Red Hat, and SuSE operatings. Infiniband adapters can be used for highest network performance, but even the GDPC/stretch cluster version of DB2 pureScale only requires a regular TCP/IP network ("vanilla ethernet"). If you don't want to run pureScale on dedicated hardware, no problem, virtual machines (VMware and KVM) and even VM mobilitity are supported, too.
• Smart Workload Management and Processing: Depending on requirements and available resources, applications or specific workloads can be tied to a single node or to a group of computers in the pureScale cluster. This is great for consolidation. Workload balancing distributes the load among the nodes within a group. Over the past years several performance enhancements have also been added to DB2 that cater to consolidation scenarios.

All of the above boils down to cost savings and higher flexibility, an important driver behind opting for pureScale. Having said that I need to mention that earlier this week I decided against pureScale. I gave a nanoCluster, the same type as pictured above, away to make some room in my home office.

BTW: I have been asked whether a DB2 pureScale cluster can brew a good coffee. What would be your answer...?