legop3/MultiRoombaRover
1
0
Fork 0
mirror of https://github.com/legop3/MultiRoombaRover.git synced 2026-09-15 17:12:59 -04:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

docs stub

Browse Source
This commit is contained in:
legop3
2026-02-11 02:32:38 -05:00
parent 0c3b3aa711
commit dcf7208c08
27 changed files with 4 additions and 868 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+4 -86
View File
@@ -1,89 +1,7 @@
# Multi Roomba Rover
A system for controlling create 2 compatible roombas through a webpage.
a remake of my RoombaRover project with a decentralized and embedded approach
supports multiple roombas
Docs coming "soon"
on each roomba:
- a raspberry pi zero 2 w
- a raspberry pi camera
- roomba's serial port hooked up to the built in serial port on the raspberry pi
pi provisioning:
- enable serial port
- disable wifi powersave
- disable bluetooth
## Repo layout
- `pi/roverd`: tiny Go daemon that bridges the Create 2 serial port, BRC pin, and the control server via WebSockets.
- `server`: Node.js process that terminates rover sockets, relays commands to/from the Socket.IO UI, and serves `public/`.
- `pi/bin` / `pi/systemd`: helper scripts + systemd units for the rover (roverd itself plus the SRT video publisher that streams camera feeds to the server).
- `docs/pi-deployment.md`: per-rover build + install instructions (cross-compiling on Fedora 43, deploying roverd + mediaMTX).
## Quick start
```bash
# build the Pi agent (armv7)
cd pi/roverd
mkdir -p ../../dist
make pi-build
# start the server + UI
cd ../../server
npm install
npm run start
```
Need a fake rover or multi-rover testing without hardware? Use the dummy build:
```bash
cd pi/roverd
mkdir -p ../../dist
make dummy
./../../dist/roverd-dummy -config ./roverd.sample.yaml
```
The dummy binary connects to the Node server, emits simulated sensor frames, and logs every command it receives, so you can spin up as many virtual rovers as you’d like on your dev machine.
## Admin config & authentication
Before running the Node server, copy `server/config.example.yaml` to `server/config.yaml` and customize the admin records (password hashes, Discord IDs, lockdown permission). Those credentials are used by the driver UI’s login panel—only admins can toggle locks/modes, and lockdown admins retain access when the system enters lockdown mode. The spectator page (future) can set `role:set` to `spectator`, and the server enforces all permissions server-side so client tweaks can’t grant extra control.
Deploy a rover by copying the repo + `dist/roverd` to the Pi and running the helper (it installs roverd plus the SRT video publisher service):
```bash
cd ~/MultiRoombaRover
sudo ./pi/install_roverd.sh
```
Then point each rover's `/etc/roverd.yaml` at `ws://<server>:8080/rover`, set `name` to the rover’s ID, and (optionally) override `media.publishUrl` if your control server isn’t `192.168.0.86`. The video publisher service (`video-publisher.service`) captures the Pi camera with `rpicam-vid`/`libcamera-vid`, pipes the raw H264 into the stock FFmpeg binary, and publishes via SRT to the server’s mediaMTX instance at `srt://<server>:9000?streamid=#!::r=<name>,m=publish`. The installer now just pulls `libcamera-apps` + `ffmpeg` from apt (no custom build). Use the “Restart Camera” button if you enable media management so roverd can bounce the publisher service remotely.
Heads-up: the BRC pulser now uses libgpiod; make sure the `roverd` service account is in the `gpio` group (or otherwise allowed to access `/dev/gpiochip*`) and set `brc.gpioChip` if your hardware exposes a different chip name.
## Fedora server deployment
Run the installer from inside the `server/` directory after cloning the repo onto your Fedora 43 Server box:
```bash
cd ~/MultiRoombaRover/server
sudo ./install_server.sh
```
The script must be executed via `sudo` from the user that owns the repo. It will:
- install Node.js/npm plus curl/tar
- run `npm install --production`
- copy `config.example.yaml` to `config.yaml` if needed (edit the file afterwards for admins + `media.whepBaseUrl`)
- download mediaMTX v1.15.3 and drop it into `/usr/local/bin`
- write `/etc/mediamtx/mediamtx.yml` from `server/mediamtx/mediamtx.yml` (SRT ingest on :9000, open ingest, viewer auth webhook at `/mediamtx/auth`)
- create + enable `mediamtx.service` and `multirover.service`, both running as your repo user and pointing at the clone directly
Publishing rovers lives on a trusted network, so the shipped config (tracked at `server/mediamtx/mediamtx.yml`) skips HTTP auth for SRT ingest and whitelists any path that matches `rover-*`. The installer overwrites `/etc/mediamtx/mediamtx.yml` every time you run it—if you need to tweak ports or add TURN servers, edit the template in the repo and rerun `install_server.sh` so every box stays in sync automatically.
Once finished, update `server/config.yaml` with your admin passwords and `media.whepBaseUrl` (set it to the URL you expose publicly, e.g. `https://rover.otter.land/video`). If your proxy can’t rewrite paths, create the `/video` location there and add a custom nginx snippet to rewrite `/video/<rover>/whep` to `/<>/whep` before forwarding to mediaMTX. Restart `multirover.service` whenever you edit the config. To pull updates later, just `git pull`, re-run `npm install --production` inside `server/`, and restart the service—no need to rerun the installer.
Room cameras now use JPEG snapshots (4 fps) instead of WHEP. Each entry in `roomCameras` must include a `url` pointing at the snapshot endpoint; the server polls and relays frames over socket.io with the same access rules as before.
### Video handshake + diagnostics
- Every `video:request` returns `{ url, token }`. The browser posts the SDP offer to `url` and includes `Authorization: Basic base64(token:token)`. mediaMTX forwards the username (`token`) to `/mediamtx/auth`, which checks the socket’s permissions (driver assignment, admin/spectator role, lockdown state) and either returns 200 or 401—no query parameters are involved anymore.
- To see what mediaMTX is ingesting from the Pis, run `npm run check:media` (or `node scripts/checkMedia.js`). It hits `/v3/paths/list` and prints each rover’s `ready` state and byte counters so you can instantly spot publish issues.
## Basic installation
-
plans/audio_on_roomba_outline.md
-27
View File
@@ -1,27 +0,0 @@
# general idea
- the pi on each roomba will have a speaker and microphone
- alsa devices
- they are both the default audio device
- you will have to modify roverd, the pi install script, and the server to get this all to work
# adding stuff to installation script
- I am using the google voice AIY v1 kits for audio
- boot config stuff
- enable `dtoverlay=googlevoicehat-soundcard`
- disable `dtparam=audio=on`
- copy asound.conf in pi folder to /etc/asound.conf
# microphone
- add microphone to the SRT publish stream
# speaker
- user's chat messages will be TTS'ed through the speaker on the pi
- either flite with a way to choose the voice
- or espeak where you can choose the pitch
- on the web UI and in the chat API
- add new stuff to chat
- only shows up if you are on a rover
- only shows up if TTS is enabled on that rover
- people can choose between flite or espeak
- if they choose flite, they can choose the voice from the default flite voices (exclude awb and awb_time)
- if they choose espeak, they can choose the pitch. Have a dropdown with increments of 10 from 0 to 99
plans/authentication_and_access_control.md
-33
View File
@@ -1,33 +0,0 @@
# access control modes:
- open
- open to the public
- users are randomly assigned a rover to drive, with priority on the rover with the least amount of drivers
- if there are multiple people on one rover, those people will all be controlling that rover at the same time
- turns
- open to the public
- users are randomly assigned to a rover same as open mode
- if there are multiple people on one rover, they will each have one minute at a time to drive.
- the turn queue loops
- the rover will stop moving and stop all aux. motors if the turn switches to a different person
- admin
- admin authentication is required to access the driver page at all
- lockdown
- ONLY lockdown admins can access the driver page
- the future spectator page is DISABLED (not even a way to log into it)
# roles in the access control system:
- user
- default, for normal people who visit the site
- admin
- authentication needed
- can drive and view any rover when not on lockdown, no matter who is controlling it
- can switch modes (including switching to lockdown mode)
- lockdown admin
- authentication needed
- only works if said admin has lockdown: enabled in config
- can ALWAYS access and control EVERYTHING that there is to do on the site
# other things to keep in mind:
- in the future, there will be a Discord bot for community alerts and a few admin controls
- wherever the admin list is configured, there has to be a spot for their discord ID
- admin's discord IDs are linked to their admin name server-side
plans/battery_manager_outline.md
-27
View File
@@ -1,27 +0,0 @@
# general idea
- uses the rover's reported battery full, warn, and urgent values
- will apply to all rovers individually
- uses the rover locking system
- completely server side
- always use the battery warn value as 0% battery and the full value as 100%
## first: the server-side server-wide event bus
- global server event bus
- used for realtime alerts between modules
- includes a way to tell where the event is coming from
## what will the battery manager do?
- watch each rover's battery charge number (reported in sensors)
- if the number reaches warn, fire an event on the event bus
- the UI will show a warning to users, independently based on sensor data
- once the rover is docked and charging, lock it.
- when the battery is fully charged, unlock it.
## while we're at it...
- add a lock reason to the rover locking system
- add the following to the rover roster in the UI session state:
- battery full #
- battery warn #
- battery urgent #
- in the rover roster UI component, add a display for battery percentage and lock reason.
- make the rover's background red when locked
plans/battle_mode.md
-9
View File
@@ -1,9 +0,0 @@
# general idea
- IR led on the front of each roomba
- connected to a pin on the pi
- made to be very directional
- each roomba has a different IR code
- use the omni reciever to get a shot
- keep score per user
- use the go alert system
- alert discord with a live score count
plans/discord_bot_outline.md
-35
View File
@@ -1,35 +0,0 @@
# general idea
- discord bot run by the server
- use discord.js
- don't use discord's slash commands
- listen for commands the old fashioned way
- only admins with IDs set in the server config can use commands
- use nice looking embeds with colors for everything but messages
# features
## admin server management commands
- admins can lock and unlock rovers from discord
- admins can change the server access control mode
## announcements
- the bot has an announcements channel assigned in the server config. It will also have an announcement role ID to optionally ping. it will announce:
- when a rover is locked / unlocked (no ping)
- when the server access mode is changed (ping)
- the bot will have an admin ping role and alert channel. in here will be:
- rover activity (no pings)
- docking
- charging
- stopping charging
- undocking
- rover alerts (ping)
- rover comes online
- rover goes offline
- rover is at warn battery
- rover is at urgent battery
## chat bridge
- bridge between the server chat and discord chat
- use chat events that are on the bus already
plans/home_assistant_controls_outline.md
-15
View File
@@ -1,15 +0,0 @@
# general idea:
- control on / off switches and lights in home assistant from the web UI
- use this:
- https://www.npmjs.com/package/home-assistant-js-websocket/v/3.1.2
- remember to ignore updates that are of the same states, this library will give you a lot of those
- switches and lights are configured in the server's config file
- give each one a name (no description)
- auto detect a switch type or light type
- deliver list of lights to the UI through the session service
- show realtime on/off status of the switches / lights in the UI
- create a react component for the controls
- it will automatically create a control for each switch / light
## permissions:
- even if someone isnt assigned to a rover, they should be able to control the switches / lights
plans/led_night_vision_toggle_outline.md
-13
View File
@@ -1,13 +0,0 @@
# general idea
- The idea of this feature is to toggle night vision on the camera by turning on an LED from GPIO on the pi which will me mounted in front of the camera's light sensor
- with this, the camera will disable night vision when the LED is ON, and enable night vision when the LED is OFF.
- this will only really involve pi and webui programming. the server passes commands straight through.
- do not track the state of night vision, it is not needed.
## pi side
- new GPIO on/off control on GPIO 17, 27, or 22. any of these will work.
## web UI
- a new keyboard shortcut to toggle night vision
- a new button in the mobile UI to toggle night vision
- put it above the mobile horizontal servo slider
plans/mini_summary_view_outline.md
-6
View File
@@ -1,6 +0,0 @@
## general idea
- new page
- designed for a very small screen
- not interactive at all
- a small summarized status of what's going on in the basement (where the rovers are)
- this small screen does not have space to show all info and all video for all rovers
plans/new_help_system_outline.md
-21
View File
@@ -1,21 +0,0 @@
# general idea
- a help system that pops up onscreen
- changes based on control layout
- mobile / desktop
- on desktop especially, keybinds will dynamically update, based on what is actually assigned
# UI layout specifics:
- remake the current help component from scratch
- leave it in the place where it is, so people can always look at the help
- match the styling of the rest of the page
- make sure the help is easy to edit
- add a pop-up which displays underneath any other popup layers, which will display the help component in a large format
- make this pop-up show every time UNLESS the user checks "dont show again"
- use the settings system to store this in the browser
# what will the help explain?
- how to use the nickname and chat
- how to start driving the rover
- rover controls
- this is the biggest thing that will change in different layouts
- how it works technically (just a placeholder for now)
plans/new_video_pipeline.md
-36
View File
@@ -1,36 +0,0 @@
# Video flow (SRT ingest, WHEP playback)
1. **Raspberry Pi Zero 2 W**
- `pi/bin/video-publisher.sh` captures the CSI camera with `rpicam-vid`/`libcamera-vid` using the onboard H.264 encoder (`--inline --profile baseline --bitrate …`).
- The Annex-B stream is piped into the stock FFmpeg package and pushed to the control server over SRT as MPEG‑TS: `ffmpeg -f h264 -i - -c copy -f mpegts "srt://<server>:9000?streamid=#!::r=rover-alpha,m=publish&latency=20&mode=caller&transtype=live&pkt_size=1316"`.
- Configuration lives in `/var/lib/roverd/video.env` (`PUBLISH_URL`, resolution, FPS, bitrate). `roverd` rewrites this file whenever the rover config changes, so onboarding a new rover is just flashing the SD card, setting its `name`, and plugging it into the trusted LAN—**no auth or per-rover server config is required on the Pi ⇄ server hop.**
2. **mediaMTX on the server**
- Single wildcard path handles every rover:
```yaml
paths:
"~^rover-(?P<id>[a-z0-9_-]+)$":
source: publisher
sourceOnDemand: no
sourceProtocol: srt
readBufferCount: 512
webrtcEnable: yes
webrtcMaxPlayoutDelay: 0
alwaysRemuxWhep: no
```
- Pis publish to `srt://<server>:9000` with the streamid above; mediaMTX auto-creates the path and fans it out over WHEP/WebRTC. If you expose playback under `/video/<id>` externally, let the reverse proxy rewrite that prefix back to `<id>` before forwarding to mediaMTX so the wildcard continues to match every rover.
- Only playback is gated: mediaMTX calls the Node server to validate JWTs on `/whep/rover-<id>`, so “locking” a stream is as simple as refusing to mint viewer tokens for that rover. Ingest stays unauthenticated because it lives on a secure LAN.
3. **Web clients**
- Tiny helper (React hook or vanilla class) that:
1. Requests a viewer token for rover `<id>`.
2. Issues a `POST` to `<mediamtx-host>/<rover-id>/whep` with `Authorization: Basic base64(token:token)` (token issued by the server when the client calls `video:request`).
3. Maintains auto-reconnect timers on ICE failure so dashboard widgets can come/go without reloading the page.
- Operator dashboard mounts one player tied to the assigned rover. The spectator view instantiates one player per tile, muting + pausing hidden elements to keep CPU usage sane even when every rover is shown simultaneously.
# Deployment checklist
- `pi/install_roverd.sh` installs the `video-publisher` helper, drops `/var/lib/roverd/video.env`, and pulls in `libcamera-apps` + `ffmpeg` from apt. No custom FFmpeg, no WHIP builds, no extra config—Pis become plug-and-play.
- `roverd` derives `media.publishUrl` automatically from `serverUrl`: `srt://<server>:9000?streamid=#!::r=<name>,m=publish&latency=20&mode=caller&transtype=live&pkt_size=1316`. The media supervisor rewrites `video.env` and manages `video-publisher.service` whenever you hit “Restart Camera” or change `/etc/roverd.yaml`.
- The server’s mediaMTX config switches to the wildcard block above, leaves SRT ingest open, and enforces JWTs only on WHEP viewers. Fan-out stays inside mediaMTX so every browser sees the same low-latency stream (≈250–350 ms glass-to-glass).
- Adding a rover = flash SD → set `/etc/roverd.yaml` (`name`, `serverUrl`, camera knobs if needed) → boot it. The server auto-discovers the new `rover-<id>` stream with zero manual edits.
plans/nicknames_and_chat_outline.md
-53
View File
@@ -1,53 +0,0 @@
# nicknames:
- users will be able to have and set nicknames
- a user's nickname will store in the browser using persistence.js
- the user's nickname should probably just be in socket.data.nickname
- on connection, the web UI will tell the server "this is my nickname"
- completely enforced by the web UI
- replace any place in the web UI that shows a socket ID with the nickname
- create a small react component which can set your nickname and save it
# user list in session data:
- add a list of users to the session data for the web UI
- contains for each user:
- socket ID
- nickname
- the rover that they are driving
- their role (user, admin, lockdown, spectator)
# user list:
- a list of users
- new react component
- uses user list with nicknames from session data
- show their nickname and whether or not they are an admin
# chat:
- server side chat system:
- don't store message history
- emit an event to the event bus for each message
- eventually will be forwarded to discord through a bot
- listen to chat message events on the bus
- eventually the discord bot will also send messages to the server chat
- profanity filter
- spam filter
- repeated words
- keymashing
- etc
- somehow link chat messages to rovers
- in the future rovers will have TTS onboard, and will speak chat messages only from the person driving the rover
- chat on the UI
- new react component
- show messages as they come in:
- time (just like 19:23), sender nickname, rover they are driving, message
- pressing enter on the keyboard will pause rover control, and focus the chat box.
- pressing enter again after typing will send the message
# layout and styling for new UI elements:
- use index.css styles to match the new stuff to the current UI
- just edit the desktop page for now
- layout:
- in the left column, a new row in between video and logs
- 50/50 split between:
- user list and nickname entry
- chat history and chat box
plans/outline.md
-58
View File
@@ -1,58 +0,0 @@
## multi roomba rover
a website where people can control multiple irobot create 2 robots in real time 100% responsively
with a raspberry pi zero 2 W on each roomba, along with a raspberry pi camera
a central nodejs control server will tell the raspberry pis what to do with the roomba
## the pi side (roomba side)
- pi's onboard UART is hooked up to the roomba's serial port
- another GPIO pin connected to the roomba's BRC pin
- pull it low for one second every minute to keep the roomba awake
- streams the rpi camera over webRTC with mediamtx
- streams roomba sensor group 100 to the server
- sensor streaming is required and important, but is allowed to falter sometimes
- listens for roomba commands from the server
- commands NEED to happen
- roomba control program needs to be simple, lightweight, and 100% responsive
## pi -> server communication
- stateless
- streaming based
- on connection, the pi will send the following info:
- rover's name
- motor enable / disable
- vacuum
- main brush
- side brush
- battery full number
- battery warning number
- battery urgent number
## nodejs server
- KISS
- decode the sensor data from each roomba
- can support multiple roombas connected from the ground up
- keep it simple, worry about getting the pi comms right.
- but the server DOES have to exist for testing
- IS the web server, hosts an entire static folder for the web UI
## server -> web UI communication
- socket.io
- don't do anything fancy with the socket.io setup
- it works fine out of the box, we will optimize it later
## the web UI
- KISS
- plain old html. no styling even. just bare minimum for testing
- what it needs to do:
- allow user to select the roomba from a list
- make the selected roomba drive with WASD
- have buttons to set the OI mode, and tell the roomba to dock
- show a plain list of the sensor data from the selected roomba
### general javascript programming guidelines (applies to the web UI too)
- everything ES6
- one entrypoint file in the web UI
- everything modular
- everything easy to read, understand, and work on
- comment where you think is best to describe whats going on
plans/pi_camera_servo_outline.md
-13
View File
@@ -1,13 +0,0 @@
# general idea
- servo connected to pin 19 on the pi
- it will allow the camera to look up and down
- use go-rpio
- it has a hardware PWM implementation
- mechanical design will have limits
- set the limits in roverd config
- control the servo from the web browser
- expose both a slider and buttons for "nudging" it up and down
## verification of functionality before full implementation
- make sure that the go program can properly use the GPIO correctly before full implementation
- modify the roverd installer to add the needed stuff to enable PWM access
plans/pi_mic_to_rover_video_outline.md
-23
View File
@@ -1,23 +0,0 @@
# general idea
- the pi's microphone needs to be streamed to users
- as part of the rover's video feed
- the pi model is a zero 2 W
- it CANNOT handle transcoding the audio onboard, I have tried.
- the server is super powerful and can handle transcoding
- it is NOT acceptable to add more than 100ms of video latency from glass to glass
- it is NOT acceptable to break video streaming for pis that don't have microphones
### OLD, BAD, but working audio configuration that worked for the microphone
```
-f alsa -guess_layout_max 0 -thread_queue_size 2048 -ac 1 -ar 48000 -i plughw:0,0 \
-map 1:a:0 \
-c:a libopus -b:a 24000 -compression_level 0 -application voip -frame_duration 60 \
-ac:a 1 -ar:a 48000 -af "pan=1c|c0=c0,volume=20dB"
```
- the raspberry pi CANNOT HANDLE AUDIO ENCODING onboard. this is just to show you how to use the mic.
sudo systemctl restart roverd
#sudo systemctl restart audio-capture
sudo systemctl restart video-publisher
sudo cat /var/lib/roverd/video.env
plans/problems.md
-27
View File
@@ -1,27 +0,0 @@
## raspberry pi
<!-- - need to throttle sensor sending, maybe only send one in every 5 packets. -->
## 3d models for camera:
- https://www.thingiverse.com/thing:2873677
- https://www.printables.com/model/356894-raspberry-camera-module-with-automatic-ir-cut-swit
- https://www.thingiverse.com/thing:4514531
## todo
<!-- 1. battery manager -->
<!-- 2. pi-side sensor throttle (1/5th) -->
<!-- 3. convert rover roster to a reusable component, unbake it from telemetry and admin panels -->
<!-- 4. room cameras -->
4. fix gamepad input - more complex axis assignment? division, combined axes?
<!-- 5. home assistant controls -->
<!-- 6. nicknames -->
<!-- 7. discord bot -->
<!-- 8. turns mode display -->
<!-- 9. online user list -->
<!-- 10. chat -->
<!-- 9. discord invite button -->
<!-- 10. redo both mobile layouts -->
<!-- 11. redo spectator view (last) -->
<!-- 21. finally.. set the favicon and title -->
22. rover snapshots freezing and never coming back
23. rover snapshot -> video switching needs to be smoother, no black flash. connect and play before showing.
24. rover snapshots delayed (not just because of framerate)
plans/react_ui_controls_system_outline.md
-69
View File
@@ -1,69 +0,0 @@
# general idea
- a modular control system
- every piece of the UI that uses rover controls will go through this, including onscreen click buttons
- allows for dynamic control labels based on saved settings
- allow a place to assign OI command macros
- like the one that the drive button uses now
- allows realtime responsive control of the rover that you are driving
## some sort of system for the site to save settings per browser
- needs to be extensible
- future things will use it
- expose functions like saveSettings and loadSettings
- other parts of the UI will need to save and load settings using this function
- use cookies
## keyboard controls:
- remappable by new component in settings tab
- key mappings will save
- controls for the keyboard
- driving
- WASD blended for tank steering
- hold backslash to move faster
- hold right shift to move slower
- aux motors
- main brush
- hold O to move it forward at speed 127
- hold L to move it backward at speed -127
- side brush
- hold P to move it forward at speed 127
- hold ; to move it backward at speed -70
- vacuum motor
- hold [ to move it at speed 127
- hold ' to move it at speed 50
- ALL AUX MOTORS
- hold . to move at full speed forward (127)
- camera movement
- hold I to look up
- hold K to look down
- dock and drive hotkeys
- G for drive (use same 3 part macro as the drive button)
- H for dock (seek dock command)
## Mobile controls
- 2 different layouts, already implemented just needs improved.
### mobile landscape
- a video game style layout
- on the left, buttons that you hold to operate the aux motors
- in the middle, is the rover video component.
- on the right, an area for a floating joystick and above is a unified control to see and change the rover's mode (drive or dock)
### mobile portrait
- designed to be driven vertically with 2 hands
- mostly fine already
- rover video at the top
- then below it, is a section with the aux motor buttons on the left, and the floating joystick are on the right.
## Gamepad controls:
- use some sort of react thing that makes it easy to use the web gamepad stuff
- left joystick for movement, right joystick for moving camera up / down
- both fully analog
- right trigger for the main brush motor
- fully analog
- press right bumper to switch it to reverse
- left trigger for the side brush motor
- fully analog
- press left bumper to switch it to reverse
- hold the right face button to run the vacuum motor
- hold the lower face button to run all aux motors forward
- left and right on the Dpad switch between drive and dock modes
plans/room_camera_conversion_outline.md
-10
View File
@@ -1,10 +0,0 @@
# general idea
- convert room cameras from webrtc h264 streams to 4fps jpegs sent over socket.io
## requirements
- make updated services for server and pi room cams
- no backwards compatability is needed
- room cameras are both 4:3, make sure they show as such in the UI
- remove anything related to the webRTC room cams
- send the jpegs efficiently (as binary)
- make sure the room cams are still authed as they are now
plans/room_cameras_outline.md
-14
View File
@@ -1,14 +0,0 @@
# general idea
- add support for multiple room cameras through the server to the UI
## what needs to happen on the server:
- add support for a path of room cameras on mediamtx
- /room/<camera_name>
- CANNOT interfere with rover cameras (/<rover_name>)
- needs to use the same auth system as the rover camera
- room cameras will be streamed to the server over SRT
## what needs to happen in the web UI
- users should be able to see all room cameras, even if not assigned to a rover
- automatically add a room camera player for each room camera
- make a component that shows all room cameras
plans/server_client_structure.md
-51
View File
@@ -1,51 +0,0 @@
# server code structure:
The server's internal structure will be modular, and by modular i mean completely modular,
the modules will import what they need from other modules, and export what other modules will need from them.
the entrypoint file will contain nothing but a long list of `require('')`s for all of the modules in the proper order
for example, A service which automatically assigns a newly connected user to a roomba that isn't in use.
this service would import the roomba list from whatever other service contains it, and import the global socket.io server instance. It will add its own io.on('connection') to the socket.io instance, which contains the logic for assigning users to roombas.
- modular code structure
- one folder for each of these categories
- globals
- GLOBALS ARE: "static" parts of the server that don't contain any interactive logic.
- where the express, websocket, and socket.io instances will be
- other global things
- services
- SERVICES ARE: parts of the program that are part of the interaction pipeline.
- contains things like the roomba manager
- will also in the future contain other things like a discord bot, home assistant integration, etc
- anything with a large amount of controlling logic should be in here
- helpers
- HELPERS ARE: parts of the program that other modules only pull helper funcions or classes from.
- if a function or class is dedicated to a service, it should NOT be in a helper.
- contains passive helpers
- things like the logger system
- no "service" logic in here, only things that are passively pulled out and used inside other modules
- one entrypoint file that contains NOTHING but `require('')`s.
# server <-> web client logistics
I want each connected roomba to have a list of drivers. if a socket is not in this list, they are not allowed to drive the roomba. I will be adding admins, authentication, a turns system, and automatic roomba assignment later so it is important that we start with this system in place.
a roomba's list of drivers will be completely managed by the server, users should not be able to change driver lists, even in a hacky way.
Each user will also have to see sensor data from the roomba that they are controlling. I want it to be done in this way:
- for each connected roomba, there is a socket.io room where all of the sensor data is streamed out to clients
- the client will be added to the room, where they can see all of the active roomba's sensor data
- ALSO for future use, it needs to work properly if a socket is subscribed to all rooms, in the future there will be a spectator page which can view all of the roombas at once.
I want there to be a ground up system where I can set the entire service to four different modes:
- open (anyone can drive, roombas are assigned randomly. if they are all full, two people will be controlling the same roomba)
- turns (anyone can drive, roombas are assigned randomly. if they are all full, each person gets one minute on their selected roomba)
- admin (only authenticated admins can log in, anyone can still view but no one is allowed to drive but admins)
- lockdown (only "lockdown" admins can view or drive. no one else can view, not even spectators).
only admins can change modes.
do NOT implement any authentication stuff yet, just add a stub service with places set up to put the auth. logic
# web client code structure:
- the same as the server's code structure
- all ES6
plans/spectate_mode_overhaul_outline.md
-44
View File
@@ -1,44 +0,0 @@
# spectate system overhaul
- rip out and remake the entire page
- basically keep nothing from it
- right now the spectator page is a mess, and hasn't been updated in a while
- does not work properly, aside from the page being out of date
- the spectate page should use modules from the driver page
- there should be no such thing as a "spectate mode" on the driver page. If someone wants to spectate, they must go to the spectator page.
## rules of the spectator page
- spectators are not allowed to drive
- spectators are not allowed to chat
- spectators are not allowed to have nicknames
- spectators are not allowed to login as admin
- these are the permissions for spectators based on the sever's access control mode
- open
- spectators can spectate
- turns
- spectators can spectate
- admin
- spectators can spectate
- lockdown
- spectators can NOT spectate
## what should be on the spectator page?
- for each rover
- video component
- current driver
- sensor telemetry component
- logs
- room cameras
- online user list
## layout and styling of the spectator page
- use same styling style as the driver page
- feel free to add spectator role checks to hide the features that spectators can't use in certain components.
- mainly designed for a 4:3 monitor
- make use of the vertical space
- a row of columns, one for each rover at the top
- below the row of columns:
- 50/50 split
- user list
- chat
- room cameras
plans/ui_buttons_consolidation.md
-50
View File
@@ -1,50 +0,0 @@
# general idea:
- consolidate each rover control button to it's own component which is used standalone
- rework mobile controls (throw away the current left column)
- check for duplicates of any control components in redundant places
- main culprits
- dock drive action
- mobile control columns
- night vision (headlight) button
- horn button
- camera tilt slider
- also plan to rework mobile controls, but just ensure consolidation first
## dock / drive action:
- ensure that it is one standalone component
- revamp the system which allows it to hide / show other componenets that it "covers"
## camera tilt slider:
- the biggest issue currently
- it seems to be the root of the problems of things not being consolidated
- ensure that it is ONLY the camera slider component
- keep styling
- add option for a vertical slider with just a degrees number at the top
## night vision (headlight) button
- center label, make it large and match the labels of the horn and drive/dock action labels
- center status badge
- allow height class to be changed for different modes
## horn button
- the newest one
- mostly good
- for mobile layouts, make it hide the settings by default, and when shown make them nicely laid out for fitting in a skinny column on mobile
# new mobile control columns:
- get rid of the current entire left column with all the aux buttons, we are replacing it
- the new left column:
- top section
- vertical camera slider
- night vision button
- middle section (two new buttons, side by side)
- all aux forward button
- all aux backward button
- bottom section
- horn button
- the modified right column:
- no more camera slider
- no more night vision toggle
- still dock/drive action full-column, which minimizes itself
- when minimized, make the dock button a little taller
plans/ui_styling_overhaul_outline.md
-67
View File
@@ -1,67 +0,0 @@
# general idea:
- very compact UI
- utilitarian
- function before pretty
- tiny text, too.
- no large margins or padding. very little wasted space
- up to 1 tailwind unit unless otherwise needed
- black background, gray cards, white or gray text
- tailwind
- no title or bar at the top, vertical screen space is precious on all layouts
- alerts should be moved to a tiny toast popup that will show at the top center of the screen
# three different layouts for the driver page
- desktop
- rover video central, no title or anything above it
- overlayed on rover video (HUD like in a video game)
- build the HUD into the video tile
- because everywhere the video is, the HUD should be too
- shows a dot that blinks on each sensor frame
- shows wheel drops and bumpers
- shows a big "loud" warning overlay during an overcurrent
- simple, easy to understand battery bar UNDERNEATH the video:
- takes in battery full, warn, and urgent values
- treat full as 100% and warn as 0%
- make the bar flash red when its 0% or lower
- on left side of rover video:
- sensor data, visualized.
- battery charge out of capacity (1763/2068)
- charging status
- OI mode
- battery voltage (in volts not mv)
- battery current
- a teeny show of the raw data (because we get it on the client and it looks cool)
- on right side of rover video
- a simple, easy control panel with the following actions:
- a button that runs the start OI, dock, then full commands (in that order)
- also contains a little status of whether or not the rover is in "driving mode" (OI in full mode)
- a button that tells the rover to seek dock
- explains that you should be straight in front of, and about a foot from the dock for a successful attempt
- contains two status indicators:
- docked / not docked (homebase true)
- charging / not charging (when chargingstate isn't "not charging" the rover is charging)
- below the upper control and video row
- center:
- a place for the room camera (not implemented yet)
- left:
- admin login and controls
- right:
- logs
- mobile in portrait mode
- rover video at the top, with HUD
- just below:
- joystick with buttons for aux. motor controls
- have a button to run all aux motors forward at max speed
- also have buttons to run motors forward / backward individually
- probably use some premade react joystick
- scroll down more to see:
- the same simple mode control buttons from the desktop layout
- also needs to have the admin login and controls
- needs to have all the functionality as the desktop page
- mobile in landscape mode
- made for videogame-like control of the rover
- control buttons and aux motors on the left
- rover video in the middle
- joystick on the right
- again, scroll down to see more
- also has to do everything
plans/ui_themeing_outline.md
-14
View File
@@ -1,14 +0,0 @@
# general idea
- users can choose from preset, and create UI themes
- the default theme is the current in place theme
- themes will NOT change margins, borders, padding, spacing, etc.
- should be as simple as changing the global css stuff
- themes can change colors, fonts, border radius, borders, etc
## technical stuff
- save theme info in
## UI for themeing
- allow people to tune every theme element that there is to tune
- allow people to export themes as json files, and import them
-
plans/ui_unification_outline.md
-23
View File
@@ -1,23 +0,0 @@
# general idea
- a bunch of small UI adjustments
- always keep styling consistent to the rest of the page
## everywhere
- add an audio stream status to the rover video panel, only show it if the rover has the separate audio stream
- make the room camera panels save their stack setting per instance of the panel in the web UI's settings storage system
- remove the status bar below room cameras
- put it in the corner of the feed, like the other video panels
- make the styling of the room camera panels match everything else
- when the user list switches to turns, always show the plain user list, but below the turns info
## on the spectator page
- rover video panels
- no more telemetry bar below each rover video
- ovelay the tiny telemetry summary on the left side of the video, with the rest of the HUD elements
- including the battery bar, make it vertical on the right side of the video
- no more title bar above each rover video
- the rover's name is already on the HUD
- add current driver to the HUD
- sidebar
- shrink the logs panel
- add an actual rover list to the top of the sidebar
roomcam-service/README.md
-28
View File
@@ -1,28 +0,0 @@
# Room camera snapshot service
Lightweight systemd service that serves a JPEG snapshot from any MJPEG-capable webcam (most USB webcams) at 4 fps. The server pulls `http://<host>:8080/snapshot.jpg` for room cams.
## Files
- `room-cam-snapshot.sh` – ffmpeg + simple HTTP server wrapper
- `room-cam.service` – systemd unit template
## Usage
1) Copy the service into place (adjust path/env as needed):
```bash
sudo cp roomcam-service/room-cam.service /etc/systemd/system/room-cam.service
sudo systemctl daemon-reload
sudo systemctl enable --now room-cam.service
```
2) Override defaults via `Environment=` in the unit or drop-ins:
- `DEVICE=/dev/video0`
- `RESOLUTION=640x480`
- `QUALITY=5` (ffmpeg MJPEG quality; lower is higher quality)
- `PORT=8080`
- `WORKDIR=/run/roomcam`
- `INPUT_FORMAT=mjpeg` (use `bayer_grbg8` for OV534/raw Bayer cams; aliases `GRBG`/`grbg` are accepted)
3) Point the server `roomCameras[].url` to `http://<host>:8080/snapshot.jpg`.
Notes:
- The camera runs at its native MJPEG frame rate; the server polls snapshots at ~4 fps, so no extra filtering is applied here.
To run outside systemd, just execute `./room-cam-snapshot.sh` with any overrides.
webui/README.md
-16
View File
@@ -1,16 +0,0 @@
# React + Vite
This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Currently, two official plugins are available:
- [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react) uses [Babel](https://babeljs.io/) (or [oxc](https://oxc.rs) when used in [rolldown-vite](https://vite.dev/guide/rolldown)) for Fast Refresh
- [@vitejs/plugin-react-swc](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react-swc) uses [SWC](https://swc.rs/) for Fast Refresh
## React Compiler
The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see [this documentation](https://react.dev/learn/react-compiler/installation).
## Expanding the ESLint configuration
If you are developing a production application, we recommend using TypeScript with type-aware lint rules enabled. Check out the [TS template](https://github.com/vitejs/vite/tree/main/packages/create-vite/template-react-ts) for information on how to integrate TypeScript and [`typescript-eslint`](https://typescript-eslint.io) in your project.