Embedded solutions for a class of highly unstable, underactuated and self-balancing robotic systems

3.1 Didactic perspective of the work

From an educational point of view, the three case studies were suitable for multidisciplinary working teams. For each case, laboratory activities have been provided and divided into subtasks associated to the design phases of the robotic systems. The first task is the mechanical layout of the robotic systems. It should be defined by the team under common design constraints like the type of materials, the limit weight, the distribution of weights in order to obtain the right distribution of the inertia moments, etc. The second task is devoted to the selection of the actuators able to provide the necessary performances to the robotic systems. In this case, the designer needs to identify the simplest first-principle models and physical laws that make them able to effectively obtain the necessary dynamic performances as required accelerations, velocities and torques. The third task deals with the development of the electronic hardware architecture. It must be well-designed to condition and adapt signals and provide apt power supply to all the system units. In the fourth task, the basics of embedded microcontrollers are addressed along with their application in control technology. The state-of-the-art electronics technology for robotics and autonomous systems, with respect to its availability and real costs in the market, is evaluated and chosen.

The scope of the activities is to provide a basic industrially-aware knowledge for the design of small automatic systems and robotic systems that are capable to operate autonomously in indoor or outdoor environments applying lightweight control algorithms based on embedded technology.

3.2 Ballbot

In this section, the involved hardware and its setup are explained. The ballbot robot shown in Fig. 1 is designed as a test bed to investigate the issues of a dynamically stable robot balancing and driving on a single ball.

The platform was built with on-board hardware and processing. It is designed to be self-contained and to perform all the computing on board. It is relatively low cost, and the availability of its constituent parts makes it attractive for research and educational use.

3.2.1 Hardware

As shown in Fig. 1, the mechanical system is basically composed of three parts: the chassis, the propulsion system and the sphere (a basketball). The whole structure is made of alluminium and plastic in order to reduce the system’s weight. The chassis is composed of three parallel disks having a radius of 140 mm and placed at three different levels spaced 100 mm. On the bottom of the highest level, the inertial measurement unit (IMU) can be found (see Fig. 2).

The propulsion system is composed by three DC brushed motors with gear boxes and incremental encoders, three DC-drivers and three omni wheels installed on the motor shafts. The omni wheels are a key parts of the ballbot system. An omni wheel (see Fig. 3) is a conventional wheel with a series of rollers connected to the circumference.

The axes of rotation for the rollers is parallel to the circumference of the wheel. This configuration of rollers enables the omni wheel to move in both the rotational and the lateral direction of the wheel. It can either roll around the wheel axis like a regular wheel or roll laterally using the rollers connected to the circumference or both at the same time. If actuated as normal wheel, the omni wheel allows the system to apply, in the wheel’s contact point, a force which is tangential to its circumference. Moreover, it allows the system to slip sideways, if some lateral force is applied. Between the axes of the wheels, an angle β of 120° is considered (see Fig. 4). To avoid a slip motion of the platform over the ball, a minimum angle for the omniwheel contact point α of 40° is required. It is the angle between the contact point and the vertical axis of the platform (see Fig. 4).

The physical parameters describing the system are listed in Table 1.

Parameter	Value	m.u.
Mass of the ball	0.65	kg
Mass of the wheel	0.107	kg
Mass of the body	5.045	kg
Radius of the ball	120	mm
Radius of the wheel	53	mm
Radius of the body	140	mm
Height of COG	410	mm
Inertia of the ball	0.005	k g m 2
Inertia of the body	0.47	k g m 2

3.3 Robotic Leg

During the last decade, there have been significant efforts in the developing of autonomous legged robots actuated by electric motors [12, 15, 16]. Some efforts have been also done in improving the performances of the electric motors [17]. DC motors (direct current motors) are widely used in industrial systems, such as robotic manipulators, thanks to their simplicity and dependability in a wide range of operating conditions. DC motors are usually easily modeled, and linear or nonlinear control approaches can be implemented.

The powered robotic leg shown in Fig. 5 is designed as a test bed to investigate the issues of robotic legged locomotion. It is a single legged hopping that reduces the complexity of the quadrupedal (or bipedal) running, but it is still capable to explain much else about real dynamics. Furthermore, it can be useful for the evaluation of different control algorithms.

The proposed embedded system implements the accurate control of torque, speed and position of DC motors actuating the joints of the robotic leg when different control strategies are required. An important issue of these robotic systems is the ability to choose between different gaits in order to travel optimally at a certain speed or to robustly deal with perturbations. This leads to the use of different control strategies depending on the required task. Although the controller is designed for a particular robot application, it is applicable to other systems which requires to control simultaneously several DC motors with different tasks.

