• Students are expected to work in teams by two (exceptions allowed after consultation with teacher).
• Each group is expected to work with a real robot.
• Majority of the work is planned as an individual work of the group (you can work anytime the room is available).
• Students are expected to ask - ask early, ask often.
• Teachers will be personally available during the regularly scheduled hours, otherwise over the e-mail (but don't expect answers in order of minutes)
• Charge the robot every time you stop working with it.
• Keep your source code on a version-control system (e.g. git). This way, you can remove commented-out parts of your source code that you'd like to keep “just in case”, the version control system will keep a trace of it.

• slides

• Each team is asked to implement selected algorithms presented on lectures:
  • Multi-robot motion coordination
    • slides
    • Code
    • Map
  • Kalman filter and Extended Kalman filter for localization
    • Slides
    • CZ Slides
    • Code
  • Particle filter for global localization
    • Motion model code
    • Particle filter code
    • Particle filter code for ROS
    • Slides
    • Video with motion model demonstration

To get the seminar credit, student must:

• Participate and actively work at all seminars (up to 2 absences without excuse will be tolerated),
• Create a working algorithms solving *all* the tasks,
• Present a well-written and documented source code,
• Understand the presented solution and source code (each team member).

• Log into a PC with the diskless operation system. On these systems, your personnal NFS folder will be mounted as $HOME.
• singularity shell /opt/ros ros.
• source /opt/ros/robolab/devel/setup.bash.
• export ROS_WORKSPACE=$HOME/ros_kinetic_ws && mkdir -p $ROS_WORKSPACE/src && cd $ROS_WORKSPACE && catkin init && catkin build.

To use the turtlebots:

• Switch on the base and the onboard PC.
• Connect your PC to the wifi e210bot.
• Connect to the robot with ssh usermap_username@192.168.210.(20+turtlebot_number).
• singularity instance start /opt/ros ros.
• tmux.
• In the each new tmux window singularity shell instance://ros then source $ROS_WORKSPACE/devel/setup.bash.
• In the first tmux window roscore. roslaunch itself would run roscore if no ROS master is detected but this master will be killed when the roslaunch command finishes (usually with Ctrl+C) and nodes such as rqt or rviz would have to be closed as well. It is then better to run roscore separately.
• In the second tmux window roslaunch robolab_bringup turtlebot2.launch camera:=false.

• singularity instance start /opt/ros ros.
• singularity shell instance://ros then source $ROS_WORKSPACE/devel/setup.bash.
• roslaunch simulator_e130 simulator.launch. To be on the safe side, it's better to launch the simulation server and possibly the GUI first (roslaunch simulator_e130 server.launch, roslaunch simulator_e130 gui.launch) and then the robots (roslaunch simulator_e130 robots.launch). This avoid missing robots, especially with more than two robots.
• The node robot_coordination/robot_node can be used to drive the robot, it basically accepts a trajectory as input through services and drives the robot along the trajectory. Launch one robot_coordination/robot_node for each robot: e.g. ROS_NAMESPACE=/robot1 rosrun robot_coordination robot_node __name:=controller.
• Your node must connect to the appropriate services and send the trajectories. An example is given in Python, robot_coordination/example_robot_control.py, and can be launched e.g. with rosrun robot_coordination example_robot_control.py _server_namespace:=/robot0.

Back to the course page.