@@ -11,11 +11,12 @@ This work is licensed under the CeCiLL-B license, which is a free software license with the same spirit than the BSD license. See License.txt for details -== What is Roby ? += What is Roby ? Roby is a plan manager: it allows to represent, execute and adapt a plan, which -is a set of past, present and future activities of a robot along with the -information needed to supervise their execution. +is a representation of the past, present and future activities of a robot along +with the information needed to verify that their executin is going well, and to +manage errors. Roby is: * a task/event model in which one can represent the activities (Roby::Task) and @@ -31,10 +32,37 @@ Roby is: * (G)UI tools for interacting/controlling the living system. * all of that in a multi-robot context. -= Related publications +== Related publications -== Installation -= External dependencies +Roby is the result of my PhD work. As such, my {PhD +thesis}[files:joyeux_Thesis.pdf] can be considered as a design document for the +system. If you want an overview of the principles, you can also refer to these two +publications [IROS,FSR]. + +== Videos + +Those videos are shown here for reference purpose, but frankly you will not be +able to understand them unless you have already an idea on what is going on. +They are also referenced in other parts of the API documentation, when it is +meaningful. + +TODO: link the videos + +== Tutorials + +I've written a set of tutorials which describe Roby's main features and let you +experiment with them: +1. the GettingStarted[link:files/doc/tutorials/01-GettingStarted_rdoc.html] tutorial makes + you start a brand new Roby application and explains its structure. +2. the GoForward[link:files/doc/tutorials/02-GoForward_rdoc.html] tutorial shows how to create + a simple task, how to start the Roby controller and how to interact with it + using a shell. +3. the PlannedPath[link:files/doc/tutorials/03-PlannedPath_rdoc.html] tutorial + shows how to create a (slightly) more plan, using the plan-generation + capabilities of Roby. It also shows some properties of that plan. + += Installation +== External dependencies * The Roby engine needs * +utilrb+, which is available on RubyForge[http://utilrb.rubyforge.org] as a gem * +utilmm+, which is available on SourceForge @@ -49,13 +77,13 @@ Roby is: 1.4.9}[http://rubyforge.org/projects/korundum], SVG export requires QtRuby to be built with Qt >= 4.3 -= Installing the easy way +== Installing the easy way Roby is available on RubyForge as a gem. After having installed the C++ dependencies (boost/graph and utilmm), you can simply install it with gem install roby -= Installing from source +== Installing from source First, install all the required dependencies. Then, get the sources either from a release tarball or the RubyForge git README.txt @@ -1,21 +1,27 @@ = TODO == Refactoring +=== Small stuff * remote_id => network_id * incremental_dump? => dump_reference? -* fix Roby::Control and Roby.control. Everything should be accessible from the - same object. In a more general way, clean up the mess in globally used - methods of Roby -* don't allow to change any event or task relations if the task is not incldued - in a plan. This would finally fix problems related to logging and other stuff - like the possibility of having tasks hanging around because they have never - been removed from any plan. + +=== Big stuff +* fix the Roby singleton methods/Roby::Control/Roby::Propagation mess. Maybe move + all the execution-related stuff in a subclass of Plan, MainPlan. That would allow + per-MainPlan execution management and in the end having multiple executable + plan in the same plan manager (I'm thinking bi-simulation) +* have separate relation graphs in each Plan object. That would be possible + if we don't allow anymore to change any event or task relations if the task + is not included in a plan, which would greatly simply logging-related stuff + (for instance, rebuilding a representation of plans from logged data). + Moreover, we would not have tasks hanging around anymore because they have + never been removed from any plan. +* in dRoby, separate the implementation of the RX/TX and + connection/disconnection protocol, including the management of the TX queue + (callbacks, synchronous/asynchronous). * have a thread-safe handling of transactions. This requires a few things: - - separate relation graphs: have one relation graph per plan object. The - global constants would then be only numeric IDS (or symbols, whatever), and - the various methods would get the relation graph from the object's plan. - Note that it requires that all objects are always included in a plan (check - the previous todo point) + - separate relation graphs: have one relation graph per plan object: see previous + point. - stop using method forwarding, which is not the good way to do that. Instead, do as for distributed: update the task status in the transaction thread. Need to define a notion of "transaction thread" and how messages TODO.txt 09e72d883483f212f7d37cddf0ac1cb4d3d7d732 Sylvain Joyeux sylvain.joyeux@m4x.org http://github.com/doudou/roby/commit/788914631b2370414262e8b6ce5461d8c514d351 788914631b2370414262e8b6ce5461d8c514d351 2008-04-29T00:29:09-07:00 2008-04-29T00:29:09-07:00 [doc] update README and TODO 8e8dde0dd85ffe5e84f39e5e9a7766bb0043e698 Sylvain Joyeux sylvain.joyeux@m4x.org