The articulated leg consists of a main body on top of the two leg parts: the thigh and the shank. The latter is connected with a damping foot by means of a steel spring which stores the released impact energy which is then used for the upwards acceleration. The joints connecting these bodies are the knee, the hip and the joint rotating the thigh around the main body’s yaw axis.

Each joint is actuated by a powerful electric DC motor for a total of three motors per leg. As showed in Fig. 5, the motors actuating the hip and the knee are installed, respectively, along the main axis of thigh and shank, whereas the actuator of the yaw axis is inside the main body. Each DC motor is a Maxon DCX35L 18V powered at 24 Vdc (its maximum allowed voltage is 30 V, a 24 V supply voltage is suited for the battery system) with a gearbox Maxon GPX42 featuring a 66:1 reduction ratio, which provides each joint with a maximum continuous joint torque of 5 Nm at 120 rpm, and a shorter duration of maximum torque of approximately 18 Nm at 65 rpm (in the latter working point the motor without a gearbox has 0.26 Nm at 7200 rpm). The motors’ performance were selected to allow the leg not only to walk but also to jump. Henceforth, the basic criterion for their selection was the shorter duration of maximum torque. The range of motion for hip and knee joints are about 180 ^o both in flexion and in extension, while the joint of the yaw axis freely rotates 360 ^o .

The structure of the leg is aluminum that is reinforced and supplemented with inserts. Hip and knee joints are equipped with steel bevel gears which transmit the motion from the motor shaft to its orthogonal axis, while the joint of the yaw axis has plastic planar gears which transmit the motion from the motor shaft to its parallel axis. The sensors in the leg include a rotary optical encoder for each motor to sense the joints of hip, knee and yaw axis. In addition, current sensors are used to measure the joint’s torques. The maximum leg extension is about 60 cm (thigh and shank) with a total leg mass of approximatively 8 kg (the component weights, in kg, are leg structure 3.5, geared motor 0.9, bevel gear in steel 0.4, couple of plastic planar gears 0.14, spring 0.15, battery-pack 0.66). The powered leg additionally includes a custom embedded control system, whose components are located in the main body on top. The devices of the embedded control system are the MCU board, the DC motor drivers and DC/DC converters.

Figure 6 shows the schematic model of the considered robotic leg by representing its three rigid bodies (the main body on top of the leg, the thigh and the shank) and their main parameters.

The thigh is attached to the main body by two revolute joints, one base on top and one at the hip, whereas the shank is linked to the thigh by a revolute joint at the knee. The robotic leg is able to move in the three-dimensional world described by an inertial frame centered in the axes origin by means of the DC motors on each joint (see Fig. 5). This way the main body performs a spin γ around the yaw axis, the thigh performs a spin α on the hip and the shank S performs a spin β on knee. This rigid body system has consequently five degrees-of-freedom.

3.3.1 Hardware

The hardware of the robotic leg allows to power all its electromechanical and electronic parts and to communicate with all sensors and actuators installed. All electronic components have been chosen to fit comfortably into the structure of the robot. No external computers are used. In addition, the weight of all hardware modules have been chosen as low as possible. The proposed architecture is shown in Fig. 7.

The power source of the whole system is a Li-Po battery 5000 mAh 5S 65C 18.5 V providing a voltage of +12 Vdc, it powers the other devices through a power-layer of two DC/DC-converters (240 W, 24 V, 10 A) which linearly regulate and raise the voltage level to +24 V (the voltage supply of the DC motors). The switching regulators for efficient conversion (not shown in Fig. 7) provide intermediate levels of +3.3 V and +5 V to embedded systems and sensors. The DC motors are driven by DC-drivers MD10C V2 by Cytron. A first DC/DC-converter is devoted to powering the DC-driver of the hip joint (the joint with the highest load), while the second is devoted to powering the other two DC-drivers of the two other joints, respectively. The current sensor for each motor is an ACS758 by Allegro Microsystem. They are in serial connection between the DC-driver and the motor. Finally, the optical encoders HEDL-5540 by Avago Technologies are mechanically connected to the motor shafts. Figure 7 also shows the connections between the embedded control board and the other devices.

3.4 Quadrotor

