Talk:Maker Space Manager System

From sandbox
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
2021
  • Improvements to existing UI / core LabSwipe functionality (Fall 21)
    • Improved editing of data entry fields
    • Integration with UMD swipe Identity API to correctly identify new cards swiped into system and close current opportunity for student to use a created ID card with false UID.
    • Integration with UMD swipe API to:
      • Identify deactivated student ID cards and
      • Update CardID serial number when a lost ID card is replaced with a new card.
2022
  • Integration with Canvas LMS (Spring 22)
    • Using Canvas API, ensuring API key is well protected using a secrets manager or similar approach
    • 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.
    • See Integration with ELMS/Canvas Learning Management System below for detail
Overview of Enhancements
  • Additional Enhancements not yet implemented (many not yet scheduled).
    • 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)
      • See Tool Access Control below for details
      • 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 a particular makerspace to set up a two-tier implementation of MSM where initial swipe allows entry into makerspace without selecting a specific tool (but perhaps requires the selection of a studio or category of tool) and subsequent swipe was required to select a particular tool.
    • Tool reservation / tool-in-use flagging
    • Tool Loan (away from makerspace)
    • Student charging system (allow students to purchase materials and tooling using student ID or credit card.
    • Faculty charging system (allow faculty / researchers to purchase materials using KFC account #)
    • Matching of maker skills between students and managers.
    • Campus-wide inventory of tools at each makerspace with ability for students to search for a particular tool (similar to MIT Manus system)

Many of these are presented in more detail below:

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.

Improve quantity and quality of tool usage data being gathered.

Currently, the MSM system only asks each makerspace visitor which tools they will be using when they first swipe in at the front door. We've found this arrangement results in distorted statistics as many users just select the first tool they see on the list, don't take the time to check off every tool they intend to use, and often end up using tools they hadn't intended when they first arrived.

An improvement would be to add additional data gathering points in the makerspace. For example, by adding touch screens with swipe readers in each workshop or tool storage area we could encourage makers to log every tool they use by making the process more convenient. Another approach would be to use a mobile web app to log tool usage by scanning each tool's barcode or otherwise selecting the tool.


Several of the entries below relate to our goal of gathering more data on tool usage.

  • For example, the safety-driven requirement to add Tool Access Control lockout devices to dangerous tools (such as chop saws and lathes) will also help us gather more detailed tool usage data for those dangerous tools.
  • Adding an advanced tool reservation capability will add additional usage data for popular tools such as 3D printers and laser cutters.
  • Rather than add expensive lockout devices to all tools, we discuss the possible idea of adding Tool-In-Use flagging.

All of these work together to not only better track tool usage but also to improve the user experience and reduce frustration, increase compliance with training requirements, and ensue our compliance with campus safety rules.



Tool Access Control

Once the MSM system is able to look up tool training certification information using the ELMS/Canvas APAI. we'd like to add on to MSM additional hardware and software that will directly control use of certain tools that are deemed to be dangerous (such as a CNC router, milling machine, band saw, etc.) or other tools that, while not particularly dangerous, require specific knowledge to operate correctly (such as laser cutter, SLA 3D printer, etc) to avoid damaging the tool.

  • This access control system should be implemented as a separate hardware and software system connected to each tool we wish to have this added level of access control. While we envision this being implemented using commercially-available micro controllers (such as an Arduino-compatible microcontroller) or single board computers (such as a Raspberry Pi computer) any other implementation is acceptable so long as it provides a low cost per controlled machine tool.
  • This access control capability would require each maker to swipe their UMD ID before using that tool. Use of a UMD ID is preferred since all students and staff already carry this with them. Other authentication mechanism such as RFID or other ID card that works by proximity instead of requiring a physical swipe, or NFC or similar systems using a person's cell phone. For systems not using UMD ID magnetic stripe cards, the cost of additional cards, software, etc must be factored into our decision to use that system.
  • 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 allow use of that tool. The preferred central database would be the existing UMD ELMS/Canvas Learning Management System or a system (such as a micro credentialing or badging system) that is connected to and synchronized with the ELMS/Canvas system. Systems that provide a central database system other than ELMS / Canvas must provide an automatic mechanism to update the database using the ELMS / Canvas API.
  • The means to allow use of the tool should be by:
    • Switching on power through a relay or contactor controlled by the software logic
    • Enabling a logical +5 volt signal to be read by the tool's existing controller (such as an ENABLE signal)
    • By deactivating the tool's e-stop circuit, restoring a cabinet interlock circuit, or other mechanism by closing or opening a relay contacts. (i.e. dry contact closure)
    • Several different approaches (ideally all of those listed above) should be provided to adapt the system to the widest variety of machine 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 this but a simple example would be by setting a timeout after which the system requires the user to verify they are present by pushing a button or re-swiping their ID. This capability should be settable per-tool.
  • For tools enabled by simply applying power, the system should prevent these tools from starting up immediately on authentication to prevent unsafe situations. For example, by using a magnetic motor starter.
  • 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 is to permit use of the tool control system even if the central database is unavailable or if 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.

System Support for Enforcing Buddy System

UMD ESSR safety rule changes require certain tools to be used with the "buddy system" In short, the "buddy system" prohibits certain dangerous tools to be used by a person alone in the workshop. Another person must be close enough to see and hear the tool being used so they can render aid and call for assistance in case of injury.

The MSM system should provide support for enforcing the buddy system. This support could entail requiring a second person to swipe in when using certain tools. This requirement might be limited to certain times of day (for example during the evening or when staff is reduced. The requirements for buddy system support are not yet clear, this is a placeholder.

Tool-In-Use Flagging

An additional capability desired is the ability to flag the status of a tool as In Use, Available for Use, or other statuses such as Awaiting Repair or Out of Service Since demand for many tools is high and a student may be frustrated if they travel to a makerspace only to find a particular tool unavailable, it would be helpful for the system to flag tools that are not available for use because they are being used by someone else or are broken or otherwise unavailable.

  • For tools that are not in service, a makerspace staff member should be able to change the status through a web interface.
    • The system should record a date/time stamp for when the tool was taken out of service and a date stamp for an expected return-to-service.
  • For tools being used by a maker, the MSM system should provide a mechanism for students to quickly and easily select a tool for use. This capability should allow the use of that tool for a fixed period of time, ideally this time period would differ for different types of tools (for example, a hammer would be flagged as in-use for 1-hour intervals while a sewing machine might have longer intervals such as 3 hours.
    • The Tool-in-Use flag feature would verify the maker has completed any necessary training.
    • When a different maker wishes to use that 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 available for their use.
    • 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.
    • Ideally, the system would send an SMS message or some other sort of notification that the maker's use time has expired.
    • Some examples of quick and easy mechanisms for makers to lag that they are using a tool
      • A touch screen kiosk in each workshop or tool storage area.
      • A QR code on each tool or on the storage location for each tool. The QR code would be scanned by the maker using the tool
      • A mobile web app used by the maker.

Note that the Tool-In-Use Flag Feature will provide a great deal of useful information about the relative popularity of each tool and could provide data to support the purchase of additional tools.

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

See Tool-In-Use flagging above. 'Check-In' and 'Check-Out' functions would be used by a student when they take a tool from storage to their work area or return it to storage. Note that Check-Out is different than Tool-Loan which entails removing a tool from the makerspace.

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

Kiosk System Test

Sandbox hopes to continue the development and testing of a Kiosk System in Spring 2022. 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.

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
Ithaca Generator AuthBox
Manchester, NH MakerAuth
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=2682"