Migrate to new arch

[duncanrhamill]

Migration to new architecture to enable plugging the software into a simulator.

Basic idea is to split out all hardware endpoints as separate executables, with a network link between them. This way a simulator executable can replace the physical hardware.

TODO

• [x] Design new arch
• [x] Implement network library #9
• [ ] Implement existing hardware endpoints as separate binaries
  • [x] elec_driver -> mech_exec
• [ ] Test on rover to prevent regression

[duncanrhamill]

Possible new high-level arch @UY-Scuti-Real thoughts?

[duncanrhamill]

Ok so in the diagram above the equipment servers/clients are swapped round, but I think this is a good design for the new arch. The other thing we may want to add is a generic sim_server capable of communicating more abstract data like the stuff in SUSF-Robotics-and-Software/webots_phobos_rover#5.

Equipment message definitions to come soon.

[duncanrhamill]

Making new issue to track integration with SUSF-Robotics-and-Software/webots_phobos_rover, see #10.

[duncanrhamill]

Updated arch diagram to add sim_server and fix equipment client/servers

[duncanrhamill]

Boundaries for the communication links for equipment:

• loco - Actuator angle demands, i.e. steer axis angle in radians, drive axis rate in radians/s.
• cam - Raw images acquired by each camera
• imu - TBD, but nominally acceleration vector and attitude vector in SI?

[duncanrhamill]

loco stack should be renamed mech (mechanisms) stack, so that arm actuators can be included.

[duncanrhamill]

Looking at zmq as a network abstraction layer, I think that the equipment execs can work like this:

Where the white blocks represent zmq sockets with the given message pattern (like REQ). On the client side the API exposed to the rest of the system is:

/// Send demands to the server.
///
/// Sends the given mechanisms demands to the server. If the server acknowledges the demands
/// within the configured timeout then `Ok()` is returned, otherwise an `Err()` is returned.
pub fn send_demands(&mut self, demands: &MechDems) -> Result<(), SendError>;

/// Get the latest sensor data message from the server.
///
/// If no sensor data is available `None` is returned.
pub fn get_sensor_data(&mut self) -> Option<MechSenData>;

The idea here is that the demands and sensor data are separate things with different consequences if they aren't recieved. If the server doesn't acknowledge some demands the rover may be in an unsafe state, or the server may have shutdown, in which case the rover should go into safe mode immediately. If there's no sensor data well that may not be the end of the world.

There's also the difference in how the message patterns work. The demands are a single request-response pair, the server must always acknowledge the demands that were sent to it before a certain timeout, otherwise the rover may be unsafe. On the otherhand the sensor data is simply being broadcast to the client by the server, no need for a request-response setup.

[duncanrhamill]

Milestone: mech_exec is hooked into rov_exec over the network!

Commit 8ef3198 adds a dummy mech_exec which can communicate with the main rov_exec via the MonitoredSocket zmq based networking setup.

[duncanrhamill]

Milestone: LocoCtrl now outputs MechDems structs and the mech_exec is receiving the correct data!

Commit e6aa2fe has reworked LocoCtrl and completely removed elec_driver from the processing loop.

[duncanrhamill]

Significant change to how telecommands work in commit eb3587a. While the old TCs in JSON look like this:

{
    "type": "MNVR",
    "payload": {
        "mnvr_type": "ACKERMAN",
        "speed_ms": 0.1,
        "curv_m": 1.0
    }
}

the new ones look like:

{
    "LocoCtrlMnvr": {
        "Ackerman": {
            "speed_ms": 0.1,
            "curv_m": 1.0,
            "crab_rad": 0.0
        }
    }
}

This has greatly simplified adding in new TCs and is overall a more future proof setup.

[duncanrhamill]

Milestone: CamClient now is able to recieve images from Webots!

Commit 192acaa, and the corresponding commit in webots_phobos_rover has added the image acquisition chain to both rov_exec and webots. On the webots side this is a python multiprocessing implementation, to avoid the long process of sending images stalling the sim. It should be noted that running with the "cam" cargo feature enabled should be done with the --release cargo flag, to prevent cycle overruns.

cargo run --release --bin rov_exec

[duncanrhamill]

As it currently stands most of the needed functionality has already been added. The notable exception is the MechExec. However I think it's a good idea to merge the current arch changes into the master branch and rebase devel to master so that work can begin on adding autonomy functionality. At the moment it's more than possible to do rapid development of autonomy thanks to the webots sim, so the arch change has been a success.

Final implementation of the MechExec will come when there's a reason to get the rover physically working.