CepBot and its Components

Robot Programming using JBoss BRMS

One of my hobbies is building robots. After programming several robots, I say to myself: there’s got to be a better way of doing this. You program the behaviour of a robot using a micro-controller. Every time you want to make a change, you have to re-flash the on-board non-volatile flash memory. If you compare this practice with enterprise applications, it is similar to that of many older enterprise applications which embed business logic in code. The solution is to move the embedded business logic (in our case, the robot behaviours programmed on micro-controller) out to be managed and executed by a business rules engine. This is exactly what I did. And I call my robot CepBot.

Complex event processing or CEP is a method of analysing events (things that happen) and deriving a conclusion from them. The use of CEP in robotics is to identify meaningful events (such as sensor inputs) and respond to them as quickly as possible. Drools Fusion combines events with the Drools rules engine. It is a component that comes with JBoss Business Rule Management System (BRMS).

In this article, I shall describe how I created my CEP-based robot I call CepBot shown below.

CepBot and its Components
CepBot and its Components

Bill of Materials

CepBot is put together using the following parts:

  • 1 X Boe-bot (gains a Frisbee and loses the BOE!)
  • 2 X Continuous Rotation Servos and Wheels
  • 1 X HC-SR 04 Ultrasonic Distance Sensor
  • 1 X Micro Servo
  • 3 X Obstacle Indicator LEDs
  • 2 X Micro-controllers with Wireless Capability
  • 2 X Mini Breadboards
  • 1 X Prototyping Board
  • Jumper Wires and Header Terminals
  • 4 X AA Batteries
  • 1 X battery holder

The micro-controller. used is called the Wixel. It is an enhanced version of the venerable 8051 with a wireless radio built-in.

The Wixel Microcontroller
The Wixel Microcontroller

How it Works

The way CepBot works is best explained using the photo below.

CepBot and the PC
CepBot and the PC


The robot consists of the following components:

  • a ultrasonic sensor mounted on a micro-servo for obstacle detection
  • a Wixel wireless controller mounted on a breadboard
  • 3 LEDs mounted on the breadboard (the left LED lights up when an obstacle is detected on the left, the middle LED lights up when an obstacle is detected directly in front of the robot, etc.)
  • the components above are all mounted on a Frisbee which is attached to a Bot-bot which uses 2 continuous rotation servos for locomotion
  • the Wixel Wireless Slave control program which accepts commands from the PC via the wireless connection

PC with a USB-connected Wixel

The responsibilities of the PC include:

  • running a JBoss BRMS-based CEP master program which sends commands via the serial interface to the Wixel
  • USB-connected Wixel runs the wireless Serial Programming

The commands that the PC can send to the robot are:

  • Read Distance Sensor (1)
  • Set Servo (3)
  • Set Indicator LEDs (3)

JBoss BRMS-based CEP master program implements a number of behaviours including:

  • Wander Behaviour – roves around avoiding obstacles
  • Territorial Behaviour – rushes to face intruder entering his territory
  • Wall-following Behaviour – finds wall and follows it

For example, the Wander Behaviour consists of 9 rules:

  1. rule “Close-range Obstacle – spin right”
  2. rule “Close-range Obstacle – spin random”
  3. rule “Close-range Obstacle – turn around”
  4. rule “Collision-range Obstacle – too close, move back”
  5. rule “Close-range – Back to NORMAL”
  6. rule “Close-range – Deadlock Detected”
  7. rule “remove DistanceSensorEvent”
  8. rule “Close-range Obstacle – spin left”
  9. rule “remove CloseRangeRecoveryEvent”

A GUI has also been created to control the robot’s motion and switch among the different behaviours remotely using wireless.

GUI for CepBot
GUI for CepBot


How it Resembles an Enterprise Applications

The design and building of the CepBot resembles that of an Enterprise application in the following ways:

Robot Enterprise CEP Application
Feed from remote telemetry via an adapter Multiple data/event inout adapters
Wild variety of robots and input telemetry formats Input can be of different formats
New behaviours can be implemented by adding new sets of rules New capabilities can be implemented by addinf new sets of rules
Intelligence resides on PC (BRMS) instead of on less powerful micro-controllers Intelligence resides centrally in BRMS
Using declarative approach instead of the typical imperative programming approach Using a declarative approach instead of hard-coding business rules in applications


Now that all the rules and behaviour are taken out from the micro-controller. and managed and executed on the PC, changing or adding new behaviours to the robot is a simple matter of changing the rules on the PC. There is no longer a need to reprogram the micro-controller’s flash memory each time we want to change the robot’s behaviour. Another major change is that we have switched from the imperative programming paradigm to that of a declarative paradigm. Once you tried this approach, you may not want to go back to the frequent re-flashing and imperative programming practice.