Azure Sphere is a Microsoft platform enabling customers to build secured IoT products. For Azure Sphere-based products, Microsoft provides ongoing OS updates, enables device manufacturers to update their own app code, and provides certificate management. Being a platform, Azure Sphere is not directly used by end users, but by companies who build devices – often called “OEMs” (Original Equipment Manufacturers), or by enterprises who deploy those devices. Therefore, the “interface” for the Azure Sphere product is not an end user interface, but is docs, SDKs, software samples and hardware reference designs that enable our OEMs to build products.
In this blog post, we’re going to describe an end-to-end device built with Azure Sphere, showing how software, hardware, and physical design come together to create a real working device, which we then distributed to some end users. Our example device isn’t intended for sale, or even to be a formal reference design. It was intended as a demo device showcasing some of the key features of Azure Sphere through that device’s capabilities. We also deployed this device internally at Microsoft, which gave us insights into how end users experienced and interacted with Azure Sphere devices.
As part of the Azure Sphere team, we have a small team known as Devices & Demos, which includes software, electronics, and design expertise. This team maintains assets such as the design of the MT3620 Reference Development Board and other hardware reference designs. In addition, by designing, implementing, manufacturing, and deploying small runs of real devices, we enable the Azure Sphere team to experience and validate our OEM customers’ perspective as users of Azure Sphere.
For this particular demo, we wanted to build something:
- Enclosed and self-contained
- Battery powered
- Connected to a cloud IoT dashboard – built with Azure IoT Central
- Using a small, custom PCB (printed circuit board)
- With real-time requirements
- Engaging and fun!
We settled on a balancing two-wheeled robot. Balancing robots (and inverted pendulums) are canonical examples of hard real-time control - if the control loop is stopped from executing, or misses timing constraints, they fall over – hard.
Of course, if we’re going to build a cool demo, it wouldn’t be complete without lasers. So we added some range-finding lasers that enable the robot to avoid obstacles.
Robot design and behavior
Here’s a picture of the robot in action:
We included a small LCD screen to show the robot’s status. There are 4 icons, the top one being battery level, then WiFi connectivity status, then IoT Central connectivity status, and finally an indicator of the firmware version (version A or version B) that it is running that is used when demonstrating how the robot handles over-the-air software updates without falling over.
Inside, the robot looks like this:
As you can see, the 3 AA batteries are in the top compartment. The PCB forms the “spine” and includes an inertial measurement unit (IMU) for balancing, and the laser range-finders. The motors are housed at the bottom in line with the wheels. The whole thing is encased – we used 3D printing to quickly build some custom cases. To simplify the electronic design, we used the Avnet Azure Sphere MT3620 module.
The software architecture is illustrated in the diagram below. We made use of Azure RTOS on one of the MT3620’s M4F cores to perform the hard real-time loop of controlling the motors, using data from the IMU to stay upright, and data from the laser range-finders to detect and back away from obstacles. The “high level” A7 core app communicates with Azure IoT Central and with the real-time core to provide secured internet connectivity.
Connecting to the cloud
It wouldn’t be an IoT demo without showing how to view and control the data from the Internet. In Azure IoT Central, we implemented a dashboard showing the status of the robot:
This shows:
- The battery level of the robot over time
- The current heading of the robot in both degrees and as a compass direction
- The total number of obstacles that the robot has avoided using the laser rangefinder to detect and back away from an object
We also implemented a control feature in IoT Central:
This illustrates how IoT Central can set a “desired property” in the robot’s device twin, for the desired heading – the robot then turns on the spot to face in that direction.
Deferring updates while balancing
Being securely connected to the Internet requires a device to be regularly updated to stay on top of newly discovered security issues – this is one of the Seven Properties of Highly Secured Devices. However, to take a software update requires a device to be unresponsive while it installs – which is not a good idea if you’re balancing on two wheels. To address this, Azure Sphere supports deferral of device updates. For this robot, we use that feature and defer updates until the robot is safely lying down.
Video and source
All of the above features are illustrated in this video:
We have also made all the source files and docs for this robot available in the Azure Sphere Gallery github repository. This includes the software, electronics design, physical case design, plus assembly and end-user instructions. The Azure Sphere Gallery github repository includes unmaintained content that is not part of our official, maintained Azure Sphere platform. others might find useful as an example of a complete device implemented, manufactured and deployed on top of Azure Sphere.
Conclusion
Thank you for reading this blog post! I hope it has inspired you to think about what you could create with Azure Sphere. If you haven’t already, why not grab an Azure Sphere dev board and see how quick it is to build a secured IoT device, or have a look at the github repository to see how we did it ourselves.