README.md 8.32 KB
Newer Older
Jake Read's avatar
Jake Read committed
1
# Squid Works: Distributed Dataflow Machine Controllers
Jake Read's avatar
1st  
Jake Read committed
2

Jake Read's avatar
Jake Read committed
3
**Status 2019/07/18**
Jake Read's avatar
1st  
Jake Read committed
4

Jake Read's avatar
Jake Read committed
5
The project is ongoing. Managers exist and run dataflow programs in Node, in the Brower, and in Embedded CPP. Each manager is now essentially complete. Network serialization algorithms are written, as is a scheme for program description via sequential messaging.
Jake Read's avatar
Jake Read committed
6

Jake Read's avatar
Jake Read committed
7
Largely, work is ongoing in application development, and in completing cuttlefish's heirarchichal tools like route building and system restore / save. Work is also ongoing in networking, and many serialization types remain unwritten, but will be filled in as applications call for them...
Jake Read's avatar
Jake Read committed
8

Jake Read's avatar
Jake Read committed
9
![motors](video/squidworks-2019-07-18-motors.mp4)
Jake Read's avatar
1st  
Jake Read committed
10

Jake Read's avatar
Jake Read committed
11
12
13
14
15
16
That's great, and here's a screenshot and video of running this system through a 2nd link, showing more levels of nesting...

![L4 Graph](images/2019-07-19-systemone.png)

![L4 Video](video/2019-07-18-systemone.mp4)

Jake Read's avatar
Jake Read committed
17
18
## What it Is

Jake Read's avatar
Jake Read committed
19
The **Squid Works** project is a bundle of modular hardware and software resources for the development of Distributed Dataflow Machine Controllers: a class of controllers that use dataflow programming across network links to orchestrate global control across heterogeneous computing.
Jake Read's avatar
Jake Read committed
20

Jake Read's avatar
Jake Read committed
21
This means that *adding and removing hardware to a system is easy, and possible.* It also means that *re-writing machine controllers,* to accept new inputs, or deliver new outputs (material, or feedback) is easy. Machine controllers are transparent: their operating principles are obvious to their users, and so intelligent intervention (and modification!) of controllers is possible. We can re-use algorithms and processes that we have developed across many machine instantiations, and we can build custom systems with less overhead. Digital tools are pliable again (soon), and under our control.
Jake Read's avatar
Jake Read committed
22
23

![atkapi](images/machine-with-atkapi.jpg)
Jake Read's avatar
1st  
Jake Read committed
24

Jake Read's avatar
Jake Read committed
25
### Contexts
Jake Read's avatar
Jake Read committed
26

Jake Read's avatar
Jake Read committed
27
Each of the computers participating in the control of these machines runs a *context* - contexts, while written in different languages and running on different platforms, share a set of messages they can use to describe their internals to one another - and they run the same *execution model* internally. This is the (simple) reconfiguration that allows us to build controllers whose execution can be understood (and modified) cohesively, despite their operation across a network, in physical space.
Jake Read's avatar
Jake Read committed
28

