Robobot bridge

Revision as of 14:22, 21 December 2019

Back to robobot

Robobot_bridge

The Robobot_bridge is a link between the low-level robot hardware REGBOT, the remote control gamepad and the small status display.

There are three interface modules - one for each of the interfaces, these handles the direct communication with the device. The exchange format is always a line-oriented clear text. The gamepad generates a status line with all switches and axes and is input only. The O-Led display takes a command text and sets the displat, this is output only. The REGBOT is already clear text line-oriented and communicates two ways - as two independant channels.

Bridge

The destination can be stated explicitly with an extra keyword in front of the regular keyword ('robot', 'bridge' or 'oled'), but most commands will be identified on the basis of the regular keyword. The bridge handles these extra keywords and any special commands related to the bridge itself.

The bridge also handles the commands that can be input from the console (if the bridge is started from a console).

The command-line single-character commands are handled by the bridge:

Robobot_bridge command-line commands:
  q: quit
  s: status of data items etc
  h: this help
  help: help for the bridge
Lines with more than one character are sent to the handler as a message.

Longer commands are sent to the handler and merged with messages from any other command, and the 'help' command shows:

# Robobot_bridge help:
# Commands are all single line text staring with a keyword
#     (up to 6 characters) followed by text or numbers:
# Main topics:
#     robot       Sends all rest of the line to the robot, see 'robot help' for options
#     bridge      See 'bridge help' for options
#     oled L xxx  Prints xxx (up to 20 chars) on line L (2..7) on oled
#     client      See 'client help' for options
#     q           quit
#     h           Console help
#     help        This help
# All lines starting with '#' are assumed to be comments
# All commands are stored as a data item with a keyword as ID
# All data items has reserved subcommands, see:
#     item h      Help for data item 'item'

Handler

The handler receives line-oriented text messages, each starting with a text keyword or character, and then a number of parameters (text or numbers) and all space-separated terminated with a new-line character.

An example message is

robot log get
iron 1

This first command is a request to the logged data from the robot and is preceded with the extra keyword 'robot'. The second command turn on the IR distance sensors.

If this is the first time the command is handled, then a data item is created in the message database. A specific handler is found for this message type and the message is stored and the specific handler notified. If the message type is handled before, then the data item is updated and the specific handler notified.

In this case, both messages are for the REGBOT, and the notified specific handler just sends everything to the REGBOT interface. The extra keyword 'robot' is not stored and not send to the REGBOT interface, it is just a hint for the destination.

All keywords are unique, messages to REGBOT and from REGBOT use different keywords. Getting data from the robot often uses a 'uXX', i.e. sending 'u4' to the robot will result in a 'rid' (robot ID) message being returned. This 'rid' message will be stored as a data item and not send to any client.

Example, sending u4:

'u4' -> 'rid 85 0.155 10 48 0.05 0.05 0 11 9.89407 6 Solvej'

In this case robot Solvej together with a number of parameters.

The client must ask for the data, either once or subscribe to changes.

To get the message the client sends:

u4
rid get

The u4 will ensure that the reply will be in the database. The 'get rid' will ensure the client gets the data.

rid 85 0.155 10 48 0.05 0.05 0 11 9.89407 6 Solvej

To avoid asking for data all the time, all data messages has a subscription service. The client could send:

rid subscribe 6

The number after the 'subscribe' keyword is the subscription type

xxx subscribe 0     stop subscription.
xxx subscribe 1     fast - as fast as possible (up to 1ms), but not faster than updates arrive.
xxx subscribe 2..4  Higher number will give slower update rate, and some updates may be missed (e.g. accelerometer data, that may be updated every milisecond from REGBOT).
xxx subscribe 5     slow updates, not faster than 6 seconds between updates.
xxx subscribe 6     All updates with high priority - mostly for semi-static values (like ID), but also for logfile, where all data are needed.

The xxx is the message keyword to subscribe to.

All clients can have individual subscription settings for each message type.

All message types can create a log-file, e.g.:

hbt logopen
hbt logclose

will open a logfile in a subdirectory with the name hpt.txt. The subdirectory will include date and time, like

log_20191221_101642.117/hbt.txt

the logfile will (in this case) look like:

% logfile for item hbt
%  Heartbeat [time [sec], battery voltage [V].
1576934042.414755 3021.97 11.973 0 0 0 212
1576934043.040314 3022.58 11.9749 0 0 0 212
1576934043.666605 3023.19 11.973 0 0 0 211
1576934044.292192 3023.8 11.973 0 0 0 211

The first column is the Unix timestamp (seconds since 1 Jan 1970), the second is the REGBOT (seconds since boot), then the battery voltage (11.973V) and some other parameters where a look into the REGBOT may be needed to establish the source.

Data from the robot is handled in the same way, but nothing is sent to any clients unless they subscribe to this specific type of data.

Log data from the previous command are also line-oriented but starts with either '%' (the description lines) or a number (the timestamp). This data line is then prepended with 'logdata' and handled as all others, and it is up to the client to strip the added keyword as needed.

Doxygen description

An automated software documentation is available here: hppt://not_there_yet.dk