The following instructions are for Alpha testers only (or those building their own v1 Alpha Holoseats).
This patch is to remove the nib on the front of the Holoseat sensor module. This modification is required to ensure the signal from the tone ring is reliable.
Before implementing the patch the sensor module will look like this:
After implementing the patch it will look like this:
Below are the assembly instructions for the v0.3 Holoseat. The controller for this version is built using an AdaFruit Feather 32u4 Basic Proto. The sensors are on a remotely mountable board. Final assembly requires an appropriate set of under desk exercise pedals (we recommend DeskCycle or FitDesk ). Note, you will need to use your soldering skills on this build.
(1) Holoseat Sensor Board
The Sensor Board is now complete.
(1) Holoseat Controller
The Controller is now complete.
(1) Completed Holoseat Final Assembly
The primary objective for the final assembly is to mount the Sensor Board and the HS010 (magnet) on your chosen under desk exercise pedals. At this point in the development we are using easily reversible assembly processes (read tape) so we do not damage the exercise pedals. Note, for convenience these instructions show the Sensor Board and Controller mounted in small plastic containers (e.g. travel toothbrush holders or similar).
The Holoseat Final Assembly is complete. Proceed to the Software Set Up instructions to install the firmware and desktop configuration app.
Welcome to the backers page. Here you will find a list of all the people and organizations who have contributed to the Holoseat in one way or another.
The following block diagrams capture the architecture for the v0.3 Holoseat.
( SVG Format )
The Holoseat interacts with three external systems: the Player, the Game, and the Configuration App. The Player uses Holoseat directly by pedaling to walk forward or backward in the game and by using the Enable button to control the enabled state of the Holoseat (when enabled pedaling causes key presses, when disabled pedaling does not cause key presses). The Player also uses the Holoseat indirectly through the Configuration App.
The Game and the Configuration App are programs running on the Computer. Both programs expect input from the Player through HID controls. The Game provides interactive entertainment to the Player. Holoseat is currently only compatible with Games utilizing key presses to control walking (e.g wasd). The Configuration App provides controls to change settings in the Holoseat (either live or as new default values).
The Player is connected to the Game and the Configuration App. The Player interacts with the Game through its standard HID controls for all actions except walking forward and backward (these actions, as mentioned above, are controlled through the Holoseat). The Player uses the Configuration App through its HID controls to update settings in the Holoseat.
The Holoseat is connected to the Player, as described above, and to both programs running on the Computer. The Holoseat presents itself as an HID device to the Game and sends the user configured key presses for walking when the Player uses the pedals. The Holoseat uses a custom serial protocol (HSP) to communicate with the Configuration App. This protocol allows the Configuration App to interrogate the Holoseat for its current state (covering both settings and activity) and to update settings on the Holoseat (both live and default values).
( SVG Format )
The Holoseat presents four external interfaces (also shown on the System Context). They are the Pedals, the Enable Button, an HID interface, and the Holoseat Serial Protocol interface. See the System Context for the uses of these external interfaces.
The Holoseat is composed of four subsystems. They are the Exercise Device (typically an under desk bike or elliptical), the Sensor Triggers, the Sensor Board, and the Controller. The Exercise Device provides the physical interface for the Player (the Pedals) and the required resistance to provide the exercise experience.
The Sensor Triggers and the sensors mounted on the Sensor Board must be matched to provide the required resolution to determine the Player's cadence when pedaling. For example, you could pair Hall effect sensors with magnets for the sensors and Sensor Triggers, making sure to select magnet strength and sensor sensitivity such that they are reliable over the distance between the pedals and the Exercise Device frame. The Sensor Triggers are mounted on the one of the pedal bars and the Sensor Board (with its sensors) is mounted on the Exercise Device chassis.
Finally, the Controller is the embedded system which implements the Holoseat logic. On one side of the Controller is the Sensor Data line, reading sensor trigger events. On the other side is an implementation of the HID protocol. The controller computes the Player's cadence from the sensor events. Using the cadence, the Controller determines when to send key presses to the Game. Additionally, the Controller contains the Enable button, for use by the Player to control the enabled state, and a serial port listening for Holoseat Serial Protocol messages from the Configuration App. HSP messages can be used to update settings in the Controller such as enabled state, trigger cadence, and assigned keys for forward and backward motion.
This page covers research into creating a Bluetooth HID connection from the Holoseat controller to the gaming system (PC or console) and accepting Bluetooth HID connections from user devices (e.g. joypads). The Holoseat controller will need to be able to present itself as either a keyboard & mouse combination or a joypad. The material on this page covers some Bluetooth fundamentals (classic vs BLE), the types of Bluetooth hardware used in some of our target platforms (CHIP Pro, PS4, PCs), and available libraries for interacting with Bluetooth hardware in Node.js. It closes with an interesting (but not usable) example from the maker/hacker community.
Based on the following research, it is far too early to implement Bluetooth features in the Holoseat. Given recent developments in the Bluetooth standard, it is obvious we are only interested in implementing Bluetooth Low Energy (BLE) devices. However, the gaming platforms we are looking at supporting have widely varying support for Bluetooth in any form, with only one platform fully supporting BLE (MacOS). Until there is greater support for BLE on our selected gaming platforms we do not need to develop a means of presenting Holoseat as a Bluetooth peripheral.
The news is only slightly better on the Bluetooth host side of the requirements. While the CHIP Pro has a Bluetooth stack included in the hardware (which supports BLE), the drivers are not yet ready. We could shift to an external Bluetooth module, but that would just add cost that we really don't need to add at present. Instead, the recommended path forward is to select the onboard Bluetooth stack to be the Bluetooth host hardware and delay implementation of Bluetooth host features until the driver is released by NEXT Thing Computing. This will allow us to add support for acting as a Bluetooth host with just a software update at any point in time we decide.
In terms of impact to the 2017 development plan, here are updates to the affected Product Backlog Items
Bluetooth has evolved dramatically in the last few years and now comes in multiple "flavors", classic and Bluetooth Low Energy. Classic Bluetooth is the standard most users are familiar with. It is used to connect smart phones to cars and headsets. Classic is the older flavor, it is more common (though that is starting to change in some markets), and it commonly requires pairing. Also, according to posts from Adafruit on their forums making classic devices requires paying costly dues to the Bluetooth SIG.
BLE is a newer Bluetooth flavor, targeting battery powered devices (often sensors) and widely supported by smart phones. It appears to be far more maker friendly as well. It is well supported by Adafruit (Bluetooth products, overwhelmingly BLE) and spawned a new book from Make publishing, Make: Bluetooth.
Human Interface Devices (HID) can be built as either classic or BLE devices. It is not clear if the same device (using the same radio board) can be made to present itself as a classic or BLE device. However, it seems clear that smaller organizations are moving to BLE only development.
From the CHIP Pro datasheet, it uses a Realtek 8723DS combination module which provides Wi-Fi B/G/N and Bluetooth 4.2 LE connectivity." Other documentation has indicated the Bluetooth driver can be set as either a host or a device. So, it can be used to connect with classic and BLE devices or it can present itself as a BLE device (but not both at the same time). See notes above about implementing devices that present themselves as classic devices.
Unfortunately, at present Next Thing Computing has disabled the Bluetooth driver on the CHIP Pro (see this forum post last updated 2017-02-15 for more details). For the time being we cannot demonstrate any level of Bluetooth connectivity with the CHIP Pro and it is not clear when the driver will be enabled.
The PS4 DualShock 4 joypads connect to the PS4 using Bluetooth. Unfortunately, the PS4 only supports classic Bluetooth. Specifically, the PS4 supports Bluetooth 2.1 + EDR.
The following material is from Chapter 1 of Make: Bluetooth. We will include all three PC platforms in this discussion (Windows, MacOS, and Linux). Windows supports classic Bluetooth (specifically v2.1) in Windows XP, Vista, and 7. Windows 8 and 10 support BLE. Note, the availability of Bluetooth hardware on Windows PCs varies greatly, though modern laptops often have some flavor of Bluetooth hardware.
All Apple computers built after 2011 include BLE hardware and MacOS fully supports BLE since Mountain Lion. In short, unlike Windows machines, Macs should just work with the more maker friendly Bluetooth flavor.
Turning to Linux, the results are mixed. The OS itself supports BLE through the BlueZ service. However, like Windows machines, the computers people choose to install Linux on vary greatly in terms of available Bluetooth hardware.
At present Bluetooth support on Holoseat related hardware is all over the map. The CHIP Pro has the hardware for one connection (host or peripheral), but lacks the required drivers. And on the gaming systems side, the common denominator is classic Bluetooth, which is not very maker friendly according to Adafruit. In short, it is too early for a device like Holoseat to fully embrace Bluetooth. At best, we can select the CHIP Pro's onboard Bluetooth stack as the Holoseat's host side Bluetooth implementation, deferring work on it until the drivers are released. But, until more of the gaming machine market supports BLE controllers, there is no real value in developing support for the Holoseat to act as a Bluetooth peripheral.
Sandeep Mistry maintains three Bluetooth libraries which we will likely find useful. Note, they are all BLE only libraries and they only work with specific Bluetooth hardware.
In this example, the firmware from the RN-42 onto the HC-05. This kind of hacking, while interesting, is not strictly legal (obtaining the RN-42 firmware is not something one just does), so it is not a recommended approach. However, it does demonstrate how capable a small system can be at capturing signals from one system (the joypad) and in real time translating them to HID over Bluetooth signals. Consider this evidence that the kind of inline gameplay translation we want the Holoseat controller to do is possible. Much of the following research was found by following the links from a Hackaday post - Convert Any USB Keyboard to Bluetooth.
The video below is a summary of this project - Bluetooth HID gamepad using HC-05 module
ESP32 Wifi Bluetooth Module, another Bluetooth module that has people talking. Need to do more research.
See Google Spreadsheet for latest revision - Bill of Materials
BoM as of 2016-07-07
| Item Number | Quantity | Item Description | Link | Approved Vendor List (AVL) | AVL PN | Minimum Order Quantity (MOQ) | Lead Time | Unit Price | Total Price | Substitution Notes |
|---|---|---|---|---|---|---|---|---|---|---|
| HS001 | 1 | Double-Side Prototype PCB Universal Printed Circuit Board Universal PCB Circuit Board (2x8cm) | Order Link | Amazon.com | B012YZ2Q3W | 10 | 2 days | $0.68 | $0.68 | see description |
| HS002 | 2 | CE Tech Category 5e Jack - White (Model # 5025-WH-10) | Order Link | HomeDepot.com | 204410618 / 1000023199 | 10 | In Store | $2.30 | $4.59 | see description |
| HS003 | 2 | 750 OHM 1/2W 1% Axial Resistor | Order Link | Digikey.com | PPC750XCT-ND | 1 | 7 days | $0.20 | $0.40 | see description |
| HS004 | 2 | OH090U Hall Effect Sensor (Digiatl sensor, 90G Trip, 65G Release) | Order Link | Digikey.com | 365-1001-ND | 1 | 7 days | $1.67 | $3.34 | see description |
| HS005 | 2 | Diffused Blue 3mm LED | Order Link | AdaFruit.com | 780 | 25 | 7 days | $0.24 | $0.48 | see description |
| HS006 | 1 | AmazonBasics RJ45 Cat5e Ethernet Patch Cable (14 Feet/4.2 Meters) | Order Link | Amazon.com | B001TH7GVE | 1 | 2 days | $4.99 | $4.99 | see description |
| HS007 | 1 | Adafruit Feather 32u4 Basic Proto | Order Link | AdaFruit.com | 2771 | 1 | 7 days | $19.95 | $19.95 | or similar Leonardo clone |
| HS008 | 1 | 16mm Illuminated Pushbutton - Green Momentary | Order Link | AdaFruit.com | 1440 | 1 | 7 days | $1.50 | $1.50 | see description |
| HS009 | 1 | AmazonBasics Micro-USB to USB Cable | Order Link | Amazon.com | B013PVKQHC | 3 | 2 days | $2.33 | $2.33 | see description |
| HS010 | 1 | 3/8 in dia. x 1/8 in thick, 5.46 lbs pull force [D62-N52]" | Order Link | kjmagnetics.com | D62-N52 | 1 | 7 days | $0.77 | $0.77 | see description |
| HS011 | 1 | 220 ohm 1/2W 5% Carbon Film Resistor | Order Link | Radio Shack | 2711111 | 5 | In Store | $0.30 | $0.30 | see description |
| HS012 | 1 | 10K ohm 1/2W 5% Carbon Film Resistor | Order Link | Radio Shack | 2711126 | 5 | In Store | $0.30 | $0.30 | see description |
| Supplies | ||||||||||
| 1 | Clear 100mm 6 Size φ1.5/2.5/3/5/6/10mm Heat Shrink Tubing Cable Wrap Kit | Order Link | Amazon.com | B0156JYK5U | 1 | 2 days | $9.75 | $9.75 | see description | |
| 1 | Hook up wire kit | |||||||||
| 1 | Roll of solder | |||||||||
| 1 | Ethernet cable to pull wire from |
Some hookup wire options:
Note: Revising Bill of Materials based on OSE Wiki How to Make a BOM
HS-02: Controller
TBD by Bryan
TBD by J. when test and firmware code is updated
The v0.2 design is based on the answer to Q4 of the Initial Questions. The Fritzing drawing shown below covers the prototype design. The remainder of this document covers the design decisions by addressing each of the requirements. Note, the bread board seen in the Fritzing drawing will be replaced with a prototype shield like this one.
To send key presses, the v0.2 holoseat controller replaces the Arduino Uno + USB Keyboard Controller from v0.1 with an Arduino Leonardo, using the Leonardo's built-in keyboard emulation.
To sense activity on the exercise equipment, the holoseat will continue to use a reed switch. For v0.2, the reed switch used will be a Directed Electronics Magnetic Switch Radioshack 55050593 as with the Arduino Bike Speedometer (this switch is no longer available in stores).
To suppress the walk command signal, a toggle switch will be added with the closed position indicating the walk command should be sent and the open position indicating the walk command should not be sent. The toggle switch used will be a Radioshack #275-645 as with the Arduino Bike Speedometer. See the push button tutorial for an example of reading a switch/button in the source code.
The status of the walk command will be indicated with an LED. The LED will be lit when the walk command is active, and unlit when the walk command is not active. See the LED tutorial for an example of lighting an LED.
Supporting single step will be implemented completely in source code. The current plan is to have different behavior during the reed switch interrupt handler if the RPM is 0 (which should trigger a single key press) vs when the RPM is non-zero (which should work like the vs 0.1 holoseat).
The walking speed (that is the RPM value required to trigger a key press be sent to the computer) will be tuned with a slide style potentiometer. The mid-way point on the slider will indicate the user wishes to use the default walking speed. Lower values on the slider will reduce the walking speed down to a minimum of 50% of the default. Higher values on the slider will increase the walking speed up to a maximum of 150% of the default. See the Potentiometer Tutorial for an example of reading values from a potentiometer.
Note, slide potentiometers are not readily available at hobby electronic stores (aka Radio Shack - see HOWTO find and buy faders / sliders / slide pots / slide potentiometers for more details). Current best example of a slider which will fit on the prototype shield is this one from Mouser Electronics.
None
See First Time Setup.
The firmware for the Holoseat can be found in the SVN Repository. Its basic function is to detect pedal events from the sensor, use the timing of those events to determine the cadence (in RPM), and then send the walk command (generally by pressing the 'w' key) when the pedal speed is greater than the specified trigger speed.
The default parameters for the firmware are stored in the holoseat_constants.h file so they will be available at start up without the need for a connection to the desktop control application. The desktop control application modifies the default values by updating the values of the corresponding constants in this file and then flashing updated firmware to the Holoseat. The following parameters have default values in the constants file.
The HoloSeat firmware has a serial protocol, the Holoseat Serial Protocol (HSP), to enable the desktop control application to modify all key parameters and to determine the current configuration of the Holoseat.
The HSP supports three commands. Each command is made up of a single upper case character indicating the statement type. One command, the (S)et statement, also takes an input string.
? - Ready(?) command; used to determine if the HoloSeat is ready to receive commands over the HSP (will reply with the (R)eady message followed by one standard state message if the HoloSeat is ready)S <config string> - (S)et command; used to send updated configuration to HoloSeat (HoloSeat will reply with OK on success). The config string has the following format:<WFC>,<WBC>,<E>,<TC>,<L>,<LI> - example: S w,s,0,60,0,20
<WFC> - Walk forward character (example: w)<WBC> - Walk backward character (example: s)<E> - Enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<TC> - Trigger cadence (example: 65)<L> - Logging enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<LI> - Logging interval in deci-seconds (example: 10)Q - (Q)uery command; used to request the HoloSeat send one standard state message (see Protocol Messages below)The HSP has two messages. One is a single character message similar to the commands and one is the HSP standard state message which is sent after initialization, in reply to a (Q)uery command, and as the serial logging message.
R - (R)eady; sent by the HoloSeat to indicate it is ready for serial communication; sent in reply to the Ready(?) command and when serial port is attached in debug mode (to be added)<VER>,<WFC>(<DWFC>),<WBC>(<DWBC>),<E>(<DE>),<C>/<TC>(<DTC>),<L>(<DL>)/<LI>(<DLI>) - standard state message, see below for key; example: 1.2.3,w(w),s(s),1(1),70/65(75),1(0)/10(10)
<VER> - Firmware version string (example: 1.2.3)<WFC> - Walk forward character (example: w)<DWFC> - Default walk forward character (example: w)<WBC> - Walk backward character (example: s)<DWBC> - Default walk backward character (example: s)<E> - Enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<DE> - Default enabled state, same format as <E> (example: 1)<C> - Current cadence rounded to whole number; positive value means direction is forward, negative value means direction is backward (example: 70)<TC> - Trigger cadence (example: 65)<DTC> - Default trigger cadence (example: 75)<L> - Logging enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<DL> - Default logging enabled, same format as <L> (example: 0)<LI> - Logging interval in deci-seconds (example: 10)<DLI> - Default logging interval in deci-seconds (example: 10)Always start a serial session by sending a Ready(?) command. If a (R)eady message is not received, wait and try again until a timeout is reached or a (R)eady message is received. Be sure to check the version string sent in the initial standard state message to ensure your app is compatible with the version of the HoloSeat firmware.
After you have initialized your connection, you can then use the (Set) and (Q)uery commands as necessary to control and observe the HoloSeat's state.
The following instructions cover all of the steps required to set up your new Holoseat on supported exercise equipment.
Your Holoseat includes the following components shown in the picture below.
When you are done, it should look like the following picture.
Follow the manufacturer’s instructions to assemble the exercise equipment (supported exercise equipment includes DeskCycle and DeskCycle 2). Note, you should stop after you have completed the steps covering installing the equipment's feet and pedals. Holoseat will replace the included "bike computer".
Requires: exercise equipment, tone ring, and hex key
Requires: exercise equipment, spacer, sensor, alcohol wipe
Requires: exercise equipment, controller
Requires: exercise equipment, sensor cable
Note, the drivers are pre-installed with Windows 10. The following steps are only required for Windows 7 and Windows 8.
TBD
Requires: exercise equipment with Holoseat
Requires: exercise equipment with Holoseat, USB cable, PC
Exerfy your games! This concludes the setup of your Holoseat, you are ready to play.
TL;DR - This is something we will want to do for v1.0 not v0.4. It will allow use to identify Holoseat as Holoseat and not a Feather, Arduino, etc. This will be important for drivers on Windows and to make it easier for the serial client to identify the Holoseat via the description. We should still go ahead and register for a PID now so we have it reserved.
The Holoseat controller has a two layer communication stack. The lower (private) layer is a custom serial protocol, implemented in JSON messages. The upper (public) layer is a Socket.io event/message API wrapping around the serial protocol. This architecture places the bulk of the responsibility for implementation on the firmware, accessed using the private layer. The public layer is then only responsible for passing messages in/out of the private API and reporting when the Holoseat is disconnected.
This page serves to document both layers. Each event/message will be covered at a conceptual level followed by layer specific information and examples.
| Field | Value |
| Baud Rate | 115200 |
| Data Bits | 8 |
| Parity | None |
| Stop Bit | 1 |
This section covers the events and message that the controller responds to (aka those sent to the controller by clients).
Note, the various set_* events only broadcast their corresponding client events when they receive data that leads to an actual state change. So, if the Holoseat is already enabled and set_enabled is called with a value of True, then no state change will occur and in turn the enabled event will not be broadcast to the clients.
Purpose: Used to establish client connection
Event Specific Inputs
Response
Event Name: connect
Event Data: none
Serial Message: {"event_name":"connect", "client_id":<socket.id>}
Purpose: Used to toggle enabled state
Event Specific Inputs
Response
Event Name: set_enabled
Event Data: {"enabled":<True|False>}
Serial Message: {"event_name":"set_enabled", "client_id":<socket.id>, "data":{"enabled":<True|False>}}
Purpose: Used to give Holoseat a new configuration (aka tell it how to react to cadences)
Event Specific Inputs
Response
{"name":"wasd", "forward":{"hid":"keyboard", "responses":[{"triggerCadence":0, "actions":["w"]}]}, "reverse":{"hid":"keyboard", "responses":[{"triggerCadence":0, "actions":["s"]}]}}
This string would be hard coded into the firmware and used to initialize the default configuration object.
Used by games responding to the cadence stream instead of hid actions.
{"name":"noop", "forward":{"hid":"keyboard", "responses":[]}, "reverse":{"hid":"keyboard", "responses":[]}}
Note the use of empty arrays for the responses. This can be used separately for configurations where only one direction makes sense.
Event Name: set_configuration
Event Data: {"configuration":<configuration object>}
Serial Message: {"event_name":"set_configuration", "client_id":<socket.id>, "data":{"configuration":<configuration object>}}
Purpose: Manage the resistance level of the execise equipment Holoseat is connected to
TBD
TBD
This section covers the events and message that clients must respond to (aka those sent by the controller to clients).
Note, events and messages read from the private layer may leave out the client_id. No client_id indicate public layer shoud broadcast the event/message to all connects clients (this ia the typcial behavior). Otherwise, the event/message should be sent only to th specified client.
Purpose: Updates clients of enabled state when it changes
Event Specific Inputs
Event Name: enabled
Event Data: {"state":<"enabled" | "disabled" | "disconnected">}
Note, The public layer is the layer which determines if the state is "disconnected". This determination is made every time an event is handled by the public layer. If Holoseat is disconnectd, this event will be broadcast to all clients regardless of value in the client_id field or the original event received.
Serial Message: {"event_name":"enabled", "client_id":<socket.id>, "data":{"state":<"enabled" | "disabled">}}
Purpose: Updates clients of cadence when it changes
Event Specific Inputs
Event Name: cadence
Event Data: {"cadence":<current cadence>}
Serial Message: {"event_name":"cadence", "client_id":<socket.id>, "data":{"cadence":<current cadence>}}
Purpose: Updates clients of cadence when it changes
Event Specific Inputs
Event Name: configuration
Event Data: {"configuration":<configuration object>}
Serial Message: {"event_name":"configuration", "client_id":<socket.id>, "data":{"configuration":<configuration object>}}
Purpose: Updates clients on exercise equipment resistance
TBD
TBD
Purpose: Inform clients of attached Holoseat device and its hardware and firmare versions (see Version Scheme for details).
Message Specific Inputs
Message Data: {"type":"controller_version", "message":{"device":"<device name>", "hwVer":"<major version number>", "fwVer":"<major.minor.patch version number>"}}
Serial Message: {"event_name":"message", "client_id":<socket.id>, "data":{"type":"controller_version", "message":{"device":"<device name>", "hwVer":"<major version number>", "fwVer":"<major.minor.patch version number>"}}}
Purpose: Inform clients of error message
Message Specific Data
Message Data: {"type":"controller_error", "message":"<error message>"}
Serial Message: {"event_name":"message", "client_id":<socket.id>, "data":{"type":"controller_error", "message":"<error message>"}}
TODO - port all of this data over to the HSP page (except /api/debug) and explain how the REST API is mapped to the HSP. Then link to HSP for full details of the calls.
| Verb | Meaning |
|---|---|
| GET | Read value from controller |
| PUT | Write value to controller (volatile) |
| POST | Write value to controller (non-volatile) |
| DELETE | Clear value from controller (volatile) |
Items in italics are for future development. These methods will return a 501 not implemented status code (see status codes for more details).
| URI | Verb | Operation |
|---|---|---|
| /api/main/devicename | GET | Returns the name of the Holoseat device attached to the system |
| /api/main/enabled | GET | Returns current enabled state |
| /api/main/enabled | PUT | Update enabled state |
| /api/main/stepsize | GET | Returns current step size [1-4] |
| /api/main/stepsize | PUT | Update current step size [1-4] |
| /api/main/profile | GET | Returns current profile name (will end in a * if settings have been updated since profile was set) |
| /api/main/profile | PUT | Sets current profile name (cannot end in a '*') Note: sending an empty string as the profile name will suspend configuration update messages until a non-empty profile name is set. |
| /api/main/cadence | GET | Returns current cadence (>0 means forward, <0 means reverse) and cadence level [0-4]. See firmware notes for definition of cadence level. |
| /api/main/version | GET | Returns hardware, firmware, and HSP version data |
| /api/forward | GET | Returns current forward action (see below), returns 404 status if no forward action is active |
| /api/forward | PUT | Sets current forward action (see below) |
| /api/forward | DELETE | Clears current forward action |
| /api/forward/sprint | GET | Returns current forward sprint action (see below), returns 404 status if no forward sprint action is active |
| /api/forward/sprint | PUT | Sets current forward sprint action (see below) |
| /api/forward/sprint | DELETE | Clears current forward sprint action |
| /api/reverse | GET | Returns current reverse action (see below), returns 404 status if no reverse action is active |
| /api/reverse | PUT | Sets current reverse action (see below) |
| /api/reverse | DELETE | Clears current reverse action |
| /api/reverse/sprint | GET | Returns current reverse sprint action (see below), returns 404 status if no forward sprint action is active |
| /api/reverse/sprint | PUT | Sets current reverse sprint action (see below) |
| /api/reverse/sprint | DELETE | Clears current reverse sprint action |
| /api/defaults | GET | Returns current defaults (see below) |
| /api/defaults | POST | Sets new defaults (see below) |
| /api/defaults | DELETE | Restore factory defaults (see below) |
| /api/resistance | GET | Returns current resistance setting of the pedals |
| /api/resistance | PUT | Sets current resistance setting of the pedals |
| /api/debug | GET | Returns current debug state (True/False) as defined by the service configuration |
| /api/debug/serial | PUT | Sends a serial message to Holoseat (returns result as JSON string or status 401 not authorized if debug state is false) |
The JSON format for an action is show below for the default forward action (hold down the 'w' key down on a keyboard)
{
"device": "keyboard",
"input": 'w',
"command": "hold",
"end": "release"
}
The default settings for the Holoseat are those settings which are persisted in non-volatile memory. They represent the most generic use case for the Holoseat and as such make a number of assumptions about the default actions associated with pedaling forward and backward.
Specifically, the default settings assume the only device being emulated is a keyboard, with a command/end pairing of hold/release for both the forward and backward actions. Further, the default settings assume there are no sprint actions. These assumptions leave the following minimum set of default settings.
{
"enabled": "True",
"stepsize": 2,
"forward": 'w',
"reverse": 's'
}
Note, the default settings are written to the Holoseat controller’s EEPROM which has an expected life of approximately 100,000 write operations. While this should allow for more than sufficient lifespan for the Holoseat controller, we still want to take precautions to avoid malicious code burning through the available write operations. To that end, the POST method on /api/defaults will be protected to only support calls from the application GUI. Additionally, there will be a minimum 5 second timeout that must elapse between calls to update the default settings.
Below is a list of questions and proposed answers to help us narrow down the requirements for this project.
A1. The Holoseat is a video gaming accessory which uses the drive to play video games to encourage regular exercise. It accomplishes this by coupling exercise directly into the video game experience. It should be functional enough to support initial sales to end users as both a kit and finished product.
A2. PC based video game players who play games which involve character movement in 3rd or 1st person (role playing games, massively multiplayer role playing games, first person shooters, etc).
A3. Players attach the Holoseat interface to a recumbent exercise bike or elliptical machine and to a computer. The Holoseat interface then detects the motion from the exercise equipment and sends the appropriate keystrokes for walking (or other locomotion) to the computer. In this way, players must use the exercise equipment as part of the game experience.
A4. The Holoseat needs to support the following features to be sellable:
A5. Later versions of the Holoseat may have the following features:
A6. None - still in early prototyping phase, new versions can completely replace current version(s).
A7. The Holoseat will be offered as both a kit and a completed product. The kit version will be built by gamers and makers. The complete product will be built by Holoseat staff.
A8. Eventually, one for every gaming PC and console on the planet. For now, it will be built in limited batches (one and two at a time). Development will include a series of prototypes leading to an initial production version optimized for assembly by makers as a kit.
A9. As controllers cost between $35 and $50. The kit should be in the same level of price, which with a 2.6 times mark up means material costs for the Holoseat parts should be between $14 and $20. Budget for prototyping should cover several generations of prototypes and account for non-production components, giving a development budget of $300.
A10. The second generation prototype needs to be completed before the end of 2013. Kit prototypes should be complete by the end of Q2 2014.
TBD
TBD
J. is investigating how to automate the test rig to minimize user induced error during sensor comparison tests and later performance tests. This plan was inspired by working with Nodebots.
Holoseat supports any game which uses wasd control schemes. Pedal forward to use 'w' actions and pedal backwards to use 's' actions. In both cases simply stop pedaling to stop the current action.
Welcome to the Holoseat. We hope it serves you as well as it has our development team (yes, we really use it). Please be sure share your experience online.
The Operating Manual covers the set up and use of the Holoseat. It starts with the steps needed to prepare the Holoseat for first time use. It then moves on to how to use the Holoseat hardware while playing your games, followed by instructions for the desktop configuration app. Finally, the Operating Manual closes with some troubleshooting steps.
There are two physical components to the Holoseat: the sensors which are attached to your exercise pedals and the controller which is connected to the sensors and your computer.
As you will see, using the Holoseat in game in intuitive and only takes a few minutes to learn. Once you are in a game which uses keyboard controls to control motion (e.g. wasd) all you have to do to use the Holoseat is pedal to move and stop pedaling to stop.
If you pedal forward your character will walk forward. If you pedal backwards, your character will walk backwards. Holoseat currently supports to walking speeds: single step and continuous walking. To single step, simply pedal one rotation (either forwards or backwards). To walk continuously (forward or backward), you need to pedal at or above your trigger cadence (controlled in the desktop configuration app). While you are pedaling you will see the sensor lights blink off as you pedal past each sensor. This behavior indicates the sensor recognizes your pedal activity. If you do not see the lights blink off adjust the magnet/sensor placement until you do.
The Holoseat can be disabled so you can use the pedals without triggering keystrokes during non-gaming activities. Press the green Enable button on the Holoseat controller to disable or enable Holoseat. The Enable button will be lit when Holoseat is enabled and unlit when it is disabled. Note, you can also disable/enable Holoseat from the desktop configuration app.
The desktop configuration app resides in the Windows system tray. Start it by running Documents\Holoseat\HoloseatConfigurationUtility\HoloseatConfig.exe. Then bring up the user interface by clicking the 'h' icon in the system tray.
You can use the desktop configuration app to make live updates to Holoseat's settings (these changes are not preserved when Holoseat loses power, e.g. when it is unplugged) and to update its default settings (these changes are preserved when Holoseat loses power). Before using the configuration app, ensure the Serial Port is set correctly (it usually finds the correct port) and the Hardware select box is set to feather.
You can control four settings in the desktop configuration app.
To push your changes as live updates, click the Update Holoseat button. To push your changes as updates to the default values, click the Update Defaults button. Note, updating defaults requires installation and configuration of the Arduino IDE. See Software Setup page for more details (be sure to specify the path to your Arduino IDE installation in Arduino Path field).
There are a couple of things to try when your character is not walking.
This issue is usually caused by improper configuration of the Holoseat. You should adjust the resistance on your pedals so it is neither too easy nor too hard. Then adjust your cadence in the desktop configuration app until walking works naturally. You may need to adjust these settings from time to time as you build up your strength.
This issue is usually caused by improper configuration of the Holoseat. You should adjust the resistance on your pedals so it is neither too easy nor too hard. Then adjust your cadence in the desktop configuration app until walking works naturally. You may need to adjust these settings from time to time as you build up your strength.
__init__.py
__main__.py
Proposed connectivity (chosen to place supply voltage on TRRS tip).
| Sensor Pin | Function | TRRS Jack Postion | Arduino Pin |
| 1 | Supply Voltage | Tip | 3.3v |
| 2 | Direction | Ring 1 | 2 |
| 3 | Speed | Ring 2 | 3 |
| 4 | Ground | Sleeve | GND |
Holoseat uses two boards: the Controller (an Adafruit Feather 32u4 Basic Proto running the Holoseat firmware) and the Sensor Board (a custom board to connect the sensors to a Cat5 jack so the sensors can be mounted on the exercise pedals and the Controller can be close to the user, typically next to the user's keyboard). For the current version, the boards are built from proto-boards, so there are no Holoseat specific PCBs. Later versions will migrate to Holoseat specific PCBs.
The Holoseat Controller electronics are simple enough to fit onto the prototyping area of the Adafruit Feather 32u4 Basic Proto. The key components are the Cat5 jack and an LED push button (HS008). The Cat5 jack is connected to pins 2 and 3 (for reading interrupts from the two Hall effect sensors), ground, and the USB power (to provide 5v to the sensors). The LED push button is treated as a separate button and LED. The button portion is connected to pin 10 and uses the Feather's internal pull-up resistor. Finally, the LED portion is connected to pin 13 (per the Arduino Blink tutorial).
The Sensor Board electronics are built on a perfboard. The key components are the Cat5 jack and two sensor/LED modules. The Cat5 jack is used to connect the sensors to the Controller board using a Cat5e cable. The sensor/LED modules are composed of an OH090U Hall Effect Sensor (HS004) and a Diffused Blue 3mm LED (HS005). The LED is wired directly to the sensor to provide low level diagnostic information without using the Controller. As long as the sensor is receiving power and is untriggered (that is no magnet is within sensing range) the LED will be lit. The LED will turn off when the sensor is triggered by a magnet indicating the sensor is working correctly. Note, the sensors have a polarity like magnets and will only be triggered by a magnet if the correct pole is facing the sensor.
Design work is currently being done in Fritzing. | Fritzing Source Files
HS-04: Wheel Speed Sensor Module
Note: The final build requires (2) HS-03: 18 Pole Tone Ring Halves as detailed in Step 6.
HS-03: 18 Pole Tone Ring Half
Note: You will need (2) in progress HS-03: 18 Pole Tone Ring Halves for testing
Note: You will need (2) in progress HS-03: 18 Pole Tone Ring Halves which going forward will be considered a complete set
As the Holoseat only controls locomotion, you will need to use a keyboard or a controller for other inputs. One of the Holoseat developers prefers to play games on a recumbent exercise bike, and in turn uses a controller. For PC games, he uses JoyToKey to map an XBox 360 Wired controller to keystrokes. Below are the configuration files for the games he has played using the Holoseat.
To use these files, download and unzip JoyToKey, then download the cfg file(s) for the game in question to the JoyToKey executable directory. The next time you run JoyToKey (note, the JoyToKey developer recommends running JoyToKey as an administrator), the configuration(s) you downloaded will be listed. Simply select the one matching the game you want to play and things should be ready to go. Browse the key mappings in JoyToKey to see how the controller has been configured. Note, the walk command (w) is not mapped in these config files as the Holoseat will provide this input.
These instructions cover the software set up of a newly built Holoseat controller. There are three pieces of software required to configure and use the Holoseat: the Arduino IDE, the Holoseat controller firmware, and the desktop configuration app.
Note, these steps are for Windows (tested on Windows 7). The process is similar on other platforms, but the desktop configuration app only runs on Windows for v0.3. Future versions will support other platforms.
https://adafruit.github.io/arduino-board-index/package_adafruit_index.json to the Additional Boards Manager URLs fieldThe desktop configuration app does not currently require any installation steps. You can run it directly from Documents\Holoseat\HoloseatConfigurationUtility
The Holoseat project has three software elements. The first software element is the firmware running on the Holoseat controller. The second software element is the desktop configuration app. And the third software element is the test rig software (composed of more firmware and test execution software). This page covers each of these elements and the serial protocol between the Holoseat controller and the desktop configuration app.
The Holoseat controller firmware can be found in the SVN Repository. It runs on an Adafruit Feather and relies on the Bounce2 library for button debouncing. Its function is to detect pedal events from the sensor, use the timing of those events to determine the cadence (in RPM) and direction (forward or backward), and then send the walk command (generally by pressing the 'w' or 's' key) when the pedal speed is greater than the specified trigger cadence.
The default parameters for the firmware are stored in the holoseat_constants.h file so they will be available at start up without the need for a connection to the desktop configuration app. The following parameters have default values in the constants file.
The Holoseat configuration app can be found in the SVN Repository. It is written in C# and runs in the Windows System Tray (other operating systems will be supported in future releases). The configuration app requires a locally installed copy of the Arduino IDE to update the default parameters in the Holoseat controller and uses the SerialPortStream 2.0 library to manage the serial communications with the Holoseat controller for live updates to the Holoseat settings. Its function is to display and modify current settings for the Holoseat and allow users to update the default values for those settings.
The configuration app modifies the default parameters by updating the values of the corresponding constants in holoseat_constants.h and then flashing updated firmware to the Holoseat controller. It is the need to flash the controller with updated firmware that drives the need for a local installation of the Arduino IDE. If it is not present, the configuration app disables this feature.
The configuration app uses the Holoseat Serial Protocol (see below) to display and update the current settings. These settings will remain in the Holoseat controller until they are changed again using the configuration app or the Holoseat loses power (e.g. when unplugged or the host computer is shutdown). At which point, the Holoseat reverts to its default parameter values when next used.
The test rig software can be found in the SVN Repository. The test rig was developed to support research into the sensor and magnet pairing. It is made up of an Arduino Uno driving a stepper motor. The stepper motor has an arm attached to it with magnets on the end to simulate users pedaling. Finally, a Raspberry Pi runs the tests and hosts the sensors under test, receiving signals from the magnets attached to the stepper motor as it turns. A test case includes a magnet, a sensor, and a simulated pedaling cadence.
The test rig software is made up of two components:
The test rig firmware uses AccelStepper v1.45 to implement an open loop controller on the test rig's stepper motor. This controller drives the stepper motor at a specified cadence (in rpm). The cadence is specified as an integer on the serial port.
The test scripts use the Johnny-Five library to connect to the peripherals required for the test. The first peripheral is the Arduino running the stepper motor controller (over serial port). The second peripheral is the sensor under test (over a GPIO port). Tests are defined first in a csv file. The generate-test-files.js script converts the csv file listing all of the desired tests into a set of JSON files, each defining a single test. The scripts run-char-tests.js and run-doe-test.js implement two testing patterns (characterization and Design of Experiments, respectively). These scripts parse a test definition JSON file and write out test results in a csv time history file. The set-cadence.js script is a command line tool to set the stepper motor cadence (used before and after tests to start and stop the stepper motor). The remaining scripts are demonstration tools to verify code was functional before being integrated into the test execution scripts.
Note: This documentation is deprecated for v0.4.0+. See HSP page for updated documentation.
The HoloSeat firmware has a serial protocol, the Holoseat Serial Protocol (HSP), to enable the desktop configuration app to modify all key parameters and to determine the current configuration of the Holoseat at runtime.
The HSP supports three commands. Each command is made up of a single upper case character indicating the statement type. One command, the (S)et statement, also takes an input string.
? - Ready(?) command; used to determine if the HoloSeat is ready to receive commands over the HSP (will reply with the (R)eady message followed by one standard state message if the HoloSeat is ready)S <config string> - (S)et command; used to send updated configuration to HoloSeat (HoloSeat will reply with OK on success). The config string has the following format:<WFC>,<WBC>,<E>,<TC>,<L>,<LI> - example: S w,s,0,60,0,20
<WFC> - Walk forward character (example: w)<WBC> - Walk backward character (example: s)<E> - Enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<TC> - Trigger cadence (example: 65)<L> - Logging enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<LI> - Logging interval in deci-seconds (example: 10)Q - (Q)uery command; used to request the HoloSeat send one standard state message (see Protocol Messages below)The HSP has two messages. One is a single character message similar to the commands and one is the HSP standard state message which is sent after initialization, in reply to a (Q)uery command, and as the serial logging message.
R - (R)eady; sent by the HoloSeat to indicate it is ready for serial communication; sent in reply to the Ready(?) command and when serial port is attached in debug mode (to be added)<VER>,<WFC>(<DWFC>),<WBC>(<DWBC>),<E>(<DE>),<C>/<TC>(<DTC>),<L>(<DL>)/<LI>(<DLI>) - standard state message, see below for key; example: 1.2.3,w(w),s(s),1(1),70/65(75),1(0)/10(10)
<VER> - Firmware version string (example: 1.2.3)<WFC> - Walk forward character (example: w)<DWFC> - Default walk forward character (example: w)<WBC> - Walk backward character (example: s)<DWBC> - Default walk backward character (example: s)<E> - Enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<DE> - Default enabled state, same format as <E> (example: 1)<C> - Current cadence rounded to whole number; positive value means direction is forward, negative value means direction is backward (example: 70)<TC> - Trigger cadence (example: 65)<DTC> - Default trigger cadence (example: 75)<L> - Logging enabled? Must be a 0 (disabled) or a 1 (enabled) (example: 1)<DL> - Default logging enabled, same format as <L> (example: 0)<LI> - Logging interval in deci-seconds (example: 10)<DLI> - Default logging interval in deci-seconds (example: 10)Always start a serial session by sending a Ready(?) command. If a (R)eady message is not received, wait and try again until a timeout is reached or a (R)eady message is received. Be sure to check the version string sent in the initial standard state message to ensure your app is compatible with the version of the HoloSeat firmware.
After you have initialized your connection, you can then use the (Set) and (Q)uery commands as necessary to control and observe the HoloSeat's state.
Hackaday on "turning an electronic project into a marketable kit"
Detailed testing notes will go here.
HS-03: 18 Pole Tone Ring
Welcome to the Holoseat. We hope it serves you as well as it has our development team (yes, we really use it). Please be sure share your experience online.
The User's Guide covers the set up and use of the Holoseat. It starts with the steps needed to prepare the Holoseat for first time use (First Time Setup). It then moves on to how to use the Holoseat hardware while playing your games (Operating Instructions). If you have questions, please reach out to us on our Support Forums.
#ExerfyYourGames
Initial prototype - This is the proof of concept for the Holoseat. It uses a USB Keyboard controller board, an Arduino Uno, and a reed switch (which replaced a homemade rotary encoder). It has been in use for 8 months with few problems. It will be replaced with a simpler v0.2 prototype which will replace the USB keyboard controller and Arduino Uno with an Arduino Leonardo.
Pre-production prototype - this version of the Holoseat will work out the kinks from v0.1 and add user convenience features. In particular, it will use a simplified design (an Arduino Leonardo in place of both the Arduino Uno and the USB Keyboard controller) and implement the remainder of the required features. These include:
I hate exercise. It really just doesn't do anything for me (well, except keep me healthy). And I love video games. Especially role playing games like Mass Effect, Fallout, and now MMOs like Star Wars The Old Republic. Of course, what my life really needs is more time spend sitting on my couch or at my desk.
Sound familiar? If so, you should check out my latest project: the Holoseat. Think of it as the smallest precursor to the Enterprise's holodeck and Deep Space Nine's holosuite. Inspired by the now defunct Excite Bike (later renamed PedalSense), the Holoseat takes the idea of exercise bike as controller beyond sports games and into all game genres including role playing, first person shooters, and platfomers. It also does away with the need to hack your XBox controller, instead opting for keyboard emulation on PCs. The Holoseat uses an Ardunino Leonardo to measure pedal rates (like your bike computer does) and to send the appropriate keyboard commands for walking to your PC when you are pedaling fast enough.
Take a look at the the video below to get an idea of how it works. Note, this is from the very first working prototype, and all of the performance bugs you see have been addressed in the current version.
Oh, and want to know if it works? Well, since completing the second generation prototype, and subscribing to Star Wars The Old Republic 8 months ago, I have lost nearly 40 lbs. Of course, I am also eating better, but there is a noticeable difference in my weight loss when I am home playing my game 5-7 nights a week versus when I am on business trips and have to ride a regular exercise bike which I only manage to do a couple times a week. Clearly, your mileage may vary, but the Holoseat has been a life changer for me.
Which is why I am releasing it as open source hardware. Once the third version is complete, I will also be launching a Kickstarter to fund the initial round of production hardware (both kits and finished versions). Watch the News feed for more details.
Proudly built at Dayton Diode, Dayton's Makerspace
Improved Prototype - this version of the Holoseat will apply lessons learned from the previous versions and work to make the Holoseat more robust in preparation for a production prototype. In particular, it will look into the use of Hall effect sensors in place of the reed switch and it will investigate the use of a desktop application to interact with the Holoseat to adjust the configuration and get feedback from the Holoseat controller. Specific development will include:
Items marked with a strike through were dropped in favor of completing v0.3 in time for SyndCon 2016.
Production prototype - The goal for the production prototype is to develop a unit suitable for the first crowd source campaign (closed beta). Details to follow.
The CHIP Pro is the main board for the Holoseat controller. It is produced by Next Thing Computing (NTC).
The Feather is the HID USB board for the Holoseat controller. It is produced by Adafruit.
The "TLE4966":Speed & Direction Sensor TLE4966 is the proposed sensor package for Holoseat. It is produced by Infineon. It comes in a number of form factors, listed below.
| hw | Hardware | The physical components of Holoseat which are encumbered with version related compatibility concerns |
| sw | Software | The user application and the REST API |
| fw | Firmware | The code running on the controller itself interacting with the sensors and the game |
| Product | Major | Minor | Patch | |
| hw | Determined by USB VID/PID | Identified in hardware by version resistor | Not Used | Identified by physical markings |
| sw | Identified by string constant | Identified by string constant of form Major.Minor.Patch | ||
| fw | Identified by string constant | Identified by string constant of form Major.Minor.Patch | ||
| v0.1 | Description | Documentation |
| v0.2 | Description | Documentation |
| v0.3.1 (certified OSHW- US000058) | Description | Documentation |
| v0.4 | Description | Documentation |
Welcome to the Holoseat Wiki. Holoseat is a gaming peripheral for PCs (it works with Windows, Mac OS, and Linux) that turns your video games into workouts. Every step you take in your game is driven by pedaling in the real world. Using Holoseat is an immersive experience (players pedal faster when their characters are in danger) and invisible. This combination masks the exercise experience in game play, transforming exercise from a chore into a natural part of a gamer's day. In short, Holoseat exerfies your games!
Holoseat is an open source hardware project (v0.3 is certified as open source by OSHWA) and all aspects of its development are managed on Open Design Engine. As an open source hardware project, you have access to all of the design details of Holoseat and can participate in any manner you want. Do you want to follow along with the development team until we release the first commercial version? Great, check out the Want to learn more? section. Do you just have to have a Holoseat of your own right now? No problem, check out the Want to build your own? section. Do you have an idea for how to improve Holoseat? Do you want to help us bring Holoseat to market (this includes technical and business development work)? Awesome! Check out the Want to join the Holoseat team? section.
No matter what brought you here today, be sure to sign up for our newsletter to stay up to date on our journey toward 1.0 and our first commercial release.
So, you want to learn more about Holoseat? First, have you signed up for our newsletter? If not, follow the link and sign up. Our newsletter comes out between each of our development cycles, or sprints (roughly every 8 weeks) and covers our last sprint (what we planned and what we did) and next sprint (what we are planning to do).
Want to know how to use Holoseat? Check out our home page for an infographic summarizing how Holoseat works. Looking for more details, check out the Operating Manual. If you want to know a little about the science behind Holoseat, check out this blog post.
Finally, if you are looking for the technical details of Holoseat, take a look at the Design Data. The Block Diagram documents the Holoseat system architecture (what are the components of the Holoseat and how do they relate to their environment?). The Schematics and PCB Files covers the design of the electronic components of Holoseat (the controller and sensor boards). And the Project Software describes each of the software elements of the Holoseat project and how they work.
So, you want to build your own Holoseat? You're in luck. As an open source hardware project, all of the plans and assembly instructions for Holoseat are published here on Open Design Engine. Just check out the Assembly Information links in the navigation bar on the right. The Bill of Materials lists all of the materials required to build the Holoseat electronics (you still need to BYOP - Bring Your Own Pedals - don't have a set, we recommend DeskCycle if you prefer peddles or FitDesk for elliptical). Then just follow the Assembly Instructions and the Software Set Up and you will have your very own Holoseat.
So, you want to join our team and help us get to market faster? Step one is to sign up for an account on Open Design Engine. Step two is to introduce yourself on the forums. We welcome any and all comers. Found a bug? Report it. Have an idea? Share it on the forums. Want to help with the development? Let us know on the forums and we will include you in our weekly meetings and development cycle. Want to help on the business side? Again let us know on the forums and we will be in touch about how we can work together. What are you waiting for? Sign up and introduce yourself!
