Remote-side Assistance

What

Remote-side Assistance is a TeleroboticsModule that sits between Uplink Communication and the Vehicle/Robot Model. It is the last stage that can inspect, transform, or drop a command before the vehicle executes it — right up to the moment of execution — and the first stage in the loop that runs on the robot side, after the uplink delay. Like Operator-side Assistance (uplink), it's optional: a study that has nothing to add here leaves the field empty and a released command goes straight to the Vehicle/Robot Model. What sets it apart is that it can also read the robot's current local observations — the latest robot-side snapshot, such as pose, terrain, or sensor state — before deciding what to do with a command.

Concretely, it is UplinkRemoteSideAssistanceModule, an abstract class in Unite.Kernel (Assets/UNITE/Kernel/Uplink/UplinkRemoteSideAssistance.cs). It uses the same package-processing shape as Operator-side Assistance, plus one addition only this side of the delay needs: a second receive path, ReceiveObservation, and a read method, TryGetLatestObservation — both covered under Contract below.

Why

DR5 does not treat assistance as one slot. The review found shared control, safeguarded execution, delay compensation, and obstacle avoidance recurring at a specific point: after a command has crossed the uplink delay, but before it reaches the vehicle. That is a different position in the loop than Operator-side Assistance (uplink), which never sees the delay or any remote state at all. Giving that position its own module turns it into an explicit, reportable configuration choice: did this study apply obstacle avoidance, shared control, or delay compensation on the robot side, and exactly what did it read to decide? Without a dedicated module, that logic would otherwise be folded into the vehicle controller.

The contrast that matters for study design: Operator-side Assistance (uplink) acts before the command crosses the delay; Remote-side Assistance acts after the delay, using the robot's current state. That capability comes from TryGetLatestObservation. Whatever it returns is the robot's current state — not the state the operator was looking at when they issued the command, and not the state at the moment the command was released either, but whatever Remote Observation & State Capture last sampled locally, without crossing any delay. That is what lets this stage react to terrain, obstacles, or vehicle state that has changed since the operator acted — something Operator-side Assistance cannot structurally do.

The module is optional; the dependency is not implied. Assigning a concrete implementation here does not, by itself, wire up any sensor or state feed — an implementation declares what it reads (a stream id, typically), and the study is responsible for making sure something actually publishes to that stream through Remote Observation & State Capture. See Config.

How

The path a released command takes, and where local observations join it:

A delayed command can therefore be checked against the robot's current situation before it is applied.

Every tick, the Kernel drains whatever released command packages arrived from Uplink Communication and calls TryProcessPackage once per package, in order, with that tick's timestamp — identical in shape to Operator-side Assistance's contract:

protected abstract bool TryProcessPackage(
    Package package,
    double timestampSeconds,
    out Package output);

Return false to drop the package for this tick — no command reaches the Vehicle/Robot Model at all. Return true with a package to publish it downstream; the Kernel only checks that the returned package isn't null, exactly as it does for Operator-side Assistance. Failing that check logs an error and drops the tick.

Reading local state is a separate, event-driven path, independent of the command path above. Remote Observation & State Capture continuously maintains a snapshot of the robot's surroundings — pose, terrain, sensor readings, whatever a study configures — and makes the latest snapshot available to this stage without it ever crossing the uplink delay. Concretely, that snapshot arrives through this module's ReceiveObservation, and an implementation reads it back through TryGetLatestObservation. Remote Observation & State Capture refreshes and publishes that snapshot before this module processes commands, so whatever TryProcessPackage reads is that tick's freshly captured local state, not anything that has crossed the uplink.

Boundary

Contract

This contract matters when writing a new assistance technique — configuring a study that already has one is covered under Config below. Like Operator-side Assistance (uplink), this stage has no dedicated contract type to subclass for the command path — it reads and writes the same Package envelope, documented in full on the Operator-side Assistance (uplink) page. What it adds is a second, read-only path for local state.

public abstract class UplinkRemoteSideAssistanceModule
    : TeleroboticsModule, IPackageSource, IPackageConsumer
{
    public event Action<Package> PackageProduced;

    public void ReceivePackage(Package package);

    /// <summary>
    /// Receives a locally captured observation package. This is a separate
    /// input from command packages: a pre-control refresh is available for
    /// the current assistance step, while the post-control refresh becomes
    /// the observation available on the next control tick.
    /// </summary>
    public void ReceiveObservation(Package package);

    /// <summary>
    /// Reads the latest locally captured observation for a stream. The result
    /// is the observation available at the remote control tick, not a delayed
    /// downlink package.
    /// </summary>
    protected bool TryGetLatestObservation(
        string streamId, out Package package);

    /// <summary>
    /// Reads and type-checks the latest locally captured observation.
    /// </summary>
    protected bool TryGetLatestObservation<TObservation>(
        string streamId, out TObservation observation)
        where TObservation : class;

    protected abstract bool TryProcessPackage(
        Package package,
        double timestampSeconds,
        out Package output);
}

