Collar

What is it?

• A bondage collar that can be controlled remotely, or can run a scenario autonomously.
  • This may include both "carrot" and "stick" mechanisms for eliciting compliance from the wearer.
    • Carrots may include rewards such as vibration play, or audio stimuli.
    • Sticks may include electric shock, or body autonomy denial through estim across muscle groups. Or other forms of punishment.
  • Allow for the device to be taken control of by casual users, or by a remote control operator.
    • Rendering a QR code on the display would allow for "pickup".
    • The control app could also be used to locate the device.

Device Architecture

Objectives for the device architecture are:

• Must fit core functionality into the smallest area possible
• Modest runtime from a single 18650 cell
• Must be kept as open as possible for future development by 3rd parties/clones
• Must be prepared to replace components as they become obsolete/unavailable
• Must have netplay connectivity for remote control
• Must run a high-level interpreted language so that end users can create scenarios.
• Must have a local interface that allows for configuration of the device.
• Must integrate with existing bluetooth devices as a controller itself
• Must report what devices are attached to the collar over the CANBUS interface to the control plane/remote control app.

Some devices are on a shared bus: ESP32-C3, Accelerometer, PMIC and QWIIC expansion interface. The CANBUS transciever and OLED display are on a separate Realtime-Only SPI bus. This is due to the potential for contention between ESP-Hosted talking to the Application Processor while the Realtime Processor is trying to update the display.

Software Architecture

The main application processor runs a high-level interpreted language, which is used to run scenarios.

Each stage of the scenario is a state machine which can be entered and exited by programmed criteria. Each state machine is fed to the microcontroller for it to wait until exit states are reached.

The microcontroller is responsible for managing the hardware, and for managing the stick&carrot functionality.

While the Microcontroller is in charge, the main application processor can go offline. Upon state machine completion, the main processor is brought back online to report the results of the scenario to the remote control plane and populate the next state machine into the microcontroller.

The shared ESP32 is used to provide network and bluetooth connectivity. This may be handled by either the Application Processor or the Microcontroller. The ESP32 runs the ESP-hosted-FG firmware. This system can be handed over to either the Application Processor or the Microcontroller as needed. Ultimately the Microcontroller might end up having full control over it and relay requests sent to it via its UART interface. The handover would be a case of the Microcontroller and Application Processor agreeing who should be in control and then power-cycling the ESP32 via the PMIC's power control rails.

Example Scenarios:

"Go to your room"

Collaree is being controlled by a remote operator, who is instructing the collaree to go to a specific location at specific times.

E.g encouraging specific behaviour while punishing non-compliance.

The accelerometer could be used to determine if the collaree is laying or sitting or otherwise following instructions.

"This is, infact, a trap"

Collaree is at an event, the collar is configured to be running "freeplay" mode, where another user could take control of the Collar and become the local controller. Collar is now holding the collaree hostage, forcing compliance from both collaree and local controller. Collar requires movement to a specific location, perhaps a specific hotel room, lest the collaree be punished, leading to the collaree imploring the local controller to comply.

Collar requires certain evidence of activity to be posted into a chatroom, or to the remote controller. This could be implemented as looking for a specific emoji reaction to an image in a chat channel.