Now we come to the heart of the experiment, socialising. It has been difficult to figure out where to start with socialising, as it is one of the most complex parts of this project, if not the most.I decided to break it into 5 questions, you’ve probably come across them before: How, what, where, when and why. As exploring these questions will take some doing I will be covering one or two per part, rather than writing a short novel!
How: Technically
How will the nodes socialise
This will require both a technical and “philosophical” answer. The technical covering the technology, how they transmit data to each other, how it should be structured, processed and interpreted, and how we can program context handling. The philosophical will cover how they understand, react to and “grow” based on the outcome of an interaction. In this part we will cover the technical side.
Data Structure
The actual storage of data will be covered in a later post, it will use a mixture of distributed ledger technology and neural network like connections. For the transition of data between each other, the nodes will be using JSON. JSON provides a very simple, easy to use “key: value” structure that makes it easy to build and read data objects. As for the actual structure, the example I outline below will be a rough draft. I may decide to add or remove various keys later.
{
id: id01, // ID of the message, most likely uneccessary
sId : id001, // The ID of the sender
rId: id002, // The ID of the recipient
txId: id001, // The Transaction id
data: "Hello id002, how are you", // The data being transmitted
ts: 2017-11-19T16:18:05+00:00, // Timestamp of sent time
hash: 627cd62956d6d46b1c7f8d895abeb48f // MD5 Hash of data for checksum
}
As I will be programming this project in C, I needed to find a JSON implementation for C. A brief initial search lead me to find JSMN. Which is a “minimalistic JSON parser in C” specifically for “resource-limited projects or embedded systems”.
Handling context
This is really a mixture of both technical and philosophical. I am absolutely certain that this will change drastically over the course of the project as it becomes clearer exactly what the context is… in future contexts… However, I am of the mind that it is always better to throw something out there, even if it isn’t that good. Things only progress past rubbish when revised, so here goes.
Whenever a node is coming up with a response, it should take into account the whole of the current conversation and any recent information it has received that could affect the way it responds. This will have to be within reason due to current hardware restrictions, otherwise it will get to the point where a node is taking weeks to think of a response, and that’s just too human! This will make use of the neural network like connections that I mentioned earlier.
That’s the brief description, I think it is enough for the moment as it gives a basis to work from. It doesn’t make drastic assumptions but allows the definition to grow during development.
Transmission
Initially I will experiment with BLE (Bluetooth Low Energy) to see how the connectivity is affected by the placement of the nodes and what kind of energy draw it uses in comparison to WiFi. Of course this should be drastically less. It is also possible that nodes may not be able to connect to some others due to placement blocking their signals. To resolve this, a node might need to pass the transmission through another node. This could invoke all kinds of interesting events, as the node being used as a repeater has the opportunity to manipulate the data. Something to explore more later.
To actually transmit, the nodes will have a list of contacts that they can communicate with. If they are responding to a message, they use the sender ID from that transmission to pull the address they need to communicate with from the list. Then they build their response, as outlined in Handling Context section above, and send it to the other node.
Receiving, Processing and Interpreting
When a transmission is received, the node will store it and begin to process and interpret it. This interpretation will be based heavily on the nodes characteristics and will influence the response it creates. So each node should store a received transmission, an interpretation and a response. The data in the transmission will have an effect on the nodes emotions, in turn this will affect the interpretation and response.
The ESP32 module has two processors, one dual core chip and one ULP coprocessing chip (Ultra Low Power). I would like to make use of the ULP chip where possible to increase the battery life. So, when the nodes aren’t doing any heavy processing it switches to the lowest power mode it can. However, in this state it still needs to keep track of external influences, heat and light, and listen for incoming transmissions. A quick digression here, I would also like to see how I could give nodes the ability to choose how fast they want to process something, then based on that decision use the main CPU or the ULP chip. Additionally, I need to learn more about the wake up capabilities of different power modes and explore whether adding an ATTiny to offload certain tasks, would be useful.
In the next post: How: Philosophically.
Be First to Comment