TryGetLatestObservation returns the latest available local snapshot for a given stream id — whatever Remote Observation & State Capture most recently published, or nothing if it hasn't published yet. An implementation declares which stream it depends on, typically as a serialized field, then reads back the latest snapshot for that stream by id, exactly like Uplink Communication's channels do for commands. A generic overload adds a type check on top: it returns that same snapshot only if its payload matches the requested TObservation, so an implementation doesn't have to pattern-match the payload itself. If nothing has published to that stream yet, or the study never wired a matching source at all, the call simply returns false — there is no error, because an unconfigured dependency is a valid state before the first observation arrives, not a failure.

Examples

The baseline passes commands through; the route guard reads local pose observations before the vehicle update.

public sealed class SlopeBoundaryGuard : UplinkRemoteSideAssistanceModule
{
    [SerializeField] private MeshCollider terrain;
    [SerializeField] private Transform vehicle;
    [SerializeField, Range(0f, 90f)] private float maximumSlopeDegrees = 21.80141f;

    // Reference BoundaryDetection thresholds: a rise of more than 8 cm over a 20 cm
    // look-ahead is treated as a wall rather than a navigable bump.
    private const float CheckDistance = 0.2f;

    public float MaximumSlopeDegrees => maximumSlopeDegrees;

    protected override bool TryProcessPackage(Package package, double timestamp, out Package output)
    {
        output = package;
        if (!terrain || !vehicle) return true;
        if (!(package.Payload is WheelVelocityCommand command)) return true;

        // Only translational commands can drive into a wall; ignore pure rotation.
        float commanded = (command.RequestedLeft + command.RequestedRight) * 0.5f;
        if (Mathf.Abs(commanded) < 0.001f) return true;

        if (!TryGetObservedPose(
                out float px,
                out float pz,
                out float heading))
        {
            return true;
        }
        float relativeAngle = commanded > 0f ? 0f : Mathf.PI;
        if (!IsWallInDirection(px, pz, heading, relativeAngle)) return true;

        // Reference behaviour on wall contact: reverse away from the obstacle instead of
        // climbing it.
        output = new Package(
            new WheelVelocityCommand(command.Input, timestamp, -command.RequestedLeft, -command.RequestedRight),
            package.SourceTimestampSeconds, package.StreamId);
        return true;
    }

    private bool TryGetObservedPose(
        out float x,
        out float z,
        out float heading)
    {
        if (TryGetLatestObservation<PosePackage>(
                EveryMoveStreams.Pose,
                out PosePackage observation) &&
            observation.State != null)
        {
            x = observation.State.Position.x;
            z = observation.State.Position.z;
            heading = observation.State.Heading;
            return true;
        }

        // The first control tick can precede the first published vehicle pose.
        // Retain the scene transform as a startup fallback only; subsequent
        // assistance decisions use the locally captured observation package.
        if (vehicle)
        {
            x = vehicle.position.x;
            z = vehicle.position.z;
            heading = vehicle.eulerAngles.y * Mathf.Deg2Rad;
            return true;
        }

        x = 0f;
        z = 0f;
        heading = 0f;
        return false;
    }

    private bool IsWallInDirection(float x, float z, float heading, float relativeAngle)
    {
        if (!TryTerrainHeight(x, z, out float currentHeight)) return false;
        float absoluteAngle = heading + relativeAngle;
        float checkX = x + Mathf.Cos(absoluteAngle) * CheckDistance;
        float checkZ = z - Mathf.Sin(absoluteAngle) * CheckDistance;
        if (!TryTerrainHeight(checkX, checkZ, out float checkHeight)) return false;
        float slopeDegrees = Mathf.Atan2(
            checkHeight - currentHeight,
            CheckDistance) * Mathf.Rad2Deg;
        return slopeDegrees > maximumSlopeDegrees;
    }

    private bool TryTerrainHeight(float x, float z, out float height)
    {
        if (terrain.Raycast(new Ray(new Vector3(x, 1000f, z), Vector3.down), out RaycastHit hit, 2000f))
        {
            height = hit.point.y;
            return true;
        }
        height = 0f;
        return false;
    }
}

Config

Remote-side Assistance is a Unity component, configured in the Inspector like the rest of a study.

1. Add a concrete assistance component to the agent, if the study uses one. Add a component such as SlopeBoundaryGuard to the same GameObject as TeleroboticsAgent. Every selected module must live on that one GameObject.
2. Assign it to the agent's Uplink Remote Side Assistance field, or leave it empty. This field isn't required — leaving it empty wires Uplink Communication straight to the Vehicle/Robot Model, exactly as described under Pass-through baseline above.
3. If the implementation reads local observations, configure Remote Observation & State Capture to publish the stream it expects. A dependency is declared by the implementation, not by the Kernel. SlopeBoundaryGuard, for instance, depends on a stream called robot-pose — a name for "the robot's current position and heading" — and that name has to match a source configured on the agent's Remote Observation & State Capture module, or the read simply never succeeds.