Allow Plexus to work as a standalone node

[JensOgorek]

In the current PR #153, the Plexus is fully controlled by the core ESP. It will not even execute a single step without explicit instructions from the core.

The new idea is to fully drop the main → sub model for Plexus modules and let them operate as standalone Lizard nodes. This way, they can run independently without a robot brain, but still act on commands/calls received from the robot brain.

• Plexus ↔ Expander communication: To avoid collisions on serial bus (via UART with RS485) the core must control the speaking schedule and gives each Plexus its turn (introduced in Add Plexus expander module #153). Each Plexus must queue its own messages until it is allowed to speak. Communication is not only with the core, but might also happen between Plexus modules on the RS485 bus. Weather we want to switch to CAN is discussed in Communication between EPSs via CAN? (Core ↔ Plexus) #159.
• Configuration: When running standalone, the Plexus needs its own startup script — provided either by the core or directly by the user.
• Proxies: Since the Plexus works independently, it will no longer report every step with the !!-message.
• Calls: Function calls remain similar to expanders. The Plexus validates the call, returns a response, or executes the action. New: an acknowledgement message, since the general !!-transmission is no longer happening.
• Properties: Properties are managed locally by the Plexus. They can be requested and will be transmitted on the next speaking cycle (see above).
• Interrupt-style messages: Should be discussed in a separate PR if needed.
• Watchdog: Previously, the core requested all Plexus to speak, which acted as a watchdog. With the new model, both directions are possible: the core can watch the Plexus, and the Plexus can also watch the core. For example, a Plexus could stop its attached tool safely, if the core shuts down.
• OTW (over the wire) updates: Works the same as before.
• Addressing: All Plexus modules must know the IDs of other Plexus modules to communicate.

This list will be updated as we go.

[rodja]

I edited the description a bit for more clarity and added links to the referenced PRs. @JensOgorek please check if I oversimplifed anything 😁
And I'm not sure if we need "ACK" messages for this. Are they mandatory? Otherwise I suggest to extract it into a separate feature request.

[falkoschindler]

In view of PR #153 and its limitations we came up with the following concept for "standalone ESPs" on a serial bus.

---

Multiple Lizard ESPs on a single bus

Requirements

• The host can send Lizard commands to all ESPs.
• The host can request property values from all ESPs.
• The host receives core message from the coordinator ESP only.
• All ESPs can send Lizard commands to each other based on rules.
• The bus can be connected to either the core ESP directly or via an expander. (❓)
• The host can configure all ESPs.
• The host can update the firmware on all ESPs.

Aspects

Scheduling: Who is sending when?

A coordinating ESP can cycle through peer ESPs on the bus and ask them to send buffered messages.
Peer IDs are defined as part of the Lizard configuration.

Addressing: How to call Lizard commands on a specific ESP?

This is part of the protocol internal to the SerialBus module.

Initial address assignment: How is a bare ESP addressed for its first configuration?

The ESPs are configured with a minimum configuration containing a serial bus module with a given ID.
The ID is stored persistently to survive restarts.
In case a broken configuration is received causing a boot error, the ESP falls back to the minimum configuration with the stored ID.

Configuration: How to configure individual ESPs?

The SerialBus has a method to send configuration strings to other ESPs.

Updates: How to update the Lizard firmware on individual ESPs?

ESPs between host and target ESP enter a dedicated "bridge mode" to reduce transmission errors.
The host sends the binary image to the target ESP which applies it like an OTA update.

API

Defining a bus on any ESP (first argument is own ID, ID 0 indicates coordinator):

bus = SerialBus(serial, 0, 1, 2, 7)
# or:
bus = SerialBus(serial, 0)
bus.set_peers(1, 2, 7)

Sending messages to other ESPs:

bus.send(1, 'led.on()')
bus.send(2, 'button.level') # output on sender ESP: "1:button.level 0"

Configuring a peer ESP (second option would require an update to the Lizard grammar):

bus.configure(1,
    "led = Output(32);" +
    "serial = Serial(42, 43);" +
    "bus = Bus(serial, 1, 0);"
)
bus.configure(1, """
    led = Output(32)
    serial = Serial(42, 43)
    bus = Bus(serial, 1, 0)
""")

[falkoschindler]

Open questions:

• What time is needed for requesting information from a peer ESP a) when connected directly to the core ESP, or b) with a port expander in between?
• In the context of our Robot Brain and a Plexus port expander: Can we connect the bus directly to the core ESP, or do we need the expander?
• Could we eventually remove the P0 and run the Robot Brain with a single ESP?
• If the peers were connected directly to the core ESP, can we remove the bridge mode for OTW updates?