The aerial vehicle used in this work is an electric quadrotor. It is a rotary wing aircraft where each motor is attached to a rigid cross frame as shown in Fig. 8. Quadrotors are mechanically simpler than classical helicopters. Quadrotor is a vertical takeoff and landing vehicle (VTOL) able to move omnidirectionally with the ability to fly in a stationary way.

A quadrotor is controlled by varying the angular speed of each rotor. The force produced by each motor is proportional to the square of its angular speed. The front and rear motors rotate counter-clockwise, while the other two motors, the right and the left, rotate clockwise, canceling gyroscopic effects and aerodynamic torques in stationary trimmed flight.

The vertical motion is controlled by the collective thrust input, i.e. the sum of the thrusts of the motors. The forward/backward motion is achieved by a tilt around the y-axis (the axis of the left-right motors) generating a pitch angle. This is obtained controlling the differential speed of the front and rear motors. The left/right motion of the vehicle is achieved by controlling the differential speed of the right and left motors, tilting around the x-axis (the axis of the front-rear motors) and generating a roll angle. In the following, the involved hardware and its setup are explained. The quadrotor shown in Fig. 8 is designed as a test bed to investigate the issues of application of the modern control theory on embedded systems of unmanned aerial vehicles (UAVs). Also, this platform was built with on-board hardware and processing, it is designed to be self-contained and to perform all the computing on board. Its low cost and the availability of its constituent parts makes it attractive for research, educational and commercial use.

3.4.1 Hardware architecture

The quadrotor test-bed, as shown in Fig. 8, comprises light-weight alluminium rods of length 666 mm connected to a glass fiber center piece, forming the desired cross structure for the frame. Its total weight is 0.415 kg. Four motors with propellers are installed at the ends of the rods. The hardware devices are installed in the center of the frame for balancing the inertia moments. The four propulsion units are made of brushless DC motors connected to electronic speed controllers (ESC) to provide their actuation. Each motor is a Turnigy D3536/9 910 KV, a three-phase outrunner and sensorless brushless DC motor. The motor velocity constant Kv is 10 rpm/V, it provides 212 round per seconds when supplied in the range 14.8–15 V, the motor’s maximum current is 21 A with a power consumption of 370 W at 15 V. Each motor has a weight of 0.102 kg and is actuated by an ESC Turnigy PLUSH-30A having a weight of 0.0425 kg. A two-blade propeller Slow-Fly-Electric-Prop 9057SF having size 9 x 4.7 inches (9 in diameter size and 4.7 in pitch size) is directly connected to the motor’s shaft, it provides a total thrust of 0.632 kg at full speed for each motor. The system is powered by a 2600 mAh, 14.8-Volt lithium polymer battery, it is a Turnigy nano-tech 2600 mAh-4S 25-50 Li-Po Pack having a weight of 0.210 kg. A sonar sensor is installed under the center of the frame for altitude measurements. In the center of the frame is found the inertial measurement unit (IMU): Drotek 10DOF V2 with a MPU6050 gyro and accelerometer plus HMC5883L magnetometer and MS5611 altimeter. The IMU has a MPU6050 module with a triple axis 3 g accelerometer (BMA180) and a triple-axis gyroscope (ITG3200), a triple-axis magnetometer HMC5883L, and an altimeter with a baromether MS5611-01BA03. The bandwidths of all the sensors are trimmed to 10 Hz. The MEMS inertial sensors are combined with filtering techniques for the online estimation of the attitude angles. The hardware architecture of the quadrotor allows to power its electromechanical and electronic parts and to communicate with sensors and actuators. The platform is designed to perform sensing and computations on board. The off-the-shelf electronic components have been chosen to fit into the structure of the system. The proposed architecture is shown in Fig. 9. It shows the connections at the signal level among the embedded board and the other devices. The power source of the whole system is the Li-Po battery which provides a voltage of +14.8 Vdc, which powers the electronic-power-board that linearly regulate the voltage level and distribute it to the ESCs by means of a power-divider hardware. Furthermore, the electronic-power-board decreases the voltage level to both +5 and +3.3 V needed to power the sensors and the embedded boards. Figure 8 shows hardware layout and points out the electronic and electromechanic parts of the quadrotor.

4.1 Embedded hardware choice and holonic software structure

