All posts by bsiever
MOREnet 2019: More Micro:bit Magic: Wires & Wireless!
Programs Used in Workshop
Slides
Video of Slide Builds
Curated Micro:bit Links
Great microbit.org Resources
Misc.
- ScratchX (Micro:Bit extension!)
SIGCSE 2019 Micro:bit Magic Workshop
Feedback Form
Please complete the Feedback for for SIGCSE Organizers by following this link:
https://bit.ly/sigcse2019-workshops-friday
Programs Used in Workshop
Slides
- Full Size / All builds (Lower res/smaller file size)
- Notes Style / All builds (Lower res/smaller file size)
Curated Micro:bit Links
Offline App for Windows and macOS
Control
Citizen Science
IoT Applications
Great microbit.org Resources
Misc.
- ScratchX (Micro:Bit extension!)
Making Blocks
Micro:bit workshop for WashU’s Institute for School Partnership
Slides
Control App(s)
Citizen Science / Data Logging App
IoT Applications
Great microbit.org Resources
Misc.
- ScratchX (Micro:Bit extension!)
Making Blocks
Submit your resource summaries here.
CCSC:CP 2018 Workshop — An IoTa of IoT: micro:bit Magic and Photon Phun
Slides
Micro:bit
- Control
- Citizen Science
- IoT Applications
- Great microbit.org Resources
- Misc.
- ScratchX (Micro:Bit extension!)
- Making Blocks
Photon
- The “App”: page.zip.
- SIGCSE workshop materials
SIGCSE 2018 Micro:bit Magic Workshop
Slides
Control
Citizen Science
IoT Applications
Great microbit.org Resources
Misc.
- ScratchX (Micro:Bit extension!)
Making Blocks
Mini-Garage Project
Mini-Garage: An IoT Example
This project was created in an effort to create a real-world example project for my introductory IoT courses.
Features
The mini-garage provides nearly the same features as a real garage door opener:
- Motorized door mechanism
- Safety feedback
- Electric eye
- Physical interruption/stall detection
- Physical button to toggle door state
- A light
- Most importantly, it can be controlled by a Wi-Fi enabled platform, the Particle Photon.
Videos
The videos below shows the basic garage door control that developers (students) have to implement. They implement all control logic (direction of motor, when to start/stop, etc.). Some of the required behaviors include:
- When the button is pressed the door opens/closes and the light activates.
- The light turns off soon after the door motion is stopped.
- Faults can be caused by either the electric eye’s beam being broken when closing or if the door physically stalls. In either case the door should stop (or reverse) and the light should blink. The door should be able to be restarted by pressing the button again.
Follow-up assignments implement internet-based control of and feedback from the door. These include features that aren’t feasible on traditional garage door openers, such as notifications if the door has been left open.
Basic Opening Due to Button
Alternate Video Source
Detecting a Fault (Person in the Way)
Alternate Video Source
View of the Mechanical Parts Opening/Closing from Above
Alternate Video Source
View of the Mechanical Parts Opening/Closing from Side
Alternate Video Source
Pictures and Diagrams
Videos of the 3D Model
A Tour of the 3D Model
Alternate Video Source
An Overview of Constructing the 3D Model
Alternate Video Source
Why a Garage?
A garage was selected for a variety of reasons:
- Home automation aspects of IoT are appealing.
- Garage door openers are relatively familiar devices.
- The I/O is digital, so it doesn’t distract too much from other topics.
- Like many more significant IoT projects, developers need to learn how to work with proxies for the hardware due to safety/space considerations. Moreover, APIs serve as contracts for hardware interaction.
- The mechanical aspects and timing characteristics make for a richer project.
- The scale is appropriate. Over the course of a semester it’s possible to put together a nearly commercial quality solution.
I also had some personal goals:
- Learn CAD/CAM basics.
- Practice using laser cutters.
- Learn how to efficiently manufacture a small run of a product.
Implementation Issues and Choices
The intended purpose (classroom use), imposed some requirements on the mini-garages:
- They should be easy to build (I wanted to build ~6-7 of them)
- They should be cheap. (I wanted to build ~6-7 of them!)
- They should be reasonably reliable. They’ll be used for a few semesters and poor performance undermines the experience.
- They should be portable. Developers (i.e., students) will only have access while in the classroom and the garages will be carried from table-to-table.
- They should be electrically and mechanically robust. Errors in code should not damage either the developer’s test platform (the student’s processors) or the mini-garages. Moreover, errors like this should be reported, rather than just quietly prevented.
- Developers should be able to make their code interact with the hardware with minimal effort.
Given the requirements, I decided on something that’s approximately shoe-box size. A 1/24th scale was a good fit. The model is parameterized and many aspects of it will scale with a simple change to the scale parameter. The size of tabs on the box joints may need some adjustment and some elements, like the motors/gears/etc. are a set size and don’t scale. Consequently, modifications of scale often need some triage to get back to a working model and things go awry if the scale is significantly different than 1/24th.
I chose a two processor design to help protect hardware and to require compliance with an API. The students write code for a Particle Photon, which is then plugged into the garage hardware via a ZIF socket. It interacts with an Arduino Pro Micro, which does the real I/O. The only shared electrical connections from the Photon are power, ground, and RX/TX from a UART. This minimal interface helps avoid a wayward short-to-ground due to an accidentally misconfigured output. (RX/TX is relatively safe due to code review prior to using the hardware and because we don’t use that RX/TX for any other aspect of class. Circuits for other work only uses the DX and AX pins).
When developing and testing code without the garage, developers use stubs for the API. The stubs typically simulate the garage via LEDs and switches, which is sufficient for most testing. Some aspects of the assignments require meeting timing constraints, which requires code instrumentation as well.
The motors (steppers) were chosen partly due to size and, largely, due to price and availability. The choice of motors impacted both the technique for stall detection and the power requirements. Since it’s relatively difficult to detect stalls in steppers via changes in current, a mechanical rotary sensor on the front belt gear is used. If motion stops for a sufficiently long time it’s assumed that the door is stalled. This technique has some limitations if the mechanical strength of the motor/belt can damage the mini-garage prior to a stall being detected, but fortunately this doesn’t seem to be the case.
Typically the Arduino Pro Micro is connected via a USB cable to a PC, which monitors for errors. If the developer’s code attempts to overdrive hardware or misses timing constraints, it’s reported via a message. It was originally hoped that the USB cable could also satisfy all power requirements. Unfortunately the total current used by all components may exceed the current supplied by either of the Arduino Pro Micro’s on-board voltage regulators, which could lead to erratic performance. Rather than using a custom USB cable and additional power supply, I decided to just use an independent power supply for the motors (4AA batteries).
Files / Source
- 3D Model & Parts
- A360 link or GrabCAD
- GarageParts.zip (Laser Cutter Parts on two sheets; Individual files as .dxf, and 3D printer parts as .stl)
- GarageLaserParts.pdf (converted via Zamar.com; Unknown fidelity/scale)
- Wiring
- GarageSchematic.zip: Fritzing file of breadboard layout
- GarageBreadboardLayout.pdf
- Source Code
- GarageFirmware.zip: Firmware for the Arduino Pro and the API for the Photon
Bill of Materials
Average cost for a single garage: $40.83 (plus minor incidentals)
Misc. Construction Needs
- Hot Glue: For mounting laser sensor, stepper driver board, and attaching wires
- Wood Glue: For gluing cotton fabric panel to door slats for hinge
- Super glue (gel, quick dry): For mounting laser and gluing stop switched once positioned
- Sandpaper: Misc finishing, especially door tracks
- Silicon Spray: Reducing friction on door tracks
- 3D Filament: Traveller on rail
- Tooth picks: Misc. testing. These can be used for temporary pivots rather than screws.
- Solder: Soldering 🙂
Software
- Autodesk Fusion 360: 3D Model (Design check & parts via Laser Cutter & 3D Printing)
- Fritzing: Schematic Capture / Layout
- Simplify3D: 3D printing
- CorelDraw: To merge parts onto sheets for printing
Tools
- Soldering Iron / Station
- 3D Printer (Mine is an old, used XYZprinting da Vinci 1.0 AiO)
- ULS VLS 4.60 Laser Cutter (via the now defunct TechShop, Inc….Hopefully soon to be replaced by Maker Studios)
- Misc. standard tools (screwdrivers, sanders & sanding blocks, etc.)
Acknowledgements
Special thanks to Carly Lowe, who was a Dream Consultant at Tech Shop when I made these. Around 5pm one day I mentioned to Carly that I wanted to create a little model garage. There was a prototype building with sliding door assembled and waiting when I came in at 9am the next morning. She showed me the idea was feasible. Of course it took me about two months to recreate what she’d done as an evening project. (I wouldn’t have considered the windows/door/etching if I hadn’t seen Carly’s model. She also suggested the use of fabric for the door “hinge”)
PXT for the Micro:Bit locally on macOS
This is out-of-date. Just follow the instructions at https://github.com/Microsoft/pxt-microbit
I’ve been looking into the Micro:Bit and Microsoft’s PXT (Programmer eXperience Toolkit). PXT and all the required build tools can be installed on macOS, but the official instructions are a little weak. Here are the required steps:
Installation / Running
All these commands need to be run in a terminal:
- Install Homebrew
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
- Install Node.js (using homebrew)
brew install node
- Install Yotta
brew tap ARMmbed/homebrew-formulae
brew install python cmake ninja arm-none-eabi-gcc
pip install yotta
- Install srecord
brew install srecord
- Clone the pxt repo. (Replace the repo URL with the URL of a fork if desired)
git clone https://github.com/Microsoft/pxt-microbit
- Change your directory to be within the cloned repo. For the above:
cd pxt-microbit
- Install pxt
npm install -g pxt
npm install
- Run the local pxt server.
pxt serve
This will download the needed components, do compilation, and eventually launch the PXT environment in your default browser. Watch the terminal window though. Downloads may exceed github limits and it may require you to paste a URL to login in and complete downloads (something like https://yotta.mbed.com/?provider=github#login/...).
Adding a Library
- Stop the pxt server (if running)
- Create the sub directory in ROOT/libs. Ex:
cd pxt-microbit/libs
git clone https://github.com/Microsoft/pxt-bluetooth-temperature-sensor
mv pxt-bluetooth-temperature-sensor bluetooth-temperature-sensor
- Add the new directory to bluetooth-temperature-sensor in pxt-microbit/pxtarget.json
...
"bundleddirs": [
... ,
"libs/bluetooth-temperature-sensor"
],
...
- If needed, update the pxt.json of the new library. For example, for the above update the path of the dependencies:
...
"dependencies": {
"core": "file:../core",
"bluetooth": "file:../bluetooth"
...
- Restart the server to build it.
SIGCSE 2017 IoT Workshop
This year co-author Michael Rogers and I presented “An IoTa of IoT” at SIGCSE2017.
Tech on the Farm (FFA) Projects
I helped put together two simple projects that could be used in agriculture applications (monitoring livestock):