An Overview and Strategic Look Forward

LRVC PROTOCOL

THE LRVC NETWORK

TOPOLOGIES

THE PROTOCOL - OVERVIEW

The LRVC Protocol provides a framework for communications between a Virtual Controller and an LRV. The LRVC Protocol has been designed to be flexible enough to accommodate a diverse set of functionalities in an LRV yet structured enough to yield a fair amount of code re-use between LRV implementations.

PROPERTIES

Android Compatible

Extendable

Robust UI Support

Video Streaming

Multiple Users

Secure

THE PHASES

1. Connection Phase - This phase is responsible for the security and resource allocation of the LRVC Server along with providing services for the Virtual Controller to provide a User with a selection screen of LRV options.

2. Configuration Phase - This phase is responsible for the configuration of a Virtual Controller. It populates the Virtual Controller with a standard interface of Standard Objects and a unique set of custom objects called Non-Standard Objects. These objects all have a known interface.

3. Control Phase - This phase is responsible for synchronously distributing opcodes (aka commands) to an LRV at the rate of 10Hz. Additionally, it wraps and transports the LRV’s feedback as Status Messages back to the Virtual Controller at a rate of 10Hz. Lastly, it facilitates a video feed from the LRV back to the Virtual Controller at a target rate of 20Hz.

THE CONNECTION PHASE

1.

2.

THE CONNECTION PHASE

Message Dir. Description

AccessDeniedS->C Response message that tells the Controller that it has been denied access. After this message

the communication is terminated.

AccessGrantedS->C Response message that tells the Controller that it is trusted and it can proceed. In this

response message there is a Control Port field that tells the Controller which TCP port has been allocated as its Control Port.

GetKnownVehiclesC->S A request by the Controller that can only be facilitated on the Controller’s own Control port.

It initiates a sequence of responses that tell the Controller which vehicles are active and controllable.

NoKnownVehicleS->C A response to a GetKnownVehicles request that tells the Controller that there are no

controllable vehicles at this time.

KnownVehicle

S->C A response that contains information about a vehicle that is controllable. The response contains a small bitmap picture of the vehicle and a description of its functions that can be displayed to the User. Also, the response implicitly implies that there are additional vehicles that are controllable and additional KnownVehicle and LastKnownVehicle responses are coming.

LastKnownVehicle

S->C A response that contains information about a vehicle that is controllable. The response contains a small bitmap picture of the vehicle and a description of its functions that can be displayed to the User. Also, the response implicitly implies that this is the last vehicle that is controllable.

VehiclesReceivedC->S A response from the Controller to the Server dictating that all of the KnownVehicle and

LastKnownVehicle requests have been received properly.

THE CONNECTION PHASE

THE CONNECTION PHASE

Status:

The Server has verified the Controller is trusted

The Controller has established its own unique Control Connection with the Server

The User has Selected a Vehicle to control

THE CONFIGURATION PHASE

3.

4.

THE CONFIGURATION PHASE

Message Dir. Description

GetObjectsC->S This message is issued by the Controller after a user has selected a vehicle to control. It

requests any non-standard objects that need to be placed on the “Virtual” Controller.

NoKnownObjectsS->C A response to a GetObjects request that tells the Controller that there are no non-standard

objects that need to be added to the virtual controller.

KnownObject

S->C A response that contains information about a non-standard component that will be on the Virtual Controller. The response contains various details as to how the object will be placed on the controller and how the object will be interfaced to (a.k.a. its bindings). The bindings include what opcodes that the object can issue and what bytes can be received by the object. Also, the response implicitly implies that there are additional non-standard objects that are going to be placed and additional KnownObject and LastKnownObject responses are coming.

LastKnownObject

S->C A response that contains information about a non-standard component that will be on the Virtual Controller. The response contains various details as to how the object will be placed on the controller and how the object will be interfaced to (a.k.a. its bindings). The bindings include what opcodes that the object can issue and what bytes can be received by the object. Also, the response implicitly implies that there are additional non-standard objects that are going to be placed and additional KnownObject and LastKnownObject responses are coming. Also, the response implicitly implies that this is the last non-standard object to be placed.

