Implementation

For Serval, we decided to pursue a path in the middle between Oncilla and the Cheetah- Cub-family, regarding motor-quality and sensorization, creating a more powerful system than Cheetah, whereas keeping complexity and cost lower than Oncilla. Our strategy was especially to re-use an existing control framework implemented in [112] with only small modifications. This decision was taken as a consequence of our shrinking development team, as colleagues working on control for quadruped robots finished their work in BIOROB and left the laboratory before Serval was built. Hence, Serval employs two different high-quality servo motors (Dynamixel MX64R and MX28R) in combination with an Odroid XU4 SBC, also used in the already developed control framework. Dynamixel motors consist of a small Maxon EC motor combined with a spur-gear (relatively high gear ratio of 200 : 1) and a servo-motor- board. They are capable of serial communication via an RS485 bus, giving the possibility to daisy-chain them and consequently skimming down the cabling effort. A small PCB was designed to distribute electricity from power-supply or an internal 3-cell to 4-cell Lipo battery to the motors and SBC (two PCBs in total for fore and hind trunk, respectively). The board was also acting as an interrupt in case of motor-communication failure. In this case, the motors control had to be reset by cutting the power-supply. By using the interrupt on the PCB, the power to SBC was kept unaffected from the reset. For the initial setup of Serval, sensorization was kept to an absolute minimum, as primarily mechanical effects on locomotion capability and stability were of interest. Internal leg states (joint positions) could support closed loop control, but were also a source of errors in Oncilla. With Serval we wanted to see whether or not these sensors were necessary for agile movement and control. Besides a low-cost Biscuit- Programmable Wi-Fi 9-Axis Absolute Orientation Sensor (IMU) [113], we foresaw the use of GRF-sensors located on the robot’s feet. Due to the weight of available Optoforce sensors used in Oncilla, that amounted to about half of one legs weight (≈ 50g), we did not integrate the mentioned GRF-sensors, keeping leg-inertia minimal. Further search for plausible sensors led us to [114, 115], who implemented capacitive sensors in a small and lightweight package. Due to the late discovery of these sensors, we did not yet get the chance to customize and implement them on the robot. Additionally, plans to integrate sensitive skin for physical guidance are being realized [116, 117] in the close future.

Advantages and Disadvantages in Serval

Advantages Servo-motors with serial communication capability and a minimal (off the shelf)

sensor set, kept the electronics setup very simple and cost-effective. No specialized drivers had to be written, and motors were hypothesized to be more reliable than cheaper RC-servos. Using the same electronics hardware as our colleagues made collaboration possible. We thus benefit from an already debugged and tested control-architecture possible. An additional

Chapter 6. Domain Specific Design II: Electronics

advantage in a simple electronics implementation is the ease of replication, e.g., by other research groups or future team-members of BIOROB.

Disadvantages Serial communication through a bus does not allow for real-time control,

as command and read-out cannot be done in parallel and as high control frequencies as in Oncilla. This and the servo-motors speed/torque relations limited the overall locomotion frequency for locomotion to a maximum of 2 Hz. As small animals tend to move in higher frequencies, this could impact on the feasibility of using, e.g., high-frequency gaits like a gallop. Closed loop control is possible in Serval, but in its current development state (without GRF sensors) limited to posture control implementations and physical guidance tasks, see section 11.2.

Conclusion

The overall available electronics in Serval, allow for agile gait implementation, but not as sophisticated control as in Oncilla. Depending on future directions, sensors should be added and integrated into the electronics framework. The effort for communication, low-level control as well as sensor development is kept to a minimum by employing off-the-shelf components and liberates development time for other aspects.

7

Domain Specific Design II: Control

After [11] the staff involved with robots should be divided into two groups, the robot handlers (using the robots to answer scientific questions or achieve certain goals) and the robot main- tainers (responsible for development work and operational maintenance). In case of robot control, I was not directly involved with the development part and mainly used or modified parameters provided by the control algorithms to generate locomotion patterns.

For this reason, we strongly reference the interested reader to the thesis of our colleagues Mostafa Ajalloeian [12], Alexandre Tuleu [11], the future dissertation of Tomislav Horvat and MA-thesis of Anja E.M. Schmerbauch [118] who were the minds behind most of the control efforts implemented in our robots. The employed methods will be described on an abstracted level in the specific robots sections of this chapter to facilitate the understanding of how control and experimentation were undertaken.

7.1 General Introduction of High-Level Concepts used for Locomo-

tion Control

Generation of desired control signals and the coordination between existing actuation can be achieved by imposing pre-defined open-loop patterns or relying on sensory feedback to modify the actuator states. The first approach often uses biological (mostly kinematic) data in form of MOCAP recordings for the pattern generation, whereas the second is often characterized by building on template models of locomotion. Agile motion of a robot as a sub-part of locomotion in general is one result of using either method. Both approaches can also be combined as shown in [12], relying on the implementation of a CPG-network with its modulation by sensory feedback (reflexes). In this section, we will define and describe the general control concepts we employed in our quadruped robots.

Chapter 7. Domain Specific Design II: Control