Jake Read's avatar
Jake Read committed
29
[Cuttlefish](https://gitlab.cba.mit.edu/squidworks/cuttlefish), for the browser, also serves visual representations of its own dataflow graphs, as well as dataflow across a network. This allows us to visualize, interact with, and build and edit distributed programs.
Jake Read's avatar
Jake Read committed
30

Jake Read's avatar
Jake Read committed
31
[Nautilus](https://gitlab.cba.mit.edu/squidworks/nautilus), for node.js, can run on servers and on local hardware. This is especially handy when we need to hook up to hardware resources like usb ports, etc. Its internals are directly scraped from cuttlefish.
Jake Read's avatar
Jake Read committed
32

Jake Read's avatar
Jake Read committed
33
[Ponyo](https://gitlab.cba.mit.edu/squidworks/ponyo), the smallest fish (and queen of the sea), runs dataflow graphs on embedded microcontrollers. At the moment this is limited to the ATSAMD51J19, a 120MHz Arm M4F. It connects to nautilus via usb links, and to other fishes via a very-fast-uart link that includes a synchronization line. Ponyo is very much under development.
Jake Read's avatar
Jake Read committed
34

Jake Read's avatar
Jake Read committed
35
### Circuits
Jake Read's avatar
Jake Read committed
36

Jake Read's avatar
Jake Read committed
37
At the end of the day, current moves through coils, voltages are read and delivered, etc. These machines aren't going to operate themselves (or, ) - so these are the hardware tools we use to make them dance.
Jake Read's avatar
1st  
Jake Read committed
38

Jake Read's avatar
Jake Read committed
39
![endpoints](images/endpoints.jpg)
Jake Read's avatar
Jake Read committed
40

Jake Read's avatar
Jake Read committed
41
[ATSAMD51 Motherboard](https://gitlab.cba.mit.edu/squidworks/motherboard-atsamd51) is a host to Ponyo, boasting a 40-pin (30 IO, GND, 5V and 3V3 lines) GPIO 'port'. This connects to daughter boards;
Jake Read's avatar
1st  
Jake Read committed
42

Jake Read's avatar
Jake Read committed
43
[Stepper Motor Daughterboard](https://gitlab.cba.mit.edu/squidworks/daughterboard-stepper) uses a TMC262 gate driver to drive two discrete H-Bridges, current chopping excited stepper motor coils. Spins those motors. Includes a home for an AS5047 encoder if I ever find time to close that loop.
Jake Read's avatar
Jake Read committed
44

Jake Read's avatar
Jake Read committed
45
46
[H-Bridge Daughterboard](https://gitlab.cba.mit.edu/squidworks/daughterboard-hbridge) uses an A4955 gate driver to drive one discrete H-Bridge, with a sense resistor for closed loop current control, or optional hardware current chopping. The board can also be used to drive one or two heavy dc loads, like heating elements. Includes an SPI breakout port for an encoder, or fancy thermometer, etc.

Jake Read's avatar
Jake Read committed
47
[Router Daughterboard](https://gitlab.cba.mit.edu/squidworks/daughterboard-router) adds four (4) very-fast-uart (codename VFP) links to the motherboard, establishing system hubs, etc. These can be chained / etc - there is no graph size limit.
Jake Read's avatar
Jake Read committed
48

Jake Read's avatar
Jake Read committed
49
50
51
[Power Distribution Boards](https://gitlab.cba.mit.edu/squidworks/pdbs) are handy circuits for bussing power (separate from network) around a machine.

[SPI Daughters](https://gitlab.cba.mit.edu/squidworks/spies) are small circuits used to locate sensors off board, i.e. the encoder for brushless servos and spindles.
Jake Read's avatar
Jake Read committed
52

Jake Read's avatar
Jake Read committed
53
**Planned Endpoints** include a DC motor driver and BLDC motor driver, both exist in revisions for earlier architectures. Also including an Ultrasonic driver. Many of these boards are just variations on the h-bridge, so there will be some attempt to anneal towards generic power control for i.e. heating, melting, solenoid switching, etc. Sensing is another topic.
Jake Read's avatar
Jake Read committed
54

Jake Read's avatar
Jake Read committed
55
## Machines Running DDMCs
Jake Read's avatar
Jake Read committed
56

Jake Read's avatar
Jake Read committed
57
58
59
60
61
62
63
 - [Little Rascal](https://gitlab.cba.mit.edu/jakeread/littlerascal)
 - [Mother Mother: a Machine Generalist](https://gitlab.cba.mit.edu/jakeread/mothermother)
 - [Small Stress and Strain Machine (uSSM)](https://gitlab.cba.mit.edu/jakeread/ussm)
 - [*A Machine* for playing *Music for Pieces of Wood* by Steve Reich by Jake Read](https://gitlab.cba.mit.edu/jakeread/reich)
 - [MPVMachine](https://gitlab.cba.mit.edu/jakeread/mpvmachine)
 - [SmallGantries](https://gitlab.cba.mit.edu/jakeread/smallgantries)
 - [ClayStacker](https://gitlab.cba.mit.edu/jakeread/claystack)
Jake Read's avatar
1st  
Jake Read committed
64

Jake Read's avatar
Jake Read committed
65
(Most of these machines are built with parametric designs for their constituent components, that project is here: [RCT Gantries](https://gitlab.cba.mit.edu/jakeread/rctgantries)).
Jake Read's avatar
1st  
Jake Read committed
66

Jake Read's avatar
doc    
Jake Read committed
67
# Usage
Jake Read's avatar
Jake Read committed
68

Jake Read's avatar
doc    
Jake Read committed
69
70
## Wiring

Jake Read's avatar
Jake Read committed
71
### Powering Distribution
Jake Read's avatar
Jake Read committed
72

Jake Read's avatar
Jake Read committed
73
The network cables don't carry any power, just four pairs of differential signals. So each board needs a power connection as well. I am becoming partial to XT30 connectors, and the power-top board [in here](https://gitlab.cba.mit.edu/squidworks/pdbs) has one of those included, but there are no rules.
Jake Read's avatar
Jake Read committed
74

Jake Read's avatar
Jake Read committed
75
76
I have a small set of power distribution boards:

Jake Read's avatar
Jake Read committed
77
[PDBs](https://gitlab.cba.mit.edu/squidworks/pdbs)
Jake Read's avatar
Jake Read committed
78
79
80

I hook these up end-to-end to make blocks of just-the-kind of power splitter, etc, that I want.

Jake Read's avatar
Jake Read committed
81
The boards should all share a ground, but can run on different voltages of input power. Most will take 24v on two M3 screw-mounts - I use eye terminals soldered to 18ga wire to deliver power.
Jake Read's avatar
Jake Read committed
82

Jake Read's avatar
Jake Read committed
83
The router can also accept power from a USB device. If you're powering it over USB, *do not* also power it via 24v.
Jake Read's avatar
Jake Read committed
84
85
86

Last thing, don't power your supply on before you go to screw power connections onto the boards. Wire them up, and then switch on.

Jake Read's avatar
Jake Read committed
87
### Network Cables
Jake Read's avatar
Jake Read committed
88

Jake Read's avatar
Jake Read committed
89
At a bare minimum, you're going to be hooking these things up to power, and to each other (network).
Jake Read's avatar
doc    
Jake Read committed
90

Jake Read's avatar
Jake Read committed
91
92
 - network cables can be made two ways: only one is correct - *rj45 tabs should be on the same side of the ribbon cable* i.e. the cable is a 'straight through' type, not a crossover. this means that tx meets rx, etc.
 - the transmit / receive ports are RS-485 Differential Driven, meaning there is no common gnd connection between boards besides the power bus.
Jake Read's avatar
doc    
Jake Read committed
93
94
95
96
97
98

The connectors I use are called 'RJ45' Jacks and Plugs. These are standard for Ethernet, but also 'generally useful'. This is not ethernet, but these *are* RJ45. It's 8 wires, and in our case that's four differential pairs - two duplex lines on each side.

One cool thing about RJ45 is the modularity of the cables. We can use commodity crimping tools to make our own lengths:
 - one side cuts, one side strips. use both at the same time to get the right length of stripped wire
 - use the '8p' crimp, note the tab direction in the crimp
Jake Read's avatar
Jake Read committed
99
 - pinch! the plug has a plastic tab inside that should come down to meet the wire jacket
Jake Read's avatar
doc    
Jake Read committed
100
101
102

![rj45 video](images/rj45-assembly.mp4)

Jake Read's avatar
Jake Read committed
103
104
105
```
make sure those tabs are on the same side of the flat cable
```
Jake Read's avatar
doc    
Jake Read committed
106
107
108

![rj45](images/rj45-tabs.jpg)

Jake Read's avatar
Jake Read committed
109
## Software
110

Jake Read's avatar
Jake Read committed
111
Very in-flux, pls check back soon.
112

Jake Read's avatar
doc    
Jake Read committed
113
## [Firmware -> XMEGAs](reproduction/firmware.md)
Jake Read's avatar
Jake Read committed
114

Jake Read's avatar
doc    
Jake Read committed
115
## [Circuit Reference](reproduction/circuits.md)