Transcript File
TURTLEBOT ROBOTIC GUIDE Project Description Teach a robot to guide a person to a predefined destination. General requirements: 1. Use a Turtlebot as the robot 2. The robot must use a vision algorithm(s) as the main guidance. 3. Sensors such as bump, infra-red and ultra-sound could provide direction and safety for the robot. 4. First get the robot to follow someone somehow "remembering" the route so that it can take a turn leading. 5. The solution should be easily modified for alternative routes. 6. Check out Joseph Stawicki's 2013 project for techniques about driving the robot. Meet Turtlebot Hardware Breakdown • Kinect and Mobile Base Gyro combined so all sensor data can be read from one place • iRobot create listens for commands on a serial port, so serial port to USB converter required for communication. • Sensors send data to laptop, laptop sends commands to the mobile base. • Hardware requires software framework in order to receive, process, and send data The Robot Operating System(ROS) Services Provided by ROS: • Hardware abstraction • Low-level device control • Message passing service • Name and Parameter service • Package management + • Laptop’s main OS is Ubuntu which is then overlaid with ROS. • ROS also allows for Android connectivity to the robot Developing Apps with ROS • Workspace allows for packages to be installed and edited easily • Very easily pulls from repositories for quick installs • Symbolically linked to main ROS install • Workspace set up based on directory structure • ROS incorporates a lot of different programming languages • C, C++, Python, Java, and more • The catkin workspace allows for building and debugging across all languages • ROS created ROS specific API’s for Python and C++ (rospy & roscpp) • Makes it extremely easy to call ROS functions • Also allows for cross-language communication ROS Limitations and Frustrations Open Source – does not necessarily mean “FUNCTIONING” Sources, Documentation, and Support not easily obtained Newest ROS distribution designed for newest Turtlebot base (Kobuki) The ROS Wiki – instructions misleading For the first time ever, Google.com was not my friend How it Works Remote communication to the Turtlebot required Workstation Computer connects via SSH Applications are also run locally on Workstation Computer for monitoring, information processing, and visuals These applications receive info via HTTP Android connectivity via HTTP • Incorporated the Wifi Pineapple • Allows for a portable and private Local Area Network Wireless Communication Services, Nodes, Parameters, Messages, Topics Nodes are processes that perform computation Topics are named busses over which nodes exchange messages Communicate with one another via topics, services, and parameters Nodes either subscribe or publish to relevant topics Services handle requests and replies Defined by a pair of messages Messages are simply data structures comprising of typed fields ROS Parameter server is a dictionary accessible via network APIs Nodes use this to retrieve parameters at runtime Software & Hardware Communication Kinect Example Sound Demo • Keyboard inputs command • Keyboard node processes command • Parameters obtained from server • Word node processes the sound to play based on parameters • Sound node processes sound • Output to speakers The Puzzle Pieces Teleoperation Room mapping (SLAM Algorithm) Autonomous Navigation of Known Map Following Voice Commands Color Blob Tracking Its all here! But why is it in pieces? • Applications are limited by the way they interact with the robot • Publishing/Receiving information cannot be done on the same node at the same time Room Mapping with the SLAM Algorithm Autonomous Navigation of a Known Map The Problem: Communication Interrupts Both Nodes need to publish movement commands to the mobile base The Voice Command Node is designed to continually publish directly to the mobile base node The mobile base node sees the Voice Command messages as priority and blocks movement commands from the Follower node The Pivot Node/Dynamic Subscriber Could also be considered ‘nested nodes’ Subscribing node is dynamic If multiple messages received simultaneously then prioritize My Solution (Follower with Voice Commands) The node needs help prioritizing Processing and movement become slowed when subscribing to commands from multiple nodes Using multiple pivot nodes helps speed and processing Created new voice commands that correspond to OS commands Bringing the process down to the OS level allows for universal actions across all applications The use of shell scripts allows the ability to talk to ROS via command line OS helps flag enabled nodes Mobile base will then only listen for commands from enabled nodes Command Recognition Process for enabling follow mode • This particular command effects the follower node the most. Little is done inside the Voice Command Node. Command Recognition Process for disabling follow mode • This particular command corresponds to actions in both the Voice Command Node and the Follower Node Testing/Methodology Alter launch files to see how nodes react Adjust Node publishing target Shows which nodes are capable of handling certain applications or combinations of applications Try as much hardware as possible On screen messages are given when things go wrong Different laptops, headsets, graphics cards, etc. respond and process very differently from one another Experiment on EVERYTHING If I didn’t know what it was, I played with it until I understood how it worked Follower with Voice Commands Live Demo Learning and Development Process RESEARCH – find as much information from as many different sources as possible Run it and see what happens Try everything that’s available, watch and see how the Robot reacts and then connect what’s seen to what sources say Guess, check, and actually read the error messages Make alterations and see what kind of errors come up, helps to correlate what broke to what was changed Project Continuation & Advice UNDERSTAND ROS!!! Follow the link trail Google.com is not your friend for this project. Scimming google search results will get you almost no where. In order to find good information follow links in forums and on web pages that indicate they might be helpful. Eventually you will find something actually useful Consider upgrading mobile base to the Kobuki Not understanding how ROS is working makes it extremely difficult to try and make any changes Gyro is built in allowing for more efficient processing and little calibration Attempt to break Kinect data apart The Kinect has many separate sensors, learning how to get data from each sensor individually would allow for efficient visual application multitasking