ControllerConfigured

C->S A response from the Controller to the Server dictating that all of the NoKnownObject, KnownObject and LastKnownObject requests have been received properly. It signals that the “Virtual” Controller has finished being configured.

THE CONFIGURATION PHASE

THE CONFIGURATION PHASE

Status:

The Controller is fully configured to a unique Vehicle

The Controller is connected in a basic fashion with the Vehicle

The Server now locks the Vehicle so no other Controllers can operate it

THE CONTROL PHASE

5.6.

7.

THE CONTROL PHASE

Message Dir. Description

ControlC->S This message is issued by the Controller every 10Hz indicating all of the opcodes that were

“active” in the last 100 ms.

Status

S->C A response to every Control message that has been received. This message also buffers various events and feedback as Status instances and includes them as a list. The Status Instance contains a target GUI Component on the controller and a byte-stream that will be processed by the GUI component. NOTE: Only CustomLRVCObjects may or certain special Standard Objects may process these byte streams.

VideoStreamDisabled

S->C A simple response message indicating that a video stream can not be sent to the Controller. This allows the Controller to disable all Video Streaming software gracefully.

VideoStreamEnabled

S->C A simple response message indicating that a video stream is ready to send to the Controller. This allows the Controller to enable all Video Streaming software and handle RTP Video Snippets at a 20 Hz rate.

RTP Video Snippets S->C A section of video that uses UDP wrapped implementation of the Real Time Protocol, RTP.

THE CONTROL PHASE

THE CONTROL PHASE

Status:

The Vehicle is now streaming live video back to the Controller

The vehicle is now streaming event information back to the Controller

The Controller can fully control the Vehicle

THE DETAILS

For information detailing the structure of the messages we talked about please refer to the LRVC Protocols Doc.

CONTROLLER OBJECTS

FIRE

Obj1.classObj1.class

Obj1.classObj.class

Obj.classObj.class

Standard ObjectsCustom Objects

Obj.class

CONTROLLER OBJECTS

Obj.class

CustomLRVCObject Interface

getOpcode()

public boolean wasActivated()Used internally to aggregate activated objects

giveResponse()

“Speed 8mph” 0xA3

CONTROLLER OBJECTS

FIRE

0x11

0x07

0x06 0x0A 0x10 0x0C 0x01

NOTE: Opcodes are made up

Command Msg

CONTROLLER OBJECTS

FIRE

NOTE: Responses are made up

Status Msg

(3ft, 2ft)

“No Events”

0x2F

Video Stream

THE BIG PICTURE

The basic idea is that the protocol allows extension and custom implementation through creating custom GUI objects (Java objects that contain a known “CustomLRVCObjects” interface), serializing them through the standard Java library, and interfacing them through the controllers GUI. Thus, the custom implementation is achieved not by modifying the LRVC Protocol but by adjusting the bindings of these GUI components.

HOW TO IMPLEMENT LRVC

Design an extension of the Standard Controller that accommodates your needs

Create you’re the opcodes and responses in your interface

Create and upload your Vehicle’s picture, description, custom objects, gui layout details, and MAC address to the Server

INTERFACE TO LRVC SERVER

STEPS FORWARD

Need help making this.

One team makes the Android Controller

Other team makes the Server and works on Video Streaming. (No RTP)

Weekly Meetings for those in charge of making this.

Goal of 5 weeks to complete this.

ADDITIONAL PROBLEMS

What should be the Standard Controller?

Should the communication to the Vehicle’s embedded system be synchronous at 10hertz or asynchronous?

GUI Layouts are harder in Android vs. Java. I’m not an expert in this category.

Should we have the layouts be Grid specific or try to make custom main.xml android layouts per controller?

QUESTIONS