All posts by bsiever

Micro:bit workshop for WashU’s Institute for School Partnership

Slides

  • Full (with notes)
  • Notes / Three per page
  • Video (no audio/narration, just slide builds)

Control App(s)

Citizen Science / Data Logging App

IoT Applications

Great microbit.org Resources

Misc.

Making Blocks

Submit your resource summaries here.

CCSC:CP 2018 Workshop — An IoTa of IoT: micro:bit Magic and Photon Phun

Slides

Micro:bit

Photon

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

Mechanical Diagram (top down)
Electric Eye (looking in from door)
Stepper and Back Contact (Fully open contact). Photo looking up from garage floor.
Front Contact (fully closed), Rotary Encoder (stall detect) and Traveller. Photo taken looking up from garage floor.
Control Board without a Photon Installed (Battery pack underneath)
Control Board with a Photon Installed
The Six Garages used by Students next to a Deck of Tiles IoT Cards for scale (playing cards)

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

GitHub Repo

Bill of Materials

Item Link Notes Cost (USD) Items per Purchase Items needed per Build Average cost per build
MDF Home Depot: 2’x2′ MDF Sheets 3.72 1 1 3.72
Timing Belt Gear Amazon: BEMONOC 2GT Timing Pulley 20 Teeth 6mm Bore fit GT2 Belt Width 6mm Used for rotation sensor 21.88 5 1 4.376
Timing Belt Kit Amazon: Drillpro 8Pcs 5mm 20Teeth Timing Pulley Wheel+GT2 5 Meters Belt, pully (for motor) 15.54 8 1 1.9425
Timing Belt Clamp Amazon: Mercurry 5pcs 2GT Timing Belt Aluminum Gear Clamp Mount Block 9.99 5 1 1.998
Canvas Panel Used as door hinge (glued with wood glue) ~$7 15 1 0.46
Perf Board Amazon: Gikfun Solder-able Breadboard Gold Plated Finish Proto Board 12.88 5 1 2.576
Rotary Encoder Amazon: Podoy 6Pcs Rotary Encoder Switch 6mm 18 Detent Points Used to detect door stalls / prevent crushing (easier than current detection w/ stepper) 8.39 6 1 1.398333333
Laser Amazon: GeeBat 10pcs Mini Laser Dot Diode Module Safety beam / sensor 5.99 10 1 0.599
Laser Reciever Amazon: Icstation 5V Laser Recevier Sensor Module Safety beam detection 12.99 5 1 2.598
Contact Switches Amazon: Gikfun Micro Switch Long Hinge Lever Detect when door is at extremes of travel 7.98 20 2 0.798
Stepper Motor Amazon: Elegoo 5 sets 28BYJ-48 ULN2003 5V Stepper Motor + ULN2003 Driver Board Door opener 13.99 5 1 2.798
ZIF Sockets ebay: US Stock 2x 24 Pin 2.54mm ZIF ZIP IC Test DIP Board Socket Universal 3M 224-6182 7.19 2 1 3.595
Arduino Pro Micro Amazon: KOOKYE 3PCS Pro Micro ATmega32U4 5V/16MHz 19.99 3 1 6.663333333
26 Gauge wire Amazon: 26 AWG Flexible Silicone Wire Electric wire Narrower wire would be better. (28 maybe?) 16.39 5 1 3.278
LED Amazon: Chanzon 100 pcs 5mm White LED Diode Lights (Clear Round Transparent DC 3V 20mA) Not the exact parts I used.  Overhead light. 6.67 100 1 0.0667
M2 Screws (Door connector hinges) Amazon: M2x25mm Stainless Steel Phillips Flat Countersunk Head Screws 50pcs Connect door to door hinge; Door hinge to traveller 4.99 50 2 0.1996
M2 Screws Amazon: 50 Pcs M2x14mm Stainless Steel Round Head Phillips Machine Screws Connect stop switches to guide 6.8 50 4 0.544
12 pin Header socket Amazon: 0pcs 2.54mm Single Row Female Pitch Header Socket  PCB Sockets for Arduino 1.74 10 2 0.348
M4 Screws / 16mm Amazon: Class 4.8 Steel Machine Screw, Zinc Plated Finish, Pan Head, Phillips Drive, Meets DIN 7985, 16mm Length, M4-0.7 Metric Coarse Threads 2 for motor to mount 7.37 25 2 0.5896
M4 Nuts Amazon: 20pcs M4 Thread 304 Stainless Steel Hex Hexagonal Nuts 2 for motor to mount 6 20 2 0.6
M2 Nuts Amazon: 70 Pcs Silver Tone Metal M2 Hex Screw Nut 6; 4 for switches, 3 for hinges 6.24 70 6 0.5348571429
Ribbon Cable Amazon: 30CM M/F Breadboard Jumper Wires Kit,80 Pin Male to Female Ribbon Cables For motor board to Arduino; Bundle of 6 wires per board 6.99 6 1 1.165

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

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”)

