Robobot bridge: Difference between revisions

From Rsewiki
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 2: Line 2:


== Robobot_bridge ==
== Robobot_bridge ==
The robobot_bridge is a communication interface that handles communication between the clients and (most of) the robot hardware.
Main features are:
* Interface with REGBOT hardware (motors and sensors)
* Interface with a gamepad (joystick) - e.g. manual control of the robot.
* interface to a small display (8 lines each 20 characters).
* interface to clients, e.g. REGBOT GUI and mission control application.


[[File:robobot_bridge_blocks.png | 600px]]
[[File:robobot_bridge_blocks.png | 600px]]


The Robobot_bridge is a link between the low-level robot hardware REGBOT, the remote control gamepad and the small status display.
The Robobot_bridge links the low-level robot hardware REGBOT, the remote control gamepad and the minor status display. The display and gamepad are in the new version moved to Regbot.


There are three interface modules - one for each of the interfaces, these handles the direct communication with the device.
There are three interface modules - one for each of the interfaces; these handle 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.
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 REGBOT is already clear text line-oriented and communicates two ways - as two independent channels; in and out.


=== automatic start ===
=== Automatic start ===


Robobot_bridge is started from the startup script /etc/rc.local, and thus need a reboot to start the new version,
Robobot_bridge is started from the startup script "start_bridge.sh", this script is called at reboot as a "Cron" job.


