Talk:Maker Space Manager System

LabSwipe /MSM System Development History & Future Road Map

Future Enhancements

Road Map for future enhancements.

Integration with ELMS/Canvas Learning Management System

Currently Labswipe stores training accomplishments in a Google Sheet. This needs to be manually updated. A brief look at the sheet shows very few of our makerspaces are making these manual updates.

Sandbox implemented makerspace training in ELMS/Canvas in 2019. Initially we were manually updating the Labswipe sheet from Canvas but this became very time consuming. We wrote a Canvas API query tool that re-formats the Canvas results to make the updates a bit easier. We considered automating the Labswipe sheet update process but discontinued our efforts on this when it was decided to move the Labswipe back end from google sheets to AWS.

Adding a badging or micro-credentialing plugin to Canvas was attempted in 2019-2020. Sandbox hoped that by adding this capability to Canvas we could avoid concerns about running queries directly against the Canvas system (which contains protected information about students) While the primary benefit would be isolating us from FERPA concerns, the badging system Would also simplify our queries (especially for training completed at a different makerspace), allow us to track training not done in Canvas (such as Welding or other training requiring direct, hands-on instruction), and also provide additional ways to gamify training (for example by allowing training tiers, 'leveling up', etc.) Our request to add a badging plugin to Canvas was rejected by DIT. We understand that a request to add a different badging system has been made by a different department and is still under consideration.

We'd like future versions of Labswipe to have the capability to update training accomplishments from Canvas. Ideally this update would happen every time a maker swiped in to the system.

Move tool-to-use selection further downstream from sign-in

Currently, the MSM system asks each maker which tools they will be using when they first swipe in at the front door. We've found this results in distorted statistics as many users just select the first tool they see on the list, etc. .......

An improvement would be to simplify the swipe-in process so no questions are asked and move the tool selection process closer to each tool, for example by having a swipe terminal at the door to (or inside of) each of our workshop studios or by having a tool lockout device that also tracks tool usage.

Tool Lock-Out

We'd like the system to provide tool lock-out capability for certain tools that are deemed to be dangerous (such as a CNC router, milling machine, band saw, etc.) or tools that while not particularly dangerous require specific knowledge to operate correctly (such as laser cutter, SLA 3D printer, etc).

• This lock-out capability would require each maker to swipe their ID (or other authentication mechanism such as NFC, RFID, etc) before using that tool.

• The system would look up the makers ID in a central database, and if able to verify that the maker is trained and certified to use the tool would grant access.

• The granting of access would enable the tool either by applying power, enabling a logical signal read by that tool's controller, by deactivating the tool's e-stop circuit, opening a cabinet interlock, or other mechanism. Several differnt approaches may be required to adapt the system to a variety of tools and their control systems.

• The system should provide some way to prevent the maker from walking away and leaving the tool in an operational state. Some research and discussion are needed to determine the best approach.

• For tools enabled by simply applying power, the system should prevent these tools from starting up immediately on authentication to prevent unsafe situations.

Tool Check-Out / Check-In (for use in makerspace)

Since demand for access to tools varies, it would be helpful for the system to manage access to popular tools by requiring the maker to check-out a tool for a fixed period of time. When a different maker wishes to use the tool, they would see that the tool was currently in use by another maker and would also see the time the tool is expected to be checked back in.

The Check-Out feature would verify the maker has completed any necessary training.

If a tool is still being used by that maker after the check-in time has passed, the new maker would have the right to be the next to use the tool.

The new maker would be given priority as the next user of the tool (see reservation below)

Ideally, the system would send an SMS message or some other sort of notification that the maker's use time has expired.

Should the system shut down tools after use time expires? Or just warn that time has expired? (assuming the tool is lock-out enabled)

Should the system allow a maker to extend their use of the tool if no one else is waiting to use the tool?

The Check-Out / Check-In feature could also be used for tooling, bits, and tool accessories. This provides an opportunity to check these items for damage before and after each use.

(Note: Check-Out / Check-In may not be the best name for this feature if the name implies checking the tool out and leaving the space.)

Tool Reservation