The choice of the embedded architecture both for hardware and software provisions has been oriented to a real market replication of the robotic solutions here studied. Although many choices are currently available for implementations, here, we are not only concerning with scientific results but also with the technological issues and costs of the solutions. The current choice of hardware components and boards has been influenced from the products that are actually available on the market, at least for the next 5 years. Of course, we do not rely completely on current products but we suggest some enduring design criteria for the setup of the architecture choice basing on the case studies at hand. Some practical guidelines should be followed to let scientific experiments be oriented to a fast market take-up of the solutions by assessing their feasibility, cost and scalability of the technologies involved. When we chose a hardware architecture for the experiments, we have to bear in mind that it should be produced and engineered with the best available technology.

Having the robotic solutions here illustrated conceived in didactic context, the aim is the instillation of the awareness in robotics students and communities about the engineering requirements and design constraints in typical implementation of the interested class of robots. The current choice went toward an interesting set of commercially available micro-controller unit (MCU) solutions provided by Renesas. Attention was paid to the motor control oriented features of the RX series microcontrollers.

With finding most of the needed peripheral and device provisions available on-chip, it guarantees a good design starting point for a customized board at reduced costs and ready for mass production. Moreover, we had in mind a clear and scalable hierarchy of parts that must add-up to constitute a more complex robotic system featuring artificial and distributed intelligence, possibly in cloud systems [18].

The main underlying idea is to pursue a holonic approach [19] where the regulatory layer can be put in connection, though semantically separated, to the higher intelligent, collaborative and distributed layer. So, the choice of RX series MCU has been considered ideal for the regulatory layer where the control policy can be implemented while in connection to a wider and more complex system, by the use of apt design of the low-level control scheduling policies. Holonic and collaborative system configuration is achievable within a real-time operating system infrastructure, which can handle the low-level regulation while managing the higher information interconnection.

The first choice went to the RX63N, RX631 group which consists of 32-bit microcontrollers capable of operating at up to 100 MHz with on-chip FPU, DSP instruction set, with nominal 165 Dhrystone MIPS computing performance. Of course, they can not be claimed as the fastest nor the best MCUs, but already stable and in mass-production. Moreover, our practical exercise is to put ourselves within the typical design constraints encountered in embedded electronics engineering, not a comparison among MCUs architectures and producers. The chosen constraints of course should guide the designer to an optimal solution just enough to address the needs, and this is the good practice exercise here suggested.

RX63N series feature up to 2 Mbytes fast coupled internal flash memory, that can allow the fast execution-in-place of a low footprint real-time operating system and all the needed control and communication algorithms. It provides up to 256 kbytes of static RAM and added 32 kbytes of data-specific flash for fast data access and DSP computing.

The RX63N has an Ethernet controller with dedicated direct memory access (DMA), which is suitable for networking (in holonic sense) and a hardware communication encryption unit (i.p. AES encryption and decryption functions) that is a must-have in all the devices approaching the Internet of Things. This MCU family is mostly interesting for their plenty of timers that can be used in motor control both for sensing and actuation, in particular, the multi-function timer pulse unit (MTU) designed for motor control and PWM generation and sensing. MTU is a multi-purpose timer peripheral that allows the sensing and output of a vast set of waveforms that are essentials in motor control issues.

Given the examples discussed here in this paper, a commercial hardware board that implements the regulation and control part of the one of the three systems can be safely attainable with less than US$20 in mass production, lest special quality production needs that may raise the bill of materials cost. So, we consider our experiment framework an interesting guideline and test-bed for didactic and commercial solutions in self-balancing robotics components and applications.

4.2 Real-time scheduling

Real-time scheduling of concurrent processes and actions is a hot theme in embedded systems [20]. In our robotics case, the regulation layer must act within hard real-time constraints as the controllers can not miss any contact with the physical world dynamics. At the same time, a collaborative and holonic structure needs be in timely communication with the higher control layers where real-time constraints can not be guaranteed or not strictly needed. A currently common solution, which many practitioners adopt, is the deployment of small-footprint real-time operating systems and the strict separation among deferrable and preemptible processes and uninterruptible ones.

The treatment of an optimal use of CPU resources under advanced scheduling policy is beyond the scope of this work. In the present experiments, things have been kept as simple as possible to rely on good hardware parallel architecture capabilities for the specific and limited number of actions in the control layer.

In most of the self-balancing systems, the control is obtained with a measurable duration of the computation, action and acquisition. By measuring the duration of a control period, the sequence of discrete-time controls on temporal basis can be easily scheduled. In these simple cases, a round-robin policy is enough to achieve the results. A simple scheduling solution should rely on the peripheral provisions of the RX architecture. In particular, scheduling events can be controlled by the periodic interrupts generated with the programmable compare match timer (CMT) unit. These interrupts are used to schedule among different processes and uninterruptible driver phases during the control period. After a measuring of these deterministic periods and appropriate time guards, the remaining time slice in the control period is to be reserved to external remote interaction and to the communication of parameters, information exchange and interaction with other machines. Modern lightweight RESTful approaches and similar approaches should be allowed also on tiny and resource constrained devices [21].

