A distributed operating system for multiple cpus and devices in a mesh network

Projects Discussion and Showcase Product Design
1

Z-project pix
Z-project pix958×323 289 KB

Hello! I am working on a new kind of operating system for a multi-device distributed network. In the above pix you can see five devices: distance sensor, potentiometer, speaker, photocell, and servo. Inside each box is an Arduino-compatible board (Teensy 4.0), a battery pack, and a BT radio implementing a mesh network.

Each box is a standalone node: self-powered and radio connected. The network requires no installation -- the OS in each Teensy seeks out others of its kind and auto-connects into the mesh. Each box has some single device on top of it or in it, wired to the enclosed Teensy, which is preloaded with all applicable libraries for that device.

You can put the knob (potentiometer) box on your desk and the speaker box on the wall, and then from any host with BT capability (mac, pc, phone, pi, arduino, etc), issue a command like "knob.position -> speaker.frequency". Then turn the knob on your desk and hear the speaker on the wall respond in pitch. Or place the distance sensor box somewhere and the servo pointer elsewhere and do "distanceSensor -> servo.angle", and the pointer's angle in degrees will follow the sensor's output in cm. Once the command is issued into the network, the various devices will continue to run on their own, long after the issuing system is gone.

A mike, preloaded with voice recognition software could do "mike.wheneverWordHeard('abacadabra') -> speaker.beep(5 seconds) -> lock.open"! An almost infinity of devices and commands can be implemented. Each "dev.xxx" contacts the box with device "dev" and executes the preloaded "xxx" subroutine inside that box. A command like "dev1.xx1 -> dev2.xx2 -> dev3.xx3 -> etc" passes the output of each subroutine, across the network, to the input of the next. And you can invent and add your own subroutines.

After prototyping, the plan is to shrink these boxes to the size of a single small chip, which can then be placed INSIDE each device rather than in a big box beneath it. Then we will have a network of very smart components, with which to build larger projects. No software, no wiring, and a simple interface.

To watch a short video demonstration of the current (working!) system, see here:
http://www.stevebush.org/My File Clerk/WizdomResearch/TheBook/Addenda/The Z project/Video/live demo.mp4

For more complete documentation on the system go to my website, www.stevenSwift.org and click "The Z-project".

My question for you now is: am I going in the right direction? Is this a product that is needed and wanted? Your opinions are solicited.

Thanks in advance, Steven Swift.
www.stevenSwift.org

1 Like
2

I watched the video to the 16 minute mark.
Distributed systems sound great until you have roll out a firmware update to a dozen devices. Does your decentralized "operating system" do that upgrade step automatically for you, or is it a manual process for each node?

How does a node know if its firmware needs to be updated?

1 Like
3

Thanks for watching. First of all remember that you are looking at a very rough prototype, barely past an experiment or proof of concept. On the website (www.stevenSwift.org, click "Z-project"), there is 100x more info than can be shown in a demo video. If u r interested, read the documentation there.

A dozen devices? I imagine a billion devices!

We are still in development. Having a prototype system allowed me to begin experimenting with an OS for it. Let me turn it around on you. The answer to your question, "How do you do X?" could be: "How would YOU do X?".

If you have a great idea, we can use it. I have many "great" (lol) ideas myself. If you read the more complete documentation you will find a lot more info than a simple demo video can show. You are asking how the injection ports are aligned after watching a video of the car driving down the road. However, that is why I posted, to start this conversation.

For one thing, distinguish between two classes of software: the "OS" and the "functions" loaded into the device. Here is a comparison. The "core code" of a bicycle might be its frame, its OS . On it you mount many sub-assemblies (subroutines). You can change the gear assembly, the chain, the brake assembly, the tires, you can add a headlamp and turn signals, but it is the frame that holds it all together. On Z-devices, you can change ALL the functions except the core of the OS itself, which provides the ability to change those underlying functions. The OS is a very small bit of code by comparison. All the functionality is in the easily downloaded functions. The ones it comes pre-loaded with are all open source, and you are welcome to get them, modify them, add new ones, etc.

Also remember, these are all PRIMITIVE devices. A pot, a servo, a sensor. If we have a temp sensor, how many times will it need to be upgraded? All upgrades would be of the form of new functions (subroutines). If a temp sensor came with pre-loaded functions like "temp.outputTempInCelsius" and "...inFahrenheit", and suppose you wanted "...inLogScaleKelvin", you can do that easily. I don't expect many customers to want that, we'd try to pre-load all the functions we could think of in the first place, before shipping the product.

But to begin to answer your question, function number 1 on all devices is reserved for the OS. For example, I never showed how we set the name of things. "1005, 1, 3, 'myPointer' ", aka OS function 3, sets the name of device 1005 to "myPointer". Stated without numbers, that's "pointer.OS.setName('myPointer').

That names the device. Functions within the device can then be named with cmds like "myPointer.OS.setFunctionName(14,'maxAngle')", which sets the name of the 14th function in device 1005 (now named "myPointer") to "maxAngle".

OS function 8 downloads new code, something like: "myPointer.OS.8 ( 17, array of numbers)" is how we download a new function 17 into that particular device. How we convert code to an array of numbers is another story, described in another section of my website, under "WIZ and ZOZ", see "The Big Picture". It's more like a byteCode as used by the Java Virtual Machine.

This would all have to be developed, but the idea is to stick with the single mechanism of "node number , function number , args", making OS functions simply function number 1, and work just like all other functions. OS functions would include setting names of functions, retrieving them, deleting them, downloading new ones etc.

But even changing the bicycle's frame, the core code, is still possible, again, just another OS function, "device.OS.change thyself(...)".

A final comment: In the chapter "The Z-network" I describe how a Z-network can be wired and/or use BT and/or use WiFi and/or use other. If at least one node anywhere in the mesh has WiFi, and at least one node in another mesh (all with the same customer ID) has WiFi, then the two (or more) meshes join into a single larger mesh. To do this, the OS has to go thru Z-company servers. At that point, we can easily imagine OS update mechanisms. An insular mesh, wired only, or wired and BT only, would be out of luck.

And thanks for listening, I look forward to more comments, and "great" (lol) ideas are always welcome.

4

Teensy is a good choice for this work. A wireless mesh is certainly wise as well. Can they relay messages? Say unit A needs to read unit D, which is out of range. Will units B and C relay the message from A to D?

5

Agreed, er-name-not-found. I choose Teensy because, when experimenting, I want the most powerful and flexible system. I don't really need much power or speed or memory, but it's nice to have when developing the system. I have also experimented with very small Arduino-compatibles, such as the Seeed Studio XIAO line, about 1" square. But for now, Teensy is it..

Of course they hop, that is the very definition of a mesh network. A to B to C to D. This also extends range, as you noted. In my "Z-network" chapter there is much more info. The nodes can be connected by wire (like a 1-wire protocol, any number of nodes tapping into the same wire), or by BT (again, any number of nodes can tap into the same channel), or by WiFi or "other", and the nodes can mix and match these various connection types.

With WiFi the mesh can extend planet wide. If you have a mesh in one location (eg, city), and another mesh in another, both could be wired or BT'ed locally, but if at least one node in each has a WiFi, then the two meshes become one.

So yes, mesh is the way to go!

6

Please post the working code on Github, so people can take a look at it and decide for themselves whether it seems useful. A description of the protocols would be helpful, as well.

7

Seen some products in the past described as mesh that weren't. I've always been fascinated with distributed computing. I'll be paying attention.

8

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.