.RealTimeCoordinationLibrary.Examples.Application.BeBotSystem .RealTimeCoordinationLibrary.Examples.Application.BeBotSystemThe test platform used in this work is a wheeled mobile robot known as BeBot [7]. It is a miniature mobile robot developed at Heinz Nixdorf Institute and has been used in various research projects, e.g., [8]. The BeBot is powered by two DC-motors with integrated encoder.
In order to use this mobile robot in a simulation environment, a simple model of the BeBot is developed in Dymola. Basically, the model of the mobile robot can be categorized into three main groups. The first group consist of its casing and electrical circuit boards. All these components are modeled as a rigid body in Dymola. In addition, the shape model from the Multi Body library is used to visualize these components in the animation. The next group comprises the wheels of the robot. Under the assumption of pure rolling, these wheels are represented by a pair of wheels with a common axle whereby each wheel is individually controlled. The final group is made of two DCmotors. Each of these motors is represented using a simple model of a DCmotor. In this model, friction is taken into consideration to provide a more realistic behavior for the motor. As shown in Figure 2, these components are connected accordingly to create a simple model of BeBot.
In order to control the movement of the mobile robot, the velocities of the wheels have to be con trolled. Therefore, a speed controller is designed to control the rotation velocity of each wheel. The con troller is a PIcontroller with antiwindup function and it ensures that each wheel rotates at a desired velocity.
In our scenario, two BeBots are given (see Figure 3). They communicate wireless with each other and have a distance sensor at their front. Both have the same software specifications. The BeBots drive on a straight way in the same direction. The front driving BeBot transports a heavy good to the furthermost place of de livery. The rear driving BeBot transports several small goods and has to deliver them to several stations. As the front driving BeBot is heavier than the rear driving BeBot, its cruising speed is slower than the cruising speed of the reardriving BeBot. To optimize the en ergy consumption, the rear driving BeBot may drive in the slipstream of the front driving BeBot. During platooning a collision could occur if the front driving BeBot must brake very hard (e.g., due to an obstacle on the street) and the rear driving Be Bot does not know beforehand that it must brake. To avoid a collision, the front driving BeBot commands the rear driving BeBot by sending an asynchronous brakemessage to perform a brake maneuver.
The brake-message is transmitted to the rear driving Be Bot that is going to brake as soon as it gets this mes sage. This delivery time is safetycritical, because the front driving BeBot brakes after that time and braking does not results in a collision. A precondition to co ordinate such braking behavior is, that a BeBot must know if another BeBot is driving behind. Therefore, besides the braking message also messages for start ing and ending a platoon are required. The behavior specification of this scenario can be modeled with statecharts, e.g., to distinguish if a Be Bot drives in a platoon or not. As we want to sim ulate this scenario by using Dymola, a common li brary would be StateGraph2. However, the next sec tion shows the limits of StateGraph2 for modeling the behavior of this realtime coordination scenario.
BeBotSystem contains the two connected instances front and rear of the class BeBot_SW. Furthermore, it shows two instances of the BeBot hardware model and how they are connected with the software models. The instance distance of the class Distance calculates the distance of the rear BeBot to the front BeBot. We do not display the connections to the inputs cruisingSpeed and stop.