## page was renamed from kobuki/Tutorials/Kobuki's control system ## page was renamed from kobuki/Tutorials/Kobuki's control system concept ## For instruction on writing tutorials ## http://www.ros.org/wiki/WritingTutorials #################################### ##FILL ME IN #################################### ## for a custom note with links: ## note = ## for the canned note of "This tutorial assumes that you have completed the previous tutorials:" just add the links ## note.0= ## descriptive title for the tutorial ## title = Kobuki's Control System ## multi-line description to be displayed in search ## description = Get familiar with the concept of Kobuki's control system ## the next tutorial description (optional) ## next = ## links to next tutorial (optional) ## next.0.link= [[kobuki/Tutorials/Write your own controller for Kobuki|Write your own controller for Kobuki]] ## next.1.link= ## what level user is this tutorial for ## level= AdvancedCategory ## keywords = kobuki, control system, concept #################################### <> <> <> = Overview = This tutorial will bring you in touch with the concept for Kobuki's control system. It describes the different components and how they interact with each other. At last, the reader is walked through a simple demo showing the benefits of the concept. = A note on Nodelets = Nodelets are heavily used in Kobuki's control system. They have various benefits over normal nodes. The most important among them are avoiding serialising/deserialising of messages and the transmission over the TCP/IP. This is done by passing pointers to messages instead of the messages themselves. That means messages are faster processed and transmitted. When working with big messages, such as point clouds, this can also significantly lower the CPU consumption. For our use case, the speed improvement is important, that is why we implement controllers and other speed-sensitive parts of Kobuki's control system as nodelets. Implementing code as nodelets instead of node is nothing to be afraid of as the the next tutorial will show. = Control System Concept = == Components == Kobuki's control system uses three different components. * [[kobuki_node]]: (AKA mobile base) is actually a nodelet, which wraps the C++ driver for communicating with Kobuki * [[cmd_vel_mux]]: is a velocity command multiplexer (or in otherwords a switch). It manages multiple incoming velocity commands according to the configured priority. * Kobuki controller: is a nodelet-based controller type - used for various applications; one example is the [[kobuki_safety_controller]], which watches the bumper, cliff and wheel drop sensors and acts accordingly. Use this to implement your own reactive controller (see the next tutorial). Furthermore, there is an implementation of a velocity smoother: [[yocs_velocity_smoother]]. This tool is optional, but highly recommended to use. In case a node publishing velocity commands can't ensure their smoothness, put this smoother in between that node and the cmd_vel_mux. == How it works == The three components introduced above are used in a small hierarchy. Starting bottom-up, there is the mobile base, which listens for commands (LEDs, sounds, velocity) and publishes sensor information. On top of that we use the cmd_vel_mux, which makes sure, that only one velocity command at a time is relayed through to the mobile base. On the next level we have one or more controllers and other programs, such as keyboard teleop and the navi stack. There are cases, in which we want smooth velocity (e.g. keyop) and cases in which we don't (safety controller). So, use the velocity smoother when necessary. == Example == The diagram below shows example use cases: {{https://docs.google.com/drawings/pub?id=1AP_T-5yWtVKxe981M7h8I9Paxd8gfzGIqvLZEudCG9k&w=750&h=1091|Kobuki's control system|align="middle"}} In the shown scenario, there are multiple programs, which want to control Kobuki's movement. The velocity muxer allows using all of them in parallel. An example multiplexer configuration could be the following: Priorities: * 3 (highest priority): safety controller * 2: keyboard teleop * 1: android teleop * 0 (lowest priority): navi stack teleop In this case, the navi stack would control the robot in most of the times. However, the user can override navi stack's commands, by triggering commands with the Android teleop app or the keyboard teleop. In case both teleops would be active at the same time, keyboard teleop would win. However, all the velocity commands above will be overridden when the safety controller kicks in (bumper, cliff or wheel drop sensor activated). This allows safe driving of Kobuki with all three tools. = Playing with the Control System = == Overview == To show you the benefit of following the presented control concept, we will modify the default launch files to show you bad behaviour we want to avoid. == Bad Kobuki == In order to bring forth Kobuki's bad behaviour, we will tweak {{{kobuki_node/keyop.launch}}}. 1. Comment out the multiplexer: {{{ [...] [...] }}} 2. Remap the velocity command topic of the safety controller in order to send commands directly to the mobile_base nodelet: {{{ [...] [...] }}} 3. The same for keyop: {{{ [...] }}} Now, let's see what will happens: First, launch the basics: {{{ roslaunch kobuki_node minimal.launch --screen }}} and then in a separate terminal the keyop app ({{{keyop.launch}}}): {{{ roslaunch kobuki_node keyop.launch --screen }}} First, make Kobuki drive against an obstacle. You will notice that Kobuki's starts to shake (quickly moving back and forth) at the obstacle. Now, lift Kobuki up. The safety controller will stop Kobuki, once one of the wheel drop sensors trigger. However, you will notice that the wheels are shaking and slowely moving forward. Both behaviours are due to Kobuki receiving and executing velocity commands from both keyop and the safety controller at the same time. == Good Kobuki == Now, undo the modifications above and start {{{minimal.launch}}} and {{{keyop.launch}}} again. You will notice that Kobuki now moves a couple of centimeters back, when hitting an obstacle. Also, when you lift Kobuki up, the wheels stop turning. = Conclusion = '''Follow the control system concept!''' :-) The above is true, but we also want to highlight, that the presented control concept represents our first iteration. In the future, we want to further improve the performance and design. If you have suggestions, please feel free to join the development! You can contact us through various channels, which you find on [[http://kobuki.yujinrobot.com/|kobuki.yujinrobot.com]]. You can also reach us through the [[https://groups.google.com/group/ros-sig-turtlebot/|Turtlebot mailing list]] or notify us on [[https://github.com/yujinrobot|GitHub]]. Now, that you have learned about the control system, it is time to implement your own controller: [[kobuki/Tutorials/Write your own controller for Kobuki|Write your own controller for Kobuki]] ## AUTOGENERATED DO NOT DELETE ## TutorialCategory ## FILL IN THE STACK TUTORIAL CATEGORY HERE