290 likes | 366 Views
LRVC Protocol. An Overview and Strategic Look Forward. The LRVC Network. Topologies. The Protocol - Overview.
E N D
LRVC Protocol An Overview and Strategic Look Forward
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 • 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. • 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. • 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 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 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 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 Custom Objects Standard Objects Obj.class Obj1.class Obj.class Obj1.class Obj1.class Obj.class Obj.class FIRE Android Virtual Controller
Controller Objects CustomLRVCObject Interface getOpcode() giveResponse() Obj.class 0xA3 “Speed 8mph” public booleanwasActivated() Used internally to aggregate activated objects
Controller Objects 0x06 0x0A 0x10 0x0C 0x01 Command Msg 0x07 0x11 FIRE NOTE: Opcodes are made up
Controller Objects Video Stream 0x2F Status Msg (3ft, 2ft) “No Events” FIRE NOTE: Responses are made up
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
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?