<slide_break></slide_break> ## Development Patterns * *Teleop is a common term for "remote controlling" a robot* <slide_break></slide_break> ### Structure of an "idiomatic" ROS program * ROS is distributed, with nodes talking to each other * Nodes should be small and have one job * Make nodes small and simple * Use a `.launch` file to launch all the nodes at once. <slide_break></slide_break> ### Twist Messages * Recall that Topics are the names of the publish/subscribe "channels" and the content that is sent and received is a Message. * `/cmd_vel` messages tell a mobile robots 'base' to move in all the possible directions * Depending on the hardware and type of robot, it has up to 6 degrees of freedom to move * Our robots can move forward (and backward) and can spin (left or right) in place, or both at the same time. They cannot go sideways, up or down or pitch (tip forward) or yaw (tip sideways). Drones can go in all 6 * The message type sent over `/cmd_vel` is `Twist` * which includes two fields, `linear` and `angular`. * each of which has an `x`, `y`, and `z`. * Notice that Twist is generic and general, but depending on what kind of robot is receiving it, there are limits in which direction it will be told to move. * Notice also that Twist is about motion, not about location <slide_break></slide_break> ### Lab Instruction: rostopic and rosmsg * Use `rostopic` and `rosmsg` to examine /cmd_vel topic and Twist message <slide_break></slide_break> ### Keyboard Driver * Node 1 - Keyboard Driver * listens to keystrokes, interprets them * Publishes the 'semantic' commands * Node 2 - Motion Generator * Subscribes to 'semantic' commands * Publishes `cmd_vel` <slide_break></slide_break> ### Lab Instruction: Keyboard Driver * You can find `key_publisher.py` in the `samples` package. If it's not there try doing a git pull. * You will need two Terminals (plus `roscore` running somewhere) * `rosrun samples key_publisher.py` * `rostopic echo keys` * Verify that the topic is being published any time a key is pressed * All that is happening is that the letter is being sent as the content of the message * If the letter is not printable then you won't be able to see it * Questions to ponder: * Could you write a graphical interface to control the robot given what you know? * What features could you add to the basic `key_publisher.py`? <slide_break></slide_break> ### Lab Instruction: Motion Generator" * You can find `keys_to_twist.py` in the `samples` package. * Run it with key_publisher from before and then monitor both topics with two separate instances of `rostopic` echo. This will require two terminals! * Questions to ponder: * How are you going to test it? * Does it work? * How long will the robot move in the requested direction as the result of a single cmd_vel? <slide_break></slide_break> ### Lab Instruction: Generating a stream of cmd_vel * We will update the program to generate a stream of cmd_vels, around 10 per second * You can find `keys_to_twist_using_rate.py` in the `samples` package.. If it is not there try doing a git pull. * Run it and verify that it works * How would you verify that? * Try running `$ rqt_plot` to view the information in a graph * Plot `cmd_vel/angular/z` and `cmd_vel/linear/x` ## Motion Generator * Two nodes: * key_publisher: waits for user input and publishes the keys typed on topic `keys` * keys_to_twist_using_rate: subscribes to `keys` and generates cmd_vels based on decode * Comments * `cmd_vel` is published at a constant steady stream * Meaning of the keys is part of `keys_to_twist_using_rate.py` which to me is not a great Design * Better would to keep the translation of a key to an intended motion inside key_publisher * And instead of publishing the letters, publish something with semantic meaning, e.g. * stop = cmd_stop * turn left = cmd_turnleft * turn right = cmd_turnright * forward = cmd_forward * backward = cmd_backward * The encoding could be part of a class. ## Parameter Server * Being a distributed operating system means brings configuration hassles * Just about any code that is written will have some parameters, e.g. "how far from the wall should I get before trying to turn?" * We know that hard-wiring constants inside code is a very bad idea (at least for any kind of production code.) * Usual way of providing parameters is either command line arguments or Environment variables * Parameters are a ROS specific way, well adapted to the distributed nature <slide_break></slide_break> ### Parameter Server * Parameter server is 'built into' `roscore` and is a simple 'key/value' store * Private and Public Parameters * Private: node name is automatically pre-pended to parameter name to avoid name conflicts * Public: parameter name "as-is" * In this example we are running a script and at the same time assigning values to two private parameters * They will be known as `keys_to_twist/linear_scale` and `keys_to_twist/angular_scale` with values of 0.5 and 0.4 respectively * The values can be accessed from the code as follows: <pre><code class="language-language-python"> rospy.has_param('~linear_scale') # => returns True or false rospy.get_param('~linear_scale') # => returns 0.5 </code></pre> * The `~` tilde preceding the parameter name means that the parameter is "private", which means that it is prepended with the node's name * Oddly enough, the `-` hyphen preceding the parameter in the command line argument, means the same thing! * A default value can be supplied <slide_break></slide_break> ### Lab Instruction: Command Line * It is possible to set parameters directly from the command line <pre><code class="language-bash"> $ ./keys_to_twist_parameterized.py _linear_scale:=0.5 _angular_scale:=0.4 </code></pre> <slide_break></slide_break> ### Velocity Ramps * When a robot with mass is commanded to change speed or direction too suddenly * Cant defy physics so you can see misbehavior: skidding, slipping, shuddering, even damaging the motor * So we overrule the human's command and just change speed gradually and up to a maximum * Take a close look at `keys_to_twist_with_ramps.py` * Make sure you understand how the ramp works <slide_break></slide_break> ### Lab Instruction: Using Gazebo to test * Gazebo is a simulator which can simulate physical things with 3d rendering and realistic physics * In our case we configure it to simulate a tb3 and reasonable surroundings. * Note that I have not gotten gazebo to run with any stability on VMWare <pre><code class="language-language-bash"> $ roslaunch turtlebot3_gazebo turtlebot3_world.launch </code></pre> * You can also specify a different turtlebot3 model to use <pre><code class="language-language-bash"> $ roslaunch turtlebot3_gazebo turtlebot3_world.launch model:="NAME OF MODEL" </code></pre> * If you look around the turtlebot3_gazebo package (`roscd turtlebot3_gazebo`) you will see different 'worlds'. These correspond to different initial configurations of obstacles, walls, bookcases, and so on. * Don't forget that you need to have roscore running as well <slide_break></slide_break> ### rviz * Unlike Gazebo, RViz is NOT a simulator * RViz == ROS Visualization * RViz visualizes the data coming through topics onto a 3D graphical world * Note that in ROS, whenever a set of coordinates are given (x,y,z) they always are accompanied by a "frame of reference" (or a *tf*) * The *odometry* TF has an origin where the robot was powered on (or where the odometry was most recently reset) <slide_break></slide_break> ### Lab Instruction: Running RViz * You run rviz as follows with the fake robot. It comes up with a fake robot and the landscape <pre><code class="language-bash"> $ roslaunch turtlebot3_fake turtlebot3_fake.launch </code></pre> * You can zoom and rotate and move around that world * In order to run rviz with your actual robot you need two commands: <pre><code class="language-bash"> # In a terminal window: $ roslaunch turtlebot3_bringup turtlebot3_remote.launch # In a second separate terminal window: $ rosrun rviz -d `rospack find turtlebot3_description`/rviz/model.rviz </code></pre>