Local
Design > Protocols
Local Protocols
Nodes are hard wired to one another in a tree-like heirarchical network structure. Routing modules (HERE) provide addressability and end modules have only a single communications port, TX and RX. Details are HERE.
The physical connections are specific to a specific build but the network can be mapped by a supervisory, command or monitor module. Routing modules treat all TX/RX pairs the same. The TX/RX pairs are identified by an ASCII character such as "1", "2", "A" or "B" but no assumption of priority is assumed from the designation. Processing of messages is purely first come first served. Garbled messages and missed messages are simply ignored.
Local protocols and other protocols are not really different. But interaction at the supervisory or control level is not required. Messages only need to route "up" the heirarchy as far as needed to accomplish the purpose of the message. This example will perhaps illustrate the idea. If the thumb needs to know the position of the index finger the query message only needs to route to the forearm. The shoulder, neck, backbone or whatever do not need to receive, repeat or process the interaction. This "short circuit" process is the "local protocol".
Robot DHQ protocols and have to do with communications between Robot DHQ logic nodes. Communications protocols are coded into the router module and the servo module and need to be understood for the maker to control, extend and modify the modules and create new compatible modules.
The message formats and encoding are also covered here. Messages are composed of serial sequences of human-readable ASCII characters.
A basic request and response or client-server model is used. Any node can send a request or respond to a request. The requesting node is the client and the responding node is the server. Router modules may become overloaded but data collisions are not possible in this network architecture. Details of the network architecture are HERE. Details of the cable system are HERE.
The first character of all requests is the module type of the server.
Modules only process messages intended for modules of their type. The first character of a request is a module type. The first character of a request to be served by a router module will be "R". The first character of a request to be served by a server module is "S". As additional modules are defined this table can be extended.
| Module Type | Required Message Prefix Character |
| Servo Module | S |
| Router Module | R |
When using someone else's code you may end up with more than one type of server module, etc. To allow for this the second character in a request message can be used. The second character in a request will be an ASCII character such as "1", "a" or "Z". This allows for as many as 62 versions of a particular module type.
The next three characters identify a command. The next character is "," (a comma) if the command has an argument or parameter. The command, argument or parameter is terminated by an ASCII carriage return (CR) or linefeed (LF) character. The maximum length of a command should typically be less than 15 characters. The average length of a command should be less than 6 or 7 characters.
The average response should be even shorter. Most responses should be a single character followed by an ASCII carriage return (CR) or linefeed (LF) character.