Carly’s Garage

PXT for the Micro:Bit locally on macOS

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:

  1. Install Homebrew


    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

  2. Install Node.js (using homebrew)


    brew install node

  3. Install Yotta


    brew tap ARMmbed/homebrew-formulae
    brew install python cmake ninja arm-none-eabi-gcc
    pip install yotta

  4. Install srecord


    brew install srecord

  5. Clone the pxt repo. (Replace the repo URL with the URL of a fork if desired)


    git clone https://github.com/Microsoft/pxt-microbit

  6. Change your directory to be within the cloned repo. For the above:


    cd pxt-microbit

  7. Install pxt


    npm install -g pxt
    npm install

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

  1. Stop the pxt server (if running)
  2. 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

  3. Add the new directory to bluetooth-temperature-sensor in pxt-microbit/pxtarget.json


    ...
    "bundleddirs": [
    ... ,
    "libs/bluetooth-temperature-sensor"
    ],
    ...

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

  5. Restart the server to build it.

SIGCSE 2016 IoT Workshop

Thanks for participating in our Workshop. Feel free to contact us at any time either via e-mail or connect with us on LinkedIn:

Bill Siever Michael Rogers
bsiever@gmail.com mprogers@mac.com
View Bill Siever's profile on LinkedIn View Bill Siever's profile on LinkedIn

Please download these files:

  1. SIGCSE.zip: SIGCSE Simblee Examples Library
    (GitHub Repository)
  2. Simblee-PulseSensorAmped.zip: Simblee Pulse Sensor Library
    (GitHub Repository)
  3. SimbleeForMobile-BarGraph.zip: Simblee Bar Graph Library
    (GitHub Repository)
  4. SIGCSE_IoT_Exercises.pdf: Guide to the exercises

Please help SIGCSE evaluate workshops by completing this survey at the end of our session:

https://www.surveymonkey.com/r/WFNRGJY

Experiments with JavaScript in Swift Playgrounds

In preparation for the SIGCSE 2015 I put together a demo showing ways to leverage Swift’s Playgrounds for a more immersive learning experience. They are:

01_WelcomeToThePlayground.playground.zip

02_While.playground.zip

The first example is an introduction to Swift Playgrounds. It gives a quick overview of the element of the Playground environment itself (the Results Sidebar, Assistant Editor, etc.). It concludes with some JavaScript multiple-choice self-test questions.

The second example introduces while-loops and the Assistant Editor. It also contains a “code building” component that uses a “Parsons problem” from Runestone Interactive. The Parson’s Problems are a powerful way to guide learners to proper logic and syntax. Rather than create code from scratch, it’s just a matter of dragging/dropping code in the correct order, as seen here:
ParsonsProblem
In the full while-loop playground example the learner should also type in the actual code and evaluate it in the playground.

