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.
For MW
-
rick click on menu bar to delete module
-
delete module ? then we're done ...
-
walk program units and change
-
what program units do we want?
-
try demo machine setup ... want flow control,
-
jogging, etc ... keydown units ?
-
documentation
-
upd8ts to modules:
-
rename inout to jsunit
-
buttons get onClick evt
-
as you test, to track,
-
weird state types solution: arrays, numbers, buttons, etc ?
-
UI desires
-
off-screen divs get pointers-to so that we don't get lost
-
'h' or something to zoom-to-extents
-
GIFS
-
load a program
-
drag around
-
zoom in and out
-
add a module
-
hook events up
-
rm events
-
rm modules
-
change settings
-
next spiral
-
programs come in chunk-wise and get placed
-
programs are modules are heirarchical
WRT Representations
OK
Module have Inputs Outputs State (initial states are settings)
Also Names, IDs Paths-to-source
Modules-that-represent-remote-computing also have Ports that connect to a Link
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
title bar L for load prgmem M for add module
- once we can plan gcode sequence, work towards more
- better hardware abstraction, i.e. stepper.port = bridge.port('0,1') stepper.port.onPacket = function(){ ... } callbacks ?
- UI elements, i.e. demonstrating slider for individual axis movements, or just an arrow / keypad capture on mouseover thing
Deeply Missing
- delete modules / module context menu
- load / save program
- decent page nav
- title bar / instructions
- heirarchy zoom
- 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?
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
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
- when bridge has two addresses only one sends
- add watch for identical addresses
- besides we want a different network representation
- cannot connect input to output w/o backwards bezier
The RPI
-
sudo apt-get update
-
sudo apt-get upgrade
-
install nvm
-
install git