Navigation based on synchronized events, commands via RPC¶

Events synchronization:¶

Must be running before rsbnavigation can be used. The queue size (approxt-qs) can be increased, if no events are sent to outscope.

./bin/rsb_timesync --outscope /nao/navigation/merged --primscope /nao/camerapose/0 --supscope /nao/odometry --supscope /nao/proprioception --strategy approxt --approxt-qs 60

rsbnavigation¶

Usage: rsbnavigation [options]
options:
    -m, --mergedScope <mergedScope>                   :   merged scope (default '/nao/navigation/merged')
    -c, --camPoseScope <camPoseScope>                 :   camera pose scope (default '/nao/camerapose/0/')
    -o, --odoPoseScope <odoPoseScope>                 :   odometry pose scope (default '/nao/odometry/')
        --estimatePoseScope <estPoseScope>                :   pose estimate scope (default '/nao/navigation/estimate')
    -r, --rpcServerScope <rpcServerScope>             :   scope to send rpc requests (default '/nao/navigation/server')
    -e, --eps <precision (m)>                         :   goal pose precision (default '0.05')
    -s, --maxstep <step (m)>                          :   maximal step length (default '0.1')
    -t, --table <filename>                            :   table corners file (default is no table)

Advanced parameters:
     --minPoseConfidence <conf>                       :   minimal confidence of pose estimation (default '0.7')
                                                          Smaller values of pose estimation confidence will trigger looking around.
     --initPoseConfidence <conf>                      :   initial pose estimation confidence (default '0.1')
     --mergedConfidence <conf>                        :   confidence of merged visual and odometry measurement (default '0.8')
     --odometryConfidence <conf>                      :   confidence of odometry measurement only (default '0.2'

where eps denotes the precision so that the goal is reached when the euclidean distance to the goal is less than eps and the difference in angle is less than eps * PI.
Corners of the table may be specified in a text file given via the -t/--table parameter. The format of the table file is as follows:

N
x1 y1
x2 y2
.
.
.
xN yN
xIn yIn

Where N is the number of corners (6 for the L shaped table), xi and yi, where i is in the interval [1;N], are corners coordinates. They need to be given so that x(i), y(i) and x(i+1), y(i+1) is a table edge. The last N+1^th point is a point inside the table polygon, in this scenario, it should be the point In in the figure. Dimensions are in milimeters.

Notes¶

• mergedScope must be the same as --outscope in rsb_timesync.
• camPoseScope and odoPoseScope must be the same as one of the --supscope in rsb_timesync.
• There must be no other --supscopes in the rsb_timesync.
• If table is not given, the navigation module cannot ensure safety of the robot (e.g. falling off the table)

rsbsendPose - commanding the robot¶

The robot is controlled via messages sent to rpcServerScope. Example of such program is rsbsendGoalPose.
Coordinates are in the world coordinate system. Distances are in milimeters, heading in radians.

./build/src/rsbsendGoalPose
USAGE: rsbsendGoalPose <x(mm)> <y(mm)> <phi(rad)> [<scope=/nao/navigation/goal>]

The responses from the navigation module are of type string:

• "goal reached" - self explanatory
• "cannot walk" - the rpc call to NaoQi function WalkTo failed (is the robot standing, stiffness enabled, .. ?)
• "unreachable" - the goal is outside the table polygon
• "in use" - the module is already in use (navigating the robot somewhere), wait for the previous task to be finished

Debugging info¶

Pose confidence¶

The pose confidence is computed based on Bayes probability rules (inspired by occupancy grids in mapping)

conf(k+1) = p * conf(k)/(p*conf(k) + (1-p)*(1-conf(k))),

where conf is a pose estimation confidence, expressed as probability of being confident (1=completely sure, 0=no idea where the robot is). p is an update of the confidence. When the information about pose is obtained only from odometry, p=0.2, thus the confidence decreases. When the information is both from odometry and visual localization, p=0.8 and confidence increases. The confidence is thresholded in the update function, to be in the interval [0.1, 0.9], which ensures fast reaction to p. The values of p and thresholds are hardcoded, this could be fixed in future releases.