Credits

  • Both examples were built with Jason Sandmeyer’s Playground builder (https://github.com/jas/playground).
  • The quizzes and Parsons problem use JavaScript and CSS from

Including interactive JavaScript in Playgrounds could be a great tool for improving their impact, but it requires some effort to set it up.

Logging events with on Nordic’s nRF series via Seger’s J-Link Real-Time Terminal

One of the most most common debugging techniques is “logging”, or creating a history of what happens while code runs.  Logging can be especially difficult in embedded systems, which often lack a natural way to log events, like a console.  Commonly UARTs are used to log messages via a serial port, but this approach can consume significant run-time that may undermine the timing constraints of the software. It also requires the use of additional pins to support development.

I’ve found it especially difficult to debug applications using Nordic’s Bluetooth Low Energy products (nRF family).  Fortunately, due to some helpful hints by fellow Nordic developers (Thanks Jeremy) and great products from Segger, I’ve got a solution that suits my needs fairly well. Segger’s Real-Time Terminal is a perfect solution to the problem. I’ve taken the example’s provided by Segger and made a package from them (easier to configure on multiple projects). I’ve also added some wrapper functions that provide additional data I find helpful when debugging.

The following explains how to setup a logger for the nRF series of chips, but assumes that:

  1. You are using a Segger J-Link (I’m using the J-Link CortexM)
  2. You are using Keil MDK v5 or later,which uses Software Packs.

This guide is broken into three distinct phases:

  1. Installing the Logging Package and updating the Keil’s IDE to easily connect to Segger’s Log Viewer
  2. Configuring a project to use the Logging functions
  3. A quick demo of actual use

 

Installing the Logging Package and updating the Keil

These steps should only need to be performed once.

    1. Install the latest version of Segger’s J-Link: https://www.segger.com/jlink-software.html?step=1&file=JLink_496a.

 

  1. Install the Software Package I created for Logging
    1. Download Siever.Segger_RTT_Logger.1.0.1.pack. (It works with any system that Segger’s RTT supports, not just Nordic)
    2. Double click on the package. It should automatically install via Keil’s Package Installer.
  2. Update Keil’s Tools menu to allow easy access to the Log Viewer (which is the window you will use to view log messages).
    1. Open Keil.
    2. Select Tools → Customize Tools Menu... from the menu:

      1_AddCustomEntry
    3. Add a new entry for the Log Viewer. When done it should look something like:
      2_LogViewerEntryDetails

      There are a few things to notice here:

      • I typed Log Viewer in the first available slot. This will be the name of the new item on the Tools menu.
      • The Command is the JLinkRTTViewer.exe. Verify that the path is correct for your installation.
      • Note that Run Independent is checked.

    The Tools menu should now have a new item that will be used to launcher the Log Viewer.


Configuring a project to use the Logging functions

You will need to do this for each project on which you want to use these logging functions.

    1. Open the Project
    2. Select the Logger Package for inclusion in the project. Select Project → Manage → Select Software Packs...:

      1_AddPack
    3. Select the newly added Logger Package and set the version to fixed:

      2_SelectPackToAdd_1.0.1

 

  1. Add the Pack to the Run-Time Environment. Select Project → Manage → Run-Time Environment...:

    3_AddPackToRunTime
  2. Ensure that the package will be included at Run-Time. Expand it and make sure it is selected:

    4_ExpandLoggerPackAndSelect_1.0.1
  3. The package will need to be enabled via a define. Add the define to the project’s Preprocessor Symbols.
    1. Select Project → Options For Target...:

      OptionsForTarget
    2. Navigate to the C/C++ tab and add RTT_LOG_ENABLED to the Defines:

      AddDefine

Demo of Use

In order to use the logging functions you will need to add calls to the logging functions to your code. You can use primitive functions provided by Segger, but I choose to use my own wrappers. In order to use my wrappers you will need to include the header file:


6_AddIncludeWhereNeeded

and insert calls into your code. I’ve provided three functions that each have printf semantics (and each call Segger’s SEGGER_RTT_vprintf()). My functions are:

loge(…)
Used for logging run-time errors (shown in red)
logw(…)
Used for logging warnings (shown in yellow)
logi(…)
Used for logging general information (shown in white)

Here are some examples in code:


7_AddLogMessages
I generally start a debugging session and then launch the Log Viewer via the item added to the Tools menu:


3_UpdatesMenu Launching

The Log Viewer you will ask how it should connect to a debugger session. When being run with an existing debugging session just indicate it should connect to the debugging session:


4_LaunchSettings

Here’s an example of the log generated by the three examples shown above:


RunAndDebug

Notice that:

  • The different warning styles are color coded.
  • The log macros I’ve created insert the file name and line number. This does consume additional flash memory, so don’t get too carried away with log messages.
  • Currently I have all log messages going to the tab for Terminal 0. It would be easy to update the approach to include different messages to different terminal tabs for different modules.

Disclaimers

This work is provided as-is with no warranty or guarantee of any sort. I’m new to Segger’s RTT and haven’t done any review of performance issues. I’m also new to CMSIS Packages and haven’t verified that I’ve followed all appropriate package conventions. At this point this is an alpha version, but any input or suggestions are welcome. The log macros were made for my needs when I developed them and may not suite other’s needs. The formatting used for them could certainly be improved.

Credits

The package includes unmodified code provided by Segger at: http://download.segger.com/J-Link/RTT/RTT_Implementation_141217.zip. Code by Segger includes a copyright notice, but they have given me permission to share the package.