Robotics and its software differ from a typical software in its two main requirements.<\/p>\n
The first requirement is that robot software must react differently\u00a0<\/strong>based on environmental changes and conditions – often modeled by a state machine<\/strong> and its states (see here<\/a>, but at its simplest, it’s just if’s in a while loop).<\/p>\n For example, should the robot not enter into a recovery state after ramming into some obstacle, rather than continuing to pummel through? Even if all the visuals and sensor\u00a0data may be the same, the robot must act differently in a recovery state than the\u00a0normal state.<\/p>\n Another requirement is that the robot (the state machine above or something else) needs to be able to handle inputs and requests from multiple sources<\/strong> – from the sensor data, requested actions, and such. Here, the complexity emerges, and ROS is handed the duties of a typical operating system – managing multiple programs at once.<\/p>\n ROS, in its distributed approach, does not have THE state machine, but rather leaves it to each node to determine its own state\u00a0and resolve the potential conflicts (an approach supported by recent neuroscience advances).<\/p>\n So, when designing nodes for ROS, one must be aware of these requirements.<\/p>\n But first of all, let us first discuss the\u00a0service\u00a0<\/strong>tool, which is a\u00a0synchronous way to establish one-to-one communication,<\/strong>\u00a0which means that there is an order to the communications.\u00a0<\/strong>The order is the following:\u00a0A node (client) would send a request to another node (server), possibly waiting for a reply as the server processes the request.<\/p>\n Where in the code do the waiting and processing happen? The waiting happens at Each node, when they receive messages through topics or service, does not immediately process them<\/strong>, as they very well might be doing something more important. Instead, the messages are held in the queue (a line essentially) and processed as a batch during the\u00a0 So what is the difference <\/a>between\u00a0 So when should you use each? You should use\u00a0 And for the services in general, you need to also consider the time that the service will take, making sure it doesn’t occupy the server for too long. Otherwise, the server will not be able to react quickly to the inputs from other nodes – perhaps a command that is requesting for the robot to freeze immediately. Thus, it is generally recommended that\u00a0services be simple, short requests.<\/strong><\/p>\n However, you would need the ability to command a robot to do a more complicated task – or even allow for multitasking of tasks. For those requirements, there is the action lib<\/a>. In contrast to service, it is – and must be –\u00a0an asynchronous way to communicate one-to-one.\u00a0<\/strong><\/p>\n Why the must? The actions must be asynchronous, as for actions with a long-time frame (~seconds), the state of the robot might change, with actions needed to be interrupted and continued later.<\/strong>\u00a0So actions are asynchronous because the execution of action is not fixed<\/strong> – unlike services, which can’t be interrupted.<\/p>\n While the exact details of both service and action is in the respective tutorials, these differing goals for services and actions must be accounted for when making servers (nodes) for each of them – asking if the service or action would be more appropriate at this point.<\/p>\n Assignment: Implement a client\/service, in which client sends in a service to the server to change the state of the server in some way.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Robotics and its software differ from a typical software in its two main requirements. The first requirement is that robot software must react differently\u00a0based on environmental changes and conditions – often modeled by a state machine and its states (see here, but at its simplest, it’s just if’s in a while loop). For example, should … Continue reading “Callbacks and Synchronicity – Week 3”<\/span><\/a><\/p>\n","protected":false},"author":1933,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/posts\/52"}],"collection":[{"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/users\/1933"}],"replies":[{"embeddable":true,"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/comments?post=52"}],"version-history":[{"count":5,"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/posts\/52\/revisions"}],"predecessor-version":[{"id":58,"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/posts\/52\/revisions\/58"}],"wp:attachment":[{"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/media?parent=52"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/categories?post=52"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/commons.trincoll.edu\/trinityrobotics\/wp-json\/wp\/v2\/tags?post=52"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}spin() and spinOnce()<\/code>, while the processing happens in the callback.<\/p>\nspin()<\/code> commands.<\/p>\nspinOnce()<\/code> and\u00a0spin()<\/code>?\u00a0spin()<\/code> is essentially\u00a0spinOnce()<\/code> called in a loop – once the node runs\u00a0spin()<\/code>, the node will now only deal with the callbacks. By comparison,\u00a0spinOnce()<\/code> allows the node to process the callbacks at the designated time “once”.<\/p>\nspinOnce()<\/code> if you have a code not part of the callback that constantly needs to run and\u00a0spin()<\/code> if the server only needs to deal with callbacks from then on. Also, with spinOnce()<\/code>,\u00a0you need to be aware of the time that will take to process the tasks between\u00a0spinOnce()<\/code>, making sure that the tasks will not prevent callback from activating too late.<\/p>\n