Cosi119a

* **Reading: <a href="/content/topics/homeworks/hw_readings_119/202_hw_119_prr10_3/">Read PRR Chapter 10 Part 3</a>**

*Reminder: Readings are your responsibility. You will be expected to come to class prepared, having read the material, and ready to participate in the discussion*

## Logistics

* What is move_base?
    * Using the map and the current estimated position (AMCL)
    * Plan a route to a destination, avoiding obstacles
* Why is an estimate needed?
    * Purely for AMCL
    * Not related to navigation
* 2D Destination?
    * Why not 3D, after all Gazebo is a 3D world
    
<slide_break></slide_break>

## What do we mean by Complex Behavior?

* Obey a high level goal by creating subgoals, and responding to real time events
* `move_base` behaviors are pretty complex
* A lot can be learned from Computer Games and the behavior of "Non Player Characters"
* Obviously an open ended question with many different approaches

<div class="discussionbox"><strong>Discussion:</strong> Which teams have an example of requiring "complex behavior", or of apparent 'inteligence'. What were you planning to do?</div>

<slide_break></slide_break>

### Example scenario

* Lets say we want to implement the following "complex behavior":

If Robot is stuck, then try the following, one after the other until the robot is unstuck: a) Conservative reset; b) clearing rotation; c) aggressive reset; d) clearing rotation. If after all of those the robot is still stuck, then abort the navigation

<div class="discussionbox"><strong>Discussion:</strong> How would you implement that?</div>

<slide_break></slide_break>

### Introduction to Finite State Machines

* [Finite Sate Machines](https://en.wikipedia.org/wiki/Finite-state_machine) also known as FSA - Finite State Automata or Deterministic Finite State Automata
* Basic and very useful way to control behaviors
* And with lots of other applications! (See Regular Expressions and Cosi 130A)
* You have seen it before, whether you identified it as an FSM or not`

<slide_break></slide_break>

### Essential features:

1. Named nodes, corresponding to states
1. Edges connecting nodes, corresponding to "inputs"
1. Initial, Final and current states

<slide_break></slide_break>

### Algorithm
1. Start in the initial state
1. Receive an input
1. Follow the one edge out of that state, given that input
1. Repeat until you get to final state

<div class="callout callout-small">
  <span class="callout-badge">Notice</span>Depending on the scenario, the states, transitions and inputs can be very different.
</div>

<slide_break></slide_break>

### Example of a real world FSM used in ROS

<slide_break></slide_break>

### Implementations

* So simple that you don't really need a package 
* But one part of the diagram can't be implemented as a basic FSM
* We can either modify it or use a more fancy kind of finite state machine

<div class="discussionbox"><strong>Discussion:</strong> Can you tell what the error is in the diagram (I didn't notice it before I actually went to implement it)</div>

<slide_break></slide_break>

### Using `transitions` python package

* You can decide whether you want to use a package or not
* My favorite package is: [pytransitions](https://github.com/pytransitions/transitions)
* And an implementation of the above FSM with pytransitions in `samples` fsm_example.py

<div class="discussionbox"><strong>Discussion:</strong> What are the tradeoffs in using a package or not?</div>

<slide_break></slide_break>

### Move Base as a Finite State Machine

<slide_break></slide_break>

### For further study

* [Finite State Machine in Python](https://www.python-course.eu/finite_state_machine.php)

<slide_break></slide_break>

## Joints and Links

<slide_break></slide_break>

<ul>
  <li>Uniform Robot Definition Format</li>
  <li>Defines a collection of links held together by joints</li>
  <li>Joints
    <ol>
      <li>Are not “visible” - all they do is to show how two links move relative to each other</li>
      <li>See <a href="http://wiki.ros.org/urdf/XML/joint">urdf documentation</a> for all the details</li>
    </ol>
  </li>
  <li>Links
    <ol>
      <li>Are “visible”</li>
      <li>Can have many other properties</li>
    </ol>
  </li>
</ul>

<slide_break></slide_break>

<h3 id="urdf-example">URDF Example</h3>

<slide_break></slide_break>

<h3 id="joint-types">Joint Types</h3>

<ol>
  <li>revolute - a hinge joint that rotates along the axis and has a limited range specified by the upper and lower limits.</li>
  <li>continuous - a continuous hinge joint that rotates around the axis and has no upper and lower limits.</li>
  <li>prismatic - a sliding joint that slides along the axis, and has a limited range specified by the upper and lower limits.</li>
  <li>fixed - This is not really a joint because it cannot move. All degrees of freedom are locked. This type of joint does not require the axis, calibration, dynamics, limits or safety_controller.</li>
  <li>floating - This joint allows motion for all 6 degrees of freedom.</li>
  <li>planar - This joint allows motion in a plane perpendicular to the axis.</li>
</ol>

<slide_break></slide_break>

<h3 id="launch-file-concerns">.launch file concerns</h3>

<slide_break></slide_break>

<h3 id="urdf-roles">URDF Roles</h3>

<ul>
  <li>Describes geometry of a robot</li>
  <li>Names various links</li>
  <li>There are others</li>
</ul>

<slide_break></slide_break>

<h3 id="robotstatepublisher">robot_state_publisher</h3>

<ul>
  <li>Looks at the urdf and publishes all the tfs which are statically tied to the base_link</li>
  <li>Using urdf, publishes <code>static_tf</code></li>
</ul>

<slide_break></slide_break>

<h3 id="jointstatepublisher">joint_state_publisher</h3>

<ul>
  <li>Looks at dynamic links (those that can move) and updates the tf as they move</li>
  <li>What would cause them to move?</li>
</ul>

<slide_break></slide_break>

<h2 class="shadow p-3 bg-white rounded">Thank you. Questions?<img class="img-fluid w-100" src="https://picsum.photos/800/100.jpg" /> <small> (random Image from picsum.photos)</small></h2>