Automatakit API
aka project 'consistent-sandbox'
Automatakit is a system architecture for robotics where machine controllers are extensible, and organized around the principle of event propagation: things happen because of other things that have happened beforehand.
We aim to take an event graph architecture down through multiple layers of computing, routing event propagation also through a message passing network between multiple cpus each operating modular hardware endpoints.
This project serves the developement environment / api we use to write and represent programs that are event graphs. Install and Run.
For MW
-
walk program units and change
-
hardware, and consolidate ?
-
what program units do we want?
-
good templates for hw/software ... good documentation
-
and a decent planner, pls, and stepper for planner-less motion
-
oh, what if extend module in module ? i.e. one stepper for planner ... one stepper for unit mtn ? same internals, different interfaces ... nice trick
-
try demo machine setup ... want flow control, better planning, this is actually a big thing
-
jogging, etc ... keydown UI modules probably cool
Documentation
- GIFS
- load a program
- drag around
- zoom in and out
- add a module
- hook events up
- rm events
- rm modules
- change settings
Questionable Moves
- module deletion seems unclean
- input / output objects should be able to unhook themselves:
- keep references of what-is-attached ?
WRT Representations
OK, should write this out properly at some point.
Module have Inputs Outputs State (initial states are settings)
Hardware Modules have routes connected to links
Also Names, IDs Paths-to-source
To assemble a representation of these, we want to have a kind of 'netlist' that, for convenience, we'll treat like a JSON object. We want heirarchy, so consider the representation having 'top-level' outputs / inputs / state as well ?
Programming Notes
15 Minute Tasks
- @ views.js, uiRequestModuleMenu and uiRequestProgramMenu don't properly build trees from folder structure. similarly, reciprical fn's in client.js do the same
- @ these load / save functions could also reach into the modules' source to retrieve their proper names, as spec'd in description ...
- 's' for save program uses hack-asf DOM alert to ask for path
Desires
- heirarchy zoom
- architectural clarity betwixt UI and Heap
- states / uis / etc - one off / one-at-a-time for updates
- i.e. all f'n update calls are to single module-global state update
- !
- states / getters / setters not applicable to sub-elements in an object within state
- i.e. array access
- consistent dereferencing, type checking implementation?
UI Desires
- modules have visual ways to throw errors - i.e. flashing red, popping up...
- off-screen divs get pointers-to so that we don't get lost
- 'h' or something to zoom-to-extents
- better module menu
- hover for alt descriptions
Planner Bugs
- trapezoid linking doesn't account for speed changes properly, i.e. doesn't ramp down into next move if next move's cruise speed is less than our exit speed
- should have some stronger ideas about flow control, allowable segment size (based on time)
Want
- log() for logs-from-module tagged
Demo Desires
- want to show immediacy of hardware: software representation
- want to show physical reconfigurability and software reconfigurability
- i.e. mill, add rotary tool, pull normal vector from planner moves and route to r motor
- want to have UI elements
- button, terminal,
- live motor torque display, vector from accelerometer
Network Desires
- c improvements / dma etc, would be very cool
- flow control probably desired ... what can we model with uart and implement with fpga?
- proper speed tests
- DMA not possible / not enough channels for router implementation / not portable enough ...
- lights displaying activity
Bugs
- cannot connect input to output w/o backwards bezier
The RPI
need to figure out how to get the RPI serialport to talk