A software description
In this last part of the post series, we are going to start reviewing roughly the classes of motion-control and then continue with the entities needed by the miLoCo task used.
Again here is the link to the git repo.
motion-control
As probably you remember from the first post, this is the program that runs on the beaglebone. If you read its main, you will notice a class called MotionApp, which is the one that controls the bot. An object of MotionApp is created after parsing the arguments. The constructor of this class initializes everything needed to move the bot, e.g. the motor drivers and kinematic model. After the object creation, the method startApp() is called. Here the miLoCo task stars running.
Once executed app.startApp() and if there weren’t any error, the main executes run(). This function depends on the argument passed to motion-control. If no argument is passed, run() will be startDefaultMovements() but if the argument is rem, run() will be startRemoteControl(). Within both functions, motion commands are sent to the bot calling app.moveRobot(). The difference between both is the source where the commands are coming from. For example in case of startRemoteControl() a TCP server is started and a client is waited, which is the one sending the motion commands. In our case this client is the python script (remoteControl.py). Feel free to implement your own client :).
Let’s describe the part of the code which is more relevant for the final goal of this post.
miLoCo task: ReducedObsPolePlacement
You may have read something about the concepts on the miLoCo readme and probably you are familiar with the need of implementing some entities. In case of the selected miLoCo task (pole placement with reduced observer) are the following:
- – input_t
- – actuator_t
- – sensor_t
- – fdbk_matrix_t
- – observer_t
Before going to the implementations of these entities in 3WheelsBot, let’s take a look at the class where the miLoCo task is created: MotionController
The MotionController class
This is the most important class in terms of the motor control loop and the reason is because it has objects of all entities needed by the miLoCo task. Additionally it contains methods for interacting with the input of the control loop, i.e. updateSpeed() and abortCmds(). For example this last one is called when you press the “space bar” for stopping the robot.
If you paid attention to the creation of the task, you may notice that the class that implements the sensor_t is actually the same as the one for actuator_t and its type name is: powertrain_t. This type also has defined other one for an auxiliary class which contains needed objects for the control loop, e.g. the reduced observer (observer_t), the feedback matrix K (fdbk_matrix_t), etc.
MotionController is actually a template class. For this reason we are not able to find on its definition file the real name of the classes. For example, in case of powertrain_t the class is Powertrain.
The last entity is input_t but here the type name is speed_setpoint_t and the class name is SpeedSetpoint. All these classes are defined under the path control/inc/control. But now, the question is: where are the objects of these template classes created? And the answer is: MotionApp
The MotionApp class was almost all explained at the beginning but I forgot to mention one very important thing and that was on purpose :). We know that driver objects are instantiated in the constructor of MotionApp, but… Where are these classes defined?
Drivers for the Beaglebone Blue
You will find all definitions and implementations in the folder platform. This is divided into source and includes following the same structure as the other folders but with the difference that you’ll find 2 extra folders: beaglebone and simulation. The folder beaglebone contains all wrapper classes for functions present in librobotcontrol. The folder simulation contains all classes for the simulation mentioned in the end of the second part.
We have reached the end and I’d like to take this opportunity to thank a friend of mine, with whom I’ve talked a lot about this project and that’s why he has also contributed indirectly: Thank very much Seba!
Finally and please if you like this post series, share it ;).