The processes involved in external communication, and at the highest level in holonic architecture, must be preemptible and interruptible, so their priority is kept lower and they can be scheduled on a session basis. Indeed most of them are prone to a packet-wise communication like in UDP/IP-based connections.

The rest of the control action, on the contrary, has to act and react with hard real-time limits. The duration of the acquisition, processing and output transduction must be fixed and deterministic. Within those design constraints, a 150-ms control period is chosen. It has been assessed as a suitable control period for the three applications at hand, basing on robust control theory and experience in the field. During this computing period, four motors are controlled, the sensing and control processing is performed and then a time slot of nearly 80 ms is left for the higher level tasks, like UDP/IP-based communications. Being this last task preemptible and interruptible, it is allowed to be spread across several control periods to complete with no harm to the overall application purposes.

The use of a more effective and advanced real-time scheduling technique, as the earliest deadline first (EDF), would allow for an optimal responsiveness of the system at possibly higher control rates. Nevertheless, the design overhead for the implementation of EDF scheduling can be avoided in simple cases if the accurate design of robust control algorithms can compensate inherently the rigidity and limitations of the round-robin scheme.

4.3 Embedded system: hardware and software

The design of accurate and efficient embedded control system is a key issue to ensure the correctness of the robotic leg’s movements. Below, both hardware and software topics will be addressed. The proposed embedded hardware (Renesas YRDKRX63N) is not based on expensive controllers for single motors but on a general purpose evaluation board which are proposed for driving at the same time at least three motors of the robotic leg, of the robotic ballbot and the four motors of the quadrotor. The embedded board has a 32-bit RX63N MCU of the RX family/RX600 series. It communicates with the embedded devices and sensors.

The functional diagram in Fig. 10 shows the functional interactions between embedded sensor/devices and MCU’s peripherals. Figure 10 shows that the low-level embedded control reads sensor data and generates a PWM signal for the DC-driver unit which drives the DC motor. Figure 10 also shows the board’s peripherals involved in the control process. The MCU uses an on-chip compare match timer (CMT) for timing the processes, the multifunction timer unit (MTU) generates PWM signals while, MTU and timer pulse unit (TPU) are used to acquire data from encoders. The analog to digital converters 10/12 bit (ADC 10/12) are devoted to read the current sensors while general purposes input/output (GPIO) digital ports are used to define the shaft’s rotation direction. The serial communication interface (SCI), set in universal asynchronous receiver-transmitter (UART) mode, is used to send the variables of the motor and of the sensors to a MATLAB-Simulink™script running on a PC for the early experimental tests.

4.4 Embedded software

In this section, the software architecture of the embedded control system is presented. The block diagram of the feedback control system for a single DC motor, which is implemented on the embedded system, is shown in Fig. 11.

The software implementing the embedded system is made of four main parts: initialization, timing and interrupt routines, acquisition of sensor measurements and controller implementation. In the following subsections, these parts will be introduced.

The reference signals, θ _r rather than ω _r or i _r are set using a high-level controller, which description is out of the scope of this paper. T _M and S _M represent switches that select control modes: the torque mode and the speed mode, respectively. The position θ _m and speed ω _m of the motor are measured using the signals generated by the encoder. The difference between reference and measured signals are, respectively, the input for the position or the speed for the control algorithm. The position and the speed controllers set the reference for the current controller. Otherwise, it is possible to set directly the motor torque from the high-level controller. Basing on the difference between the reference and the measured current, the current controller computes the new duty cycle value of the PWM control signal. The PWM generated by the microcontroller controls the driver of the DC motor. The measured current is also used for the overcurrent protection—if the current exceeds a certain limit, the PWM control signal is disabled. In the current feedback loop, an exponentially weight moving average (EWMA) filter is used to obtain a reliable current signal from the current sensor. The software implementing the embedded control system of a single DC motor can be divided into four main parts: initialization, timing and interrupt routines, acquisition of sensor measurements and controller implementation. In the following subsections, these parts will be introduced and Fig. 12 shows, as an example, the flowchart of the embedded software when the position feedback control mode is selected by high-level controller.