- or start it manually (is also better for debugging, as it has some on-line help (type help after start):
- or started manually (is also better for debugging, as it has some on-line help (type help after start):
  sudo pkill robobot_bridge
  sudo pkill bridge
  cd ~/robobot_bridge/build
  cd  
  sudo ./robobot_bridge
  ./bridge


===Bridge===
===Bridge command line===


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 command line (when started in a console) can issue commands and view the bridge's status.
The bridge handles these extra keywords and any special commands related to the bridge itself.
This feature is primarily for debugging.


The bridge also handles the commands that can be input from the console (if the bridge is started from a console).
The bridge handles single-character commands:
 
The command-line single-character commands are handled by the bridge:


  Robobot_bridge command-line commands:
  Robobot_bridge command-line commands:
Line 38: Line 46:


  # Robobot_bridge help:
  # Robobot_bridge help:
  # Commands are all single line text staring with a keyword
  # Commands are all single-line text starting with a keyword
  #    (up to 6 characters) followed by text or numbers:
  #    (up to 6 characters) followed by text or numbers:
  # Main topics:
  # Main topics:
  #    robot      Sends all rest of the line to the robot, see 'robot help' for options
  #    regbot      Sends the rest of the line to the robot; see 'regbot help' for options
  #    bridge      See 'bridge 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
  #    client      See 'client help' for options
  #    q          quit
  #    q          quit
Line 50: Line 57:
  # All lines starting with '#' are assumed to be comments
  # All lines starting with '#' are assumed to be comments
  # All commands are stored as a data item with a keyword as ID
  # All commands are stored as a data item with a keyword as ID
  # All data items has reserved subcommands, see:
  # All data items have reserved subcommands, see:
  #    item h      Help for data item 'item'
  #    item h      Help for data item 'item'


The item help looks like:
>>regbot:pose help
# help for special second parameter:
#  get        Gets the value of the data item
#  meta        Gets 'key meta r name vs s name p description': r=responder, vs: 0=val 1=seq, s=source, p=priority
#  subscribe p        Set subscription 0=none, -1=all updates, else interval in ms
#  onupdate p c        Set onUpdate action 0=none, -1=all updates, else interval in ms; c=action string
#  status      Shows status for the item (updates and subscribers)
#  name xxx    Sets name or description for the data item
#  logopen    Opens a (new) logfile and logs all updates with timestamp (key.txt)
#  logclose    Closes logfile (if open)
#  help        This help


=== Handler ===
=== 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.
The handler receives line-oriented text messages, starting with a text keyword or character. A number of parameters (text or numbers) and all space-separated terminated with a new-line character.


An example message is
An example message is
  robot log get
  regbot:pose logopen 
iron 1
This command starts logging the pose interface from the Regbot (to /home/local/log_20230202_102432.834/regbot_pose.txt)
   
   
This first command is a request to the logged data from the robot and is preceded with the extra keyword 'robot'.
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 is notified.
The second command turn on the IR distance sensors.
If the message type is handled before, then the data item is updated, and the specific handler is notified.
 
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 sourcecode may be needed to establish the source (in the file command.cpp about line 415:
 
415 void sendHartBeat()
416 {
417  const int MRL = 35;
418  char reply[MRL];
419  snprintf(reply, MRL,  "hbt %g %g %d %d %d %lu\r\n", missionTime, batVoltInt * batVoltIntToFloat,
420          control.controlActive, control.missionState, remoteControl, controlUsedTime[2] / (F_CPU/1000000));
421  usb_send_str(reply, false);
422 }
 
 
Log data from the 'log get' command is also line-oriented and each line is send as a separate message. The lines start with either '%' (the description lines) or a number (the timestamp). This data line is prepended with 'logdata' by the handler and handled as all others, and it is up to the client to strip the added keyword 'logdata' as needed.
 
=== O-Led display ===
 
There is a specific handler for the O-Led display.
 
The O-led display gets updated at every heartbeat command, this will update with battery voltage, robot name and the IP addresses.
There are 8 lines on the O-Led display, each up to 20 characters.
 
The default leaves most lines will empty:
 
0 11.9 solvej
1 192.168.2.85
2
3
4
5
6
7
 
Line number 1 is updated if the robot is powered.
Line 2 and 3 may show the IP addresses obtained on a cabled network or from a wifi connection.
 
The remaining lines may be used as status using an 'oled' command
 
So the commands:
oled 3 Control manual
oled 7 in mission 27 tunnel
 
gives the display


0 11.7 solvej
1 192.168.2.85
2
3 control manuel
4
5
6
7 in mission 27 tunnel


The first lines can be overwritten too, but an 'oled clear' will bring the default display back.
=== Gamepad ===
[[File:logitech-gamepag-annotated.png | 600px]]
The gamepad can enable manual override to a mission and the button presses and values can be used in a mission too.
==== Manual override ====
When button 9 is pressed (Logitech logo) manual override and automatic mode will be toggled.
When in manual override mode the axis 4 and 5 (the right knob) is used to control speed and turn.
Button 6 is used to disable speed limitation. No other buttons or axis are assigned any function in the bridge.
==== Gamepad messages ====
The gamepad maintains a message type as (send a 'joy get' or 'joy subscribe 3' to get message updates)
joy 1 0 8 11 0 -2 -32767 0 -2 -32767 0 0 0 0 0 1 0 0 0 0 0 0 0
With the following parameters
joy - keyword (joystick)
1      Joystick is alive
0      1 = manual control, else 0
8      Number of axis
11      Number of buttons
0 -2    Value for axis 1 and 2 (left knob)
-32767  Value of axis 3
0 -2    Value of axis 4 and 5 (right knob)
- 31767 Value of axis 6
0 0    Value of axis 7 and 8
0 0 0 1 0 0 0 0 0 0 0 the 11 button values - button 4 (yellow) is pressed


=== Port server ===
=== Port server ===
Line 212: Line 93:


All communication is in clear text and line-oriented.
All communication is in clear text and line-oriented.
On connection the bridge will send the following message
On connection, the bridge will send the following message


  # Welcome to REGBOT bridge - send 'help' for more info
  # Welcome to REGBOT bridge - send 'help' for more info


It will start with a '#' to indicate that this is just for information.
It will start with a '#' to indicate that this is just for information.
All help text and other information and debug messages will be sent starting with the '#' character as the first character.
All help text, other information, and debug messages will be sent starting with the '#' character as the first character.


Sending a 'client help' will return the special socket server help:
Sending a 'client help' will return the special socket server help:
Line 225: Line 106:
  #    help: This help text
  #    help: This help text


And the command 'client list' gives something like this:
The command 'bridge sources' gives a list of data source devices; like this:


  # Client list requested from client 4
  >>bridge sources
# client list (running=1 with 6 clients where 3 is active, poll loops=1593)
%% source list: is active, source:dev, [params]*
#    client 1, active=1, IP=127.0.0.1, rx=69, tx=1572, secs=35.369
source -4 ini:dev 1 has no data yet
#    client 4, active=1, IP=192.168.2.225, rx=7, tx=44, secs=12.811
Hostname: Oscar
#    client 5, active=1, IP=192.168.2.225, rx=1, tx=2, secs=5.395
source -3 bridge:dev 1 Oscar:24001 1 9 46.251 0 0
source -5 console:dev 1 has no data yet
source -3 gamepad:dev 0 /dev/input/js0 0 0 0 0 0
source -1 ros:dev 1 has no data yet
source -1 host:dev 1 has no data yet
source -2 regbot:dev 1 /dev/ttyACM0 25751 0 158 0 0
source -2 ttyACM1:dev 0 /dev/ttyACM1 0 0 0 0 0
source 0 socket00:dev 0 has no data yet
source 1 socket01:dev 0 has no data yet
source 2 socket02:dev 1 has no data yet


Where in this case 6 clients have ever been connected and 3 is still active. In this case, client 1 is the mission application running on the Raspberry Pi with IP 127.0.0.1, and have been open for 35 seconds.
In this case 3 clients (source 0, 1 and 2) connection 3 (source 2) is still active.
Client 4 is a REGBOT GUI application on another PC. Client 5 is a Putty session on the same PC.


This function is intended to see if someone else - by accident - is fiddling with the robot.
This function is intended to see if someone else - by accident - is fiddling with the robot.


These functions can be accessed by e.g. the debug tab in the REGBOT GUI, or in a PUTTY session.
== Data logging ==
 
Logged files can be displayed in MATLAB using a script like this
 
ir = load('log_irdist_20200105_133333.297.txt'); %
h = figure(300)
hold off
plot(ir(:,1) - ir(1,1), ir(:,2));
hold on
plot(ir(:,1) - ir(1,1), ir(:,3));
grid on
grid MINOR
axis([5,12,0,1])
legend('IR 1 distance', 'IR 2 distance','location','southwest')
xlabel('sec')
ylabel('distance [m]')
saveas(h, 'ir1-ir2.png')


== Doxygen description ==
The filename depends on the interface.
The first column is the timestamp, and to avoid extremely high numbers on the time axes, the first-time value is subtracted from the plot.
And in this case, the plot shows:


An automated software documentation is available here: hppt://not_there_yet.dk
[[File:ir1-ir2.png | 400px]]


This documentation is not very clear, and you would probably not want to make major changes.
The plot shows longer distances (IR2) have more noise than shorter distances (IR1).
In this case, the drive is started by an IR2 distance less than 0.3m (at 6 seconds); hereafter, the robot moves, and the IR 1 distance (looking right) sees different obstacles.

Latest revision as of 13:12, 2 February 2023

Back to robobot

Robobot_bridge

The robobot_bridge is a communication interface that handles communication between the clients and (most of) the robot hardware.

Main features are:

  • Interface with REGBOT hardware (motors and sensors)
  • Interface with a gamepad (joystick) - e.g. manual control of the robot.
  • interface to a small display (8 lines each 20 characters).
  • interface to clients, e.g. REGBOT GUI and mission control application.


The Robobot_bridge links the low-level robot hardware REGBOT, the remote control gamepad and the minor status display. The display and gamepad are in the new version moved to Regbot.

There are three interface modules - one for each of the interfaces; these handle 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 REGBOT is already clear text line-oriented and communicates two ways - as two independent channels; in and out.

Automatic start

Robobot_bridge is started from the startup script "start_bridge.sh", this script is called at reboot as a "Cron" job.

- or started manually (is also better for debugging, as it has some on-line help (type help after start): 

sudo pkill bridge
cd 
./bridge

Bridge command line

The bridge command line (when started in a console) can issue commands and view the bridge's status. This feature is primarily for debugging.

The bridge handles single-character commands: 

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 starting with a keyword
#     (up to 6 characters) followed by text or numbers:
# Main topics:
#     regbot      Sends the rest of the line to the robot; see 'regbot help' for options
#     bridge      See 'bridge help' for options
#     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 have reserved subcommands, see:
#     item h      Help for data item 'item'

The item help looks like: 

>>regbot:pose help
# help for special second parameter:
#   get         Gets the value of the data item
#   meta        Gets 'key meta r name vs s name p description': r=responder, vs: 0=val 1=seq, s=source, p=priority
#   subscribe p         Set subscription 0=none, -1=all updates, else interval in ms
#   onupdate p c        Set onUpdate action 0=none, -1=all updates, else interval in ms; c=action string
#   status      Shows status for the item (updates and subscribers)
#   name xxx    Sets name or description for the data item
#   logopen     Opens a (new) logfile and logs all updates with timestamp (key.txt)
#   logclose    Closes logfile (if open)
#   help        This help

Handler

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

An example message is 

regbot:pose logopen

This command starts logging the pose interface from the Regbot (to /home/local/log_20230202_102432.834/regbot_pose.txt)

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 is notified. If the message type is handled before, then the data item is updated, and the specific handler is notified.


Port server

The port server will open for connections on TCP/IP port 24001.

The server will open a new client connection for each connection. Up to 20 clients can be served.

All communication is in clear text and line-oriented. On connection, the bridge will send the following message 

# Welcome to REGBOT bridge - send 'help' for more info

It will start with a '#' to indicate that this is just for information. All help text, other information, and debug messages will be sent starting with the '#' character as the first character.

Sending a 'client help' will return the special socket server help: 

# Socket server help:
#     list: Gives a list of active clients
#     help: This help text

The command 'bridge sources' gives a list of data source devices; like this: 

>>bridge sources

%% source list: is active, source:dev, [params]* source -4 ini:dev 1 has no data yet Hostname: Oscar source -3 bridge:dev 1 Oscar:24001 1 9 46.251 0 0 source -5 console:dev 1 has no data yet source -3 gamepad:dev 0 /dev/input/js0 0 0 0 0 0 source -1 ros:dev 1 has no data yet source -1 host:dev 1 has no data yet source -2 regbot:dev 1 /dev/ttyACM0 25751 0 158 0 0 source -2 ttyACM1:dev 0 /dev/ttyACM1 0 0 0 0 0 source 0 socket00:dev 0 has no data yet source 1 socket01:dev 0 has no data yet source 2 socket02:dev 1 has no data yet

In this case 3 clients (source 0, 1 and 2) connection 3 (source 2) is still active.

This function is intended to see if someone else - by accident - is fiddling with the robot.

Data logging

Logged files can be displayed in MATLAB using a script like this 

ir = load('log_irdist_20200105_133333.297.txt'); % 
h = figure(300)
hold off
plot(ir(:,1) - ir(1,1), ir(:,2));
hold on
plot(ir(:,1) - ir(1,1), ir(:,3));
grid on
grid MINOR
axis([5,12,0,1])
legend('IR 1 distance', 'IR 2 distance','location','southwest')
xlabel('sec')
ylabel('distance [m]')
saveas(h, 'ir1-ir2.png')

The filename depends on the interface. The first column is the timestamp, and to avoid extremely high numbers on the time axes, the first-time value is subtracted from the plot. And in this case, the plot shows:

The plot shows longer distances (IR2) have more noise than shorter distances (IR1). In this case, the drive is started by an IR2 distance less than 0.3m (at 6 seconds); hereafter, the robot moves, and the IR 1 distance (looking right) sees different obstacles.

Retrieved from "https://rsewiki.electro.dtu.dk/index.php?title=Robobot_bridge&oldid=6122"