Differential Drive Robots

While working at university, I designed and built a mobile robot lab for demonstrating advanced non-linear controller design and decentralized control schemes. Once an experiment is started the nodes can operate independently, allowing truly decentralized controller execution. Various flavors of non-linear model predictive control and collaborative control tasks were successfully implemented.

Robot Nodes

I designed the robots from scratch to accomodate the setup's rather unique requirements. The decentralized aproach requires significant computing power on each node, while use in student experiments demands long battery runtime and short charge cycles. The nodes are modular in design, with drivetrain controller and processor module mounted on plug-in boards. Depending on application a stepper motor or brushed dc drive can also be fitted. The nodes run linux. A separate embedded controller impements real time operations.

Without getting into too much detail, the nodes are roughly configured as follows:

• Quad Cortex-A53@1GHz
• 28W brushless dc drivetrain
• BMS with fuel gauge and 14W charger
• Active braking
• 5h runtime with 90min charge
• Over current, over temperature, over-/undervoltage protection

The brushless drive also makes the robot quite fun to drive around. The drive system delivers enough torque to wheelie the robot, do burnouts or wreck it in a crash. While doing wheelies with robots might be fun, the main reason behing generating lots of torque is to allow for fast settling kinetics. A low level PI-Feedforward controller was designed to largely compensate dynamics. This allows controller design under purely kinematic assumptions, greatly simplifying the resulting non linear program. Closed loop control can also be disabled if kinetics should also be optimized.

Robot position is measured using a 3D motion tracking setup mounted to the ceilling trusses. The robot was designed to accept different unique non-symmetric spherical marker patterns.

Arena

Because the concrete floor in the lab environment was quite uneven, I ended up designing a false foor setup that can be leveled using adjustable feet. The arena measures roughly 24x12' (4x8m). The driving surface was fitted with a textured PVC film to minimize wheel slip. The frame was constructed from aluminum extrusions. The frame was designed to carry a human being, as it is required to walk on the surface for camera calibration.

Two projectors were mounted to provide real time plotting on the driving suface. Mirrors project the image to allow for horizontal projector mounting (required for heat dissipation). Because this results in some not so trivial projection geometry, custom image rectifcation was implemented. The plotting software is also custom and can be accessed using a python module injected into the controller runtime. Along the projectors, a 3D motion tracking system was also mounted on the ceiling.

Software

Considerable time was invested in developing custom software that allows easy execution of truly decentralized control schemes. The entire lab is controlled from a web based control panel. The control panel was written using the react framework and material UI. Real time updates are pushed to the web panel using web sockets. The entire lab can be operated remotely.

The web panel features a built-in code editor. The code can be uploaded and executed to reach robot node with the click of one button. Code execution usually starts roughly one second later. Each node's python console is streamed to the code editor. Exceptions are caught on each node and highlighted in the code editor. Addditional exception logging was also implemented to examine each node separately after running an experiment. Using the same mechanism, switching between different experiments only takes seconds. The python runtime on the nodes provides full hardware abstaction and intuitive APIs.

Each controller script can also offload parts of the computations to an additional server. This is particulary useful when solving optimization programs that are too involved for the Cortex processor. A signaling scheme was implemented for inter-node or node-server communication.

I chose C++ for most of the backend and node ES6 for the webapp. The node firmware was written in plain C. Due to it's heavy overhead, Python is only used for controller script execution.