Using an RBS to express the rules in reactive behaviors certainly has its benefits; the resulting wall-following capability has turned out efficient and realistic in the end, but at what cost?
It undoubtedly took more time to develop the RBS module than writing a script with steering behaviors would have required. In this case, there are mixed benefits of RBS over scripts:
The performance of this RBS is slightly worse, because the sensors are checked automatically by the RBS upon every execution.
The memory consumption of the system is slightly less than a scripting environment would have required.
Conceptually, the rules are simpler, but they need to be translated into a format accepted by the module (XML).
There are also pros and cons compared with a native implementation:
A native implementation is much faster than declarative rules.
The programmer gets more control over the C++, so it can be optimized and customized.
The RBS has the advantage of separating the knowledge from the implementation.
On the bright side, we also have a good feel for the development of AI using an existing module. There are some good lessons to extract from this, including the following:
The RBSs are more appropriate at higher-level control (decision making) than motor control.
Using an RBS for a simulation takes a bit more effort than just problem solving! More actions (or default values) are required to keep the working memory in the right state.
Many of the benefits of RBSs are no longer applicable in simulations. The rules may be modular, but they are so interdependent that either may break the behavior when removed or added!
Custom extensions to RBS are necessary for problems to be solved in an elegant fashion.
Although wall following wasn't the best of problems for RBSs, they actually worked and didn't take too much effort (revealing their flexibility). As an exercise, we will use them again later at a higher level of control to get a better feel for the wide capabilities of this AI technique as a problem-solving mechanism.