Talk:Maker Space Manager System

From sandbox
Revision as of 20:54, 6 July 2021 by Gfc (talk | contribs)
Jump to navigation Jump to search

LabSwipe /MSM System Development History & Future Road Map

Development History

Would someone on the Labswipe team add to this section?

Current Release

Future Enhancements

Road Map for future enhancements.

2021-2022 MSM Rework Outline

  • Outline of desired improvements for development work from Summer 2021 to Summer 2022
    • Improvements to existing UI / core LabSwipe functionality
      • Improved editing of data entry fields
      • Integration with UMD swipe Identity API (and Canvas LMS API?) to correctly identify new cards swiped into system and close current opportunity for student to use fake ID with made-up UID.
      • Integration with UMD swipe API (or Canvas LMS API?) to identify deactivated student ID cards.
      • Improve handling of replacement ID card

required to use a tool in a particular studio.

    • Integration with Canvas LMS
      • Using Canvas API, ensuring API key is well protected using a secrets manager or similar apporach
      • Implement a middle layer between MSM and Canvas to track training certifications (similar to a micro credentialing system) in a way that creates an abstraction layer between a canvas course and a training certification.
    • Integration with a tool access control system (such as Safety Spot, The Google system used at Ace Makerspace and elsewhere, or the Nova Pass system)
      • This integration would require certain tools flagged in system to have a swipe card reader at the tool which verifies training before tool will operate.
      • While extending MSM to support tool access control, modify it as well to allow two-tier implementation of MSM where initial swipe allows entry into makerspace (and perhaps required selection of a studio) and subsequent swipe was required to select a particular tool.
    • Tool reservation / check-in
    • Tool Loan (away from makerspace)

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.
  • The system should support tracking of training that was completed at other UMD MSI makerspaces to support the MSI plans to open up access to makerspaces across campus. For example, a maker who completed Glowforge laser training at one of the library makerspaces should be able to use the Sandbox Glowforge without additional training.

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 and also by having tool lockout devices that track tool usage on tools that justify the expense of a lockout device.

Kiosk System Test

Sandbox hopes to test a kiosk system in Summer 2021. The kiosk system is envisioned as a way to improve tool usage tracking and replace the tool identification signage on each studio door. Each studio would have a touch screen computer system on or near the door that displays a visual listing of tools in that studio. Makers would be asked to select the tool they wanted to use. The kiosk would verify that the maker had completed any required training on that tool.

By asking the maker to check the tool back in, we would be able to collect additional information about usage of individual tools as well as provide remote visibility of tool availability to makers planning on visiting the makerspace.

Eventually we envision the kiosk system having additional functionality including tool and studio reservation, broken tool tagging, identifying tool experts, etc.

Tool Usage Control

We'd like the system to provide tool access control 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 access control 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, the system 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, restoring a cabinet interlock circuit, or other mechanism. Several different 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.
  • The system should ideally store locally a list of the IDs for all makers who recently were authenticated to use the tool (or store a list of all authorized users, updated periodically) This may be useful for allowing the system to function even when network connectivity has failed.
  • A display on each access control station would ideally display information such as the name of the current authorized user (or last user if tool is idle), length of tool use (or countdown to expiration), connectivity check, etc.

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

Listing of commercial or open source systems with overlapping functionality

Lists of Systems (other pages like this one)

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\
MakerNexus notes on Access Control Systems
https://makernexuswiki.com/wiki/Access_Control_Systems

Individual Systems

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

(see also Systems Combining Access Control and Space Management below)

Nova Labs Nova Pass
https://novapass.nova-labs.org/ (active system home page)
(description from Makerfaire: https://nova.makerfaire.com/maker/entry/1224/)
(details:https://goo.gl/RVmtiS)
RATT - RFID All The Things
New Hampshire's MakeIT Labs RaspPi based RFID access control system. https://github.com/makeitlabs/ratt (video: https://www.youtube.com/watch?v=erwIPVwXUr8)
FATT - FOB all The Things
Ace makerspace (formerly Ace Master Toys) https://www.acemakerspace.org/fatt-project/
Ace Master Toys
Makerspace system based on Google's AuthBox system https://github.com/google/makerspace-auth
Ace Makerspace Occupancy System
https://www.youtube.com/watch?v=kemAM8MWIN8
Google Makerspace Auth (aka AuthBox)
https://github.com/google/makerspace-auth
RasPi-Lockout (designed for RIT Construct Makerspace)
Build Brighton Access Node
https://www.youtube.com/watch?v=3X64JmTpOcA
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/
tinkerAccess
The tinkerAccess system is a Raspberry Pi based access control system that can be used to prevent unauthorized users from using devices that require special training. It could also conceivably be used to control electronic lock boxes or doors. The system was originally designed and created by Matt Stallard, Ron Thomas, and Matt Peopping for TinkerMill a makerspace in Longmont, CO. It is continually being maintained and enhanced by other contributors in the community. https://github.com/TinkerMill/tinkerAccess
Triple Cities Makerspace ACS System
https://www.tcmakerspace.com/index.php/2019/08/19/project-profile-access-control-system-acs/
The MakerBarn in The Woodlands, Texas MACS System
http://koljawindeler.github.io/macs/.
PITT-X Makerspace Access System
https://www.youtube.com/watch?v=2HG-vyV4yoM
Member Access System for Pumping Station One
https://github.com/hef/ps1auth
https://github.com/bdenne2/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 Ethernet
https://github.com/zyphlar/Open_Access_Control_Ethernet
Open Source Access Control Web Interface (works with above)
https://github.com/zyphlar/Open-Source-Access-Control-Web-Interface

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/
(UC Berkeley) Makerpass system onepager
https://assets.pubpub.org/hpise2ck/01585588151622.pdf
Recursion
https://recursion.space Commercial system with free tier. Patented equipment lockout controller.
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
UT Austin Team Lockout
https://blog.uta.edu/cseseniordesign/2019/07/20/lockout/ The Maker Space Lockout System correctly gives access to Machinery only to users that have been adequately briefed on the machinery’s safety and operation. The system will be able to control access for each user according to their level of skill and expertise. Users of The Maker Space Lockout System will also become more equipped to handle and view wear and tear on machines via the data collection purge at the end of each job.

Not yet Categorized

Fabman software
Management software with machine control hardware devices, API, and other features. https://fabman.io/
RFIDDoorLock
https://wiki.melbournemakerspace.org/projects/RFIDDoorLock
Byro
https://github.com/byro/byro
HSBNE
https://github.com/hsbne/hsbneportal
MetalabOS
https://github.com/Metalab/mos/
NOMOS (Membership Management)
https://github.com/vhs/nomos
MeMaTool
https://github.com/sim0nx/mematool
RFID Tool Cabinet
https://www.youtube.com/watch?v=u-L_7pyPcvE

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/
OpenBravo (ERM/ERP)
https://www.openbravo.com/
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


Not Yet Categorized

Scholarly article on value of information collected using Maker Lens / MakerPass access system.
https://people.eecs.berkeley.edu/~eschoop/docs/makerlens.pdf
Retrieved from "https://wiki.umiacs.umd.edu/sandbox/index.php?title=Talk:Maker_Space_Manager_System&oldid=2380"