A suitable hardware and software structure has been identified as a common ground to satisfy the needs of our three experimental robots. The chosen embedded system consists of an evaluation board with its several modules and components. The evaluation board is only adopted for prototyping purposes, while the final redesign of a customized board has to be foreseen for a final optimized prototype with unused components pruned and so ready for real series production.
Embedded software has been implemented, over the environment of the compiler and driver libraries available from the MCU vendor, in order to enable the communications between the different hardware devices of the robot, namely three DC motors with gearboxes and angular encoders, on inertial measurement unit (IMU) and the robot’s controllers. Our software provides the necessary filtering of inertial measurements and the communication with external environment.
With the help of the proposed embedded system architecture, each motor can selectively operate in torque or speed or position control mode, and this can be done for each of three DC motors. In particular, the hardware of the robotic leg is composed by three motors with a gearbox. Each motor is equipped with a rotary optical encoder and with a low-cost current sensor. The hardware of the embedded system is based on a commercial low-cost embedded board equipped with a 32-bit micro controller unit (MCU). The embedded software implements the control by using only the peripherals available on board. A serial communication protocol is used to send the sensor signals to a MATLAB-Simulink™script running on a PC which stores and shows the system behaviors through a serial communication connection. The performance of the proposed embedded control system is assessed by experiments on the motor and by simulation tests on the motor’s mathematical model.
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.
4.4.1 System initialization
In this subsection, the steps required for the initialization of the system are presented. At first, all the peripherals used by the embedded board are initialized according to the hardware user’s manual of the RX63N microcontroller. The used variables are also initialized. Before the start of the main loop, the voltage offset of the current sensor is evaluated to ensure the correctness of the voltage-to-current conversion. In order to remove the offset error, a preliminary cycle of 500 ms is done when no current is absorbed by the motor, so that the voltage reading will become the zero ampere reference.
4.4.2 Timing and interrupt routines
An embedded control system assures real-time constraints through the interrupts of the MCU. Synchronous interrupts are required for the control algorithm of the DC motor. The synchronous interrupts are generated in the main loop and they are timed every 5, 10, and 80 ms by the CMT peripheral; in particular, the first timing slot is used for each data acquisition, the second timing slot is used for both data acquisition and control algorithm, and the third timing is used to manage the communication with an external device or PC. Asynchronous interrupts are instead used for the acquisition of the encoder readings. Synchronous interrupts are required for the control algorithm of the DC motor.
4.4.3 Acquisition of sensor measurements
The motor current is measured using a current sensor and is acquired using the analog to digital converter (ADC 10/12) of the embedded board. The ADC can generate high-precision results, but a filtering procedure is required due to the low resolution of the current sensor. This ADC data acquisition is timed 5 ms in order to have the sensors measures ready for the control loops but the readings of the ADC peripheral will be available only every 10 ms because we let 5 ms for data processing. The encoder readings are done by the MTU and TPU peripherals that use asynchronous interrupts. The query function to retrieve encoder’s data is read at the same time of the ADC reading that is every 10 ms. The encoder generates two quadrature encoder signals. These signals are applied on two MTU (or TPU) input type pins. The encoder is configured to generate processor interrupts at a fixed rate. The speed of the motor is computed basing on the number of encoder pulses per revolution. The instruction clock cycle of the microcontroller, the number of edges which are accounted by the MTU (or TPU) of the microcontroller (rising, falling or both edges) and so the number of counted edges during the considered time interval. The value is loaded in the register of the timer associated to velocity measurement and has to be set such that the divisor is a power of two, and to perform a register shift instead of a division.
The IMU data are retrieved using an I
2
C protocol provided by the board on-chip peripheral RIIC and supported by our peripheral driver that uses interrupt handling routine to drive the device through apt operations.
4.4.4 Controller implementation
For the ballbot and the robotic leg applications, three discrete time-cascaded PID controllers with anti-windup system are implemented for each motor [22, 23]. The computations are performed by the same function for each controller using different parameters. The cascaded controllers work according to the scheme of Fig. 11 and generate the input voltage for the DC motor. The last step of the control algorithm, shown in the flowchart of Fig. 12, is to convert the voltage value in a PWM signal and generate a direction signal in order to drive the DC driver. The PWM signal is generated by the MTU peripheral, where a function is called to convert the voltage value into the register counter which defines the PWM signal. The controller will generate the input voltage for the DC motor. The last step of the control algorithm is to convert the voltage value in a PWM signal and to generate a direction signal in order to drive the DC driver. The PWM signal will be generated by the MTU peripheral.
A linear full state-feedback LQR (linear quadratic regulator) controller based on a linearized model can be proposed for the system control, in particular, in the ballbot case. The computations can be performed by the same embedded board.
For the quadrotor, the former PIDs are not needed because the control of the rotary wings is performed completely by the ESC units.