Several tools (such as laser cutters or 3D printers are popular and makers often wish to sign-up in advance for a window of time to use the tool. In the case of 3D printers, a print job could run for many hours, or even multiple days. It would be useful for MSM to allow makers to reserve time on a tool and allow other makers to see that the tool is reserved and unavailable until a given time.

Reservations block-out for class times or maintenance windows.

Manager / Staff skills matching

Provide a new capability in MSM to allow staff and volunteer managers to swipe in and out while indicating if they are working or just using the space as a maker.

The system should provide a display of all on-duty managers and staff, displaying each manager's photo and list of each's skills / specialties. This to help makers using the space know who to best ask questions about a particular tool or technique.

Resale of maker materials, tooling, etc.

We would like to be able to resell materials such as sheet goods (plywood, MDF, acrylic, etc.) 3D printer filament, tooling (CNC router bits, milling machine tooling, etc.) This is a service to makers who don't necessarily have the ability to transport physically large materials.

Further definition is needed to specify how payments will be taken. We don't want to accept cash and are uneasy about volunteer managers having access to maker credit/debit cards. Ideally, payments would be charged against a maker's account balance. Is it possible to use an existing student payment system such as Terrapin Express?

FERPA Concerns

Since LabSwipe data is student data there may be concern that some of the data may fall under the protection of the Family Educational Rights and Privacy Act (FERPA). FERPA requires protection of "Personally Identifiable Information" (PII) from release to 3rd parties. Anyone using student PII must take steps to protect this from release, even through the action of a student working in the makerspace. FERPA exempts from the protection requirement certain "Directory Information" that is commonly used. It requires each university to identify what information is considered "Directory Information"

UMD defines their PII and Directory Information here: https://academiccatalog.umd.edu/undergraduate/university-policies/ In July 2020 this policy defined UMD PII & Directory Information as:

"Personally identifiable information" or "PII" means data or information which includes, but is not limited to:

• a student’s name;
• a name of a student’s parent or family member
• an address of a student or a student’s family;
• a personal identifier, such as a social security number, University Identification Number (UID), or biometric record;
• other indirect identifiers, such as mother’s maiden name;
• other information that alone, or in combination, is linked or linkable to a specific student and that would allow a reasonable person in the UMD community who does not have personal knowledge of the relevant circumstances to identify the student with reasonable certainty; or information requested by a person who UMD reasonably believes knows the identity of the student to whom the education record relates.

"Directory Information" means information which would generally not be considered harmful or an invasion of privacy if disclosed. It includes, but is not limited to, a student’s:

• name,
• address,
• telephone listing,
• e-mail address,
• date and place of birth,
• major field of study,
• full-time/part-time status,
• participation in officially recognized activities and sports,
• weight and height of members of athletic teams,
• dates of attendance,
• degrees and awards received, and
• the most recent previous educational agency or institution attended

Note that UID is listed as PII but not excluded as "Directory Information" as is done at other institutions, especially those that also print UID on campus ID cards.

Parallel Development of Sandbox Kiosk Prototype

One possible initiative we could undertake would be the development of a prototype kiosk system for use in the various studios at Sandbox. This prototype would allow us to test ideas for MSM improvements and more quickly iterate through design concepts without having to modify the core MSM system. It would provide a working prototype useful for demonstrating our needs to the MSM development team, or to demonstrate our requirements if MSI decides to invest in an externally-developed system.

Overview of Sandbox Kiosk System

The existing MSM / LabSwipe system assumes each lab will be a single room or small number of related spaces that are hierarchically flat. Sandbox is a group of six different studios, each with a different type of tool. This leads to some confusion and a slowdown each time a maker checks in. If the tools are grouped alphabetically, a maker interested in electronics might check that he plans to use a "multimeter" then have to scroll past "multitool" and 3 different "sander" entries related to woodworking, 4 different types of "sewing machine" in the crafting studio before finding "soldering iron" a few pages down. We've re-ordered the list by studio, which has helped quite a bit but makers using the woodworking studio have to scroll down several screens to find the start of tools they may want to use. While this may be fixable with some tweaks to the existing system UI, we've uncovered other issues that we'd like to address as well.

In a review of system usage for the fall semester, we discovered that most students select a single tool regardless of the length of their visit. A maker may swipe in and select "laser cutter" as the tool they will be using but almost never returns to the front desk if (for example) they need to use a circular saw to trim their stock to the correct size, or need to use a drill to add a couple of holes to their project, or a sander to prepare it for finishing. Individually these failures aren't important but collectively they degrade the quality of data we hope to collect on tool usage and perhaps more importantly make it more difficult for us to report other statistics such as length of visit. Also, this avoidance bypasses the very important checking of training credentials that is a critical reason for having this system in the first place. Indeed, we found that a considerable number of students would select "no tool, table use only" when that option was made available.

To improve this situation, we'd like to move tool selection part of MSM closer to the point where the tool is used. Makers would still swipe in to the space when entering, but would not be asked whaic tools they plan to use. The extreme case of this would be to equip each tool with a sensor that indicated use and requested the maker picking up the tool to authenticate and verify their certification to use that tool. This would likely be too expensive to be practical except on the most hazardous or expensive tools such as milling machines, laser cutters, etc. What we propose and would like to test using the concept of kiosks, would be moving tool check-out to each individual studio. We envision a touch-screen display at the door of each studio. While the touch screen could be a self-contatrined system such as a iPad tablet, we are more inclined to use small computers such as the RaspberryPi.

In a perfect world this kiosk system would be connected to the card key door lock system, but we don't envision that being possible because of political limitations with the UMD card key system.

Initial Requirements for Kiosk Protoype

• Kiosks to run Touch-screen terminals outside each Sandbox studio (to begin with woodworking studio and prototyping studio)
  • Kiosk will display information about each tool available in that studio including training requirements and links to training materials.
  • Tool information and training requirements should preferably come directly from existing wiki pages to ease updating. Either display wiki pages in embedded web browser or use mediawiki API to retrieve wiki content.
• Information shown on kiosk would include both publicly viewable (no login required) and private information (requiring login) such as maker's training accomplishments, etc.
  • Provide quick and simple means for each maker to log in / authenticate with the system (card swipe, phone app, NFC, etc)
• Subset of information from kiosk system also available via login-secured web page accessible from off campus. Initially, remote functionality to include:
  • ability to reserve a tool for a certain period of time, with the length of time specified by the maker, provided that request is within the limits set for that particular tool, perhaps also taking into account the time of day or day of week.
    • For example, a laser cutter might be reservible in blocks of 30 minutes with maximum of 3 blocks
    • A 3d printer might be reservible in blocks of 2 hours with the maximum number of blocks varying depending of day of week and time of day. For example, a Friday afternoon reservation might allow 48 hours total time, while Monday afternoon would only allow 4 hours total.
    • A more common power tool such as a jigsaw or drill might be reservible in blocks of 30 minutes with a maximum of 2-4 blocks.
  • Some mechanism should be devised to prevent makers from always reserving the maximum number of blocks of time.
  • display calendar view for each of the reservible tools that shows free/reserved blocks for each tool
  • display calendar view for each studio that shows free/reserved status based on the tool being reserved. This view to be used to enforce Covid-19 distancing requirements

Notes on other commercial or open source systems with similar functionality

Lists of Systems

Hackerspaces.org wishlist of software functions / features.

https://wiki.hackerspaces.org/Software_Wish_List

List of software from hackerspaces.org

https://wiki.hackerspaces.org/Hackerspace_Software\

Individual Systems

Systems Focusing on Access Control (may include door access in addition to machine tool access / lockout)

Open Source Access Control Web Interface

https://github.com/zyphlar/Open-Source-Access-Control-Web-Interface

Member Access System for Pumping Station One

https://github.com/hef/ps1auth

HACCSY

Hackerspace Access Control and Check in System. Works with Seltzer CRM, running on a Raspberry Pi. https://www.instructables.com/id/HACCSY-Hackerspace-Access-Control-and-Check-in-Sys/

Open Access Control

Uses the Arduino hardware to build a robust access control and alarm system. https://code.google.com/archive/p/open-access-control/

Systems Combining Access Control and Space Management (may include elements of CRM, AR/AP, training management, inventory control, etc.)

Safety Spot

Commercial maker space management software widely used in university maker spaces. https://www.safetyspot.com/

Makerpass system onepager

https://assets.pubpub.org/hpise2ck/01585588151622.pdf

UT Austin FabApp/JuiceBox

FabApp is a PHP-based system for managing a makerspace (https://github.com/UTA-FabLab/fabapp). JuiceBox is a Python-based system for providing access control to power tools (https://github.com/UTA-FabLab/JuiceBox). These and other UTA apps are on the UTA GitHub: https://github.com/UTA-FabLab

OpenBravo

https://www.openbravo.com/

Byro

https://github.com/byro/byro

HSBNE

https://github.com/hsbne/hsbneportal

MetalabOS

https://github.com/Metalab/mos/

NOMOS

https://github.com/vhs/nomos

MeMaTool

https://github.com/sim0nx/mematool

Fabman software

Management software with machine control hardware devices, API, and other features. https://fabman.io/

RFIDDoorLock

https://wiki.melbournemakerspace.org/projects/RFIDDoorLock

Systems Focusing on Space Management without Access Control (may include elements of CRM, AR/AP, training management, inventory control, etc.)

(Some of these may integrate with other Access Control Systems)

WildApricot

Membership management software used by many maker spaces. https://www.wildapricot.com/

Seltzer CRM

Open source CRM / membership management software created by a maker space and designed to be extensible and easily modified. https://wiki.hackerspaces.org/Seltzer_CRM

SIMPL

Software primarily designed to manage coworking spaces with features to support maker spaces. https://smpl.io/software/makerspaces/

Not Yet Categorized

WikiSpaces

The primary goal of the WikiSpaces project is to provide a 'startup' wiki, which is basically a MediaWiki distribution especially for hackerspaces. This distribution will provide a working, up to date, MediaWiki installation, with the commonly needed extensions installed and configured. https://wiki.hackerspaces.org/WikiSpaces

Scholarly article on value of information collected using Maker Lens / MakerPass access system.

https://people.eecs.berkeley.edu/~eschoop/docs/makerlens.pdf