INSTALACIÓN DE APACHE

At the lowest level, there are a number of raw I/O processes, which includes the motor control processes that keeps publishing to four chains of the Dynamixel actuators at 120 Hz, the IMU process that reads accelerometer, gyro, and filtered orientation data at 100 Hz, the camera processes that updates camera frame grabs from head and wrist cameras at 15 Hz and 5 Hz, the auditory process that monitors the microphone signal levels. They typically uses shared memory interface as the new data are streamed in roughly fixed rate.

Figure 1.16: The software architecture centers around shared memory

ception processes accumulate the sensory data, build a 3D mesh and detect features, before sending the results to the remote operator. Lower and upper body motion controllers receive high level commands and generate motions for the lower or upper body, such as locomotion or manipulation motions.

Finally, a number of finite state machines (FSMs) govern the high level behavior of the robot. An overarchingBodyFSMcontrols the underlyingMotionFSM,ArmFSM, andHeadFSMmodules. Each state machine is updated at 120Hz to match the motor update rate. The MotionFSMhandles the locomotion and balancing of the robot, theArmFSMruns the upper body control, and theHeadFSM

controls head motions. TheBodyFSMtransition between waypoint following, standing and driving modes by sending signals to the other state machines. Once in a standing mode, theArmFSMcontrols arm states, such as valve pre-positioning, tucking arms, and entering teleoperation. Transitions are commanded remotely and forwarding via the remote procedure call system.

Low Level Management

The low level communication with the actuators and sensors is split into a completely separate pro- cess from the high level behavioral logic. This separation ensures that the low level communication is continuously operated at the highest rate possible, regardless of the rest of the system. With- out such separation, a high processing load at other part of the system may disrupt the low level

communication of the robot, possibly resulting in jerky or unstable movement of the robot. The communication process constantly writes all servomotors’ desired angles and reads the servomo- tors’ current joint encoder measurements; it also polls onboard sensors such as inertial sensors or buttons.

The platform-specific motors and sensors process manager interacts with the NaoQi10 module and, for the more general DARwIn platform, interacts directly with the Dynamixel servomotors and onboard sensors using the Dynamixel protocol11. Linux shared memory managed motor and sensor data for use across processes. Two shared memory blocks store motor data and sensory data. The motor block includes motor command variables such as target position, electrical compliance, maximum velocity, and other related variables. The sensory block shares readings such as joint encoder values, as well as accelerometer and gyroscope measurements. By using shared memory, other processes, like MATLAB, can provide debugging tools.

Simulation

The Webots [95], [153] simulation platform aids in evaluating the software behaviors. Using a simulator allows for rapid prototyping, with reasonable speeds, even for full physics simulation. Shown in Figure1.17is an example of two teams of four robots running our code. Each team (or even each player) can be slightly modified to run a different parameter set. The software is tested on Mac and Linux operating systems. Support for the Gazebo simulation platform [72] allows a diversity of simulation platform..

The software platform is extensively tested in competition each year during RoboCup. The physical model in simulation helps to identify torque limits for motions and validate dynamic mo- tions before attempting on the physical robot. The simulated physics updates at 8ms, while the simulated sensors update at the same rates as the physical robot. The operator systems interact with the simulator or real robot with minor configuration tweaks.

10_{Aldebaran Nao documentationhttp://doc.aldebaran.com}

11_{Dynamixel protocol specification http://support.robotis.com/en/product/dynamixel/dxl/}

Figure 1.17: Teamplay is simulated using Webots to rapidly prototype behaviors that perform simi- larly on real hardware.

Kinematics and Keyframes

The locomotion code uses forward and inverse kinematics solvers that platform specific to account for the differences in humanoid limb configurations. Due to the possible hardware constraint such as the hip joint of the Nao robot, platform specific kinematics solvers must be used. Figure1.18 provides an example of two humanoid kinematics configurations.

Using the platform specific kinematics solvers, a system retrieves motor mapping from anatomi-

cal descriptions of the humanoid to joint ids. This allows functions to be named aptly asget head position, etc. In addition to commanding limb end effectors to certain positions, prerecorded keyframe mo-

tions can be played back. The keyframe motion is typically used for kicking and standing up behav- iors. Keyframe data is platform specific as well, which is automatically selected for each platform by the specification in the configuration file.

Figure 1.18: The kinematics of the Nao [38] and DARwIn-OP share a humanoid morphology.

Locomotion

In the framework, the zero moment point (ZMP) [149] based omnidirectional dynamic walking controller governs humanoid locomotion. An analytic ZMP trajectory is generated in real time ac- cording to the commanded walk velocity from the Behavioral logic. The center of mass (COM) tra- jectory is also calculated in real time to meet the ZMP criteria. A combination of the optimization- based approach such as ZMP preview method [63], [136] and the analytic solution of a piecewise linear ZMP target is employed for specialized locomotion methods [164]. This combination pro- vides the best of both worlds for reactive walking with application specific motions. After the foot and COM trajectory is calculated, the inverse kinematics solver generates joint angle values for the leg actuators. Shown in Figure1.19is a detailed look at how commanded walking velocities are transformed into joint commands.

The walking controller also includes stabilization control using sensory feedback to reject exter- nal disturbances and surface irregularities. Two sources provide sensory feedback - proprioception and inertial measurements. For proprioception, joint encoder angles from leg actuators and the rel- ative angle between support leg frame and torso frame are fed to the forward kinematics solver. For inertial feedback, the current angular velocity of the torso are measured using the torso-mounted gyro sensor. These feedback sources provide negative feedback on the desired torso angle in order

2 0 0.2 0.4 0.6 0.8 1 -1 -0.5 0 0.5 1 0 0.2 0.4 0.6 0.8 1 Step Planner

COM Trajectory Generation

Foot Trajectory Generation

IK solver Reference ZMP Trajectory Foot Target Position COM Trajectory Foot Trajectory

Figure 1.19: The motion diagram shows how humanoid steps are planned.

to stabilize the robot under disturbances.

The walk controller can be used for general humanoid robots and has a number of configurable parameters that influence the performance of the walking. While the default walking parameters will work as a good starting point, users should tune them when it comes to adapting the framework to their humanoid.

Finite State Automata

The behavioral logic is a Lua codebase that is shared across disparate humanoids and controls the high level behavior of the robot. This behavior includes tracking a ball with the camera, walking towards that ball, kicking the ball when the ball is in range, etc. It initializes the DCM process first so that the robots’ sensors and actuators are available for communication, and then it starts the main loop which regularly updates the behavior state machines. Each behavior state machine then communicates with the low level subsystems to get access to hardware functions such as head movement or walking.

The motion state machine controls the overall behavior of the motion subsystem. It provides abstract commands that the behavior logic module employs, such as ‘standup’, ‘walk’, and ‘kick’. The motion state machine dispatches these high level motion commands to start the appropriate behavior. Also, by checking the IMU sensory data, the Motion state machine can detect if the robot

is falling. It then reacts accordingly to minimize the falling damage, and initiates a stand up motion according to the fallen posture of the robot.

HeadFSMs BodyFSMs Motion System Vision System World Model Servos Sensors IMU, Buttons FSR, Ultrasonic Camera

Device Comm Manager Motion State Machine

Walk Engine IK Solver

FK Solver Keyframes

Lookup Table Blob Finder Object Classifi ers Localization Obstacle Avoidance Team Coordinates Ball Model Network Test Files GameFSMs

Figure 1.20: The system architecture is divided into low level drivers (boxed in red) that interface with separate Motion and Perception systems. At the highest level, finite state machines direct be- havior based on these systems, communicating over shared memory and a message passing system.

Shown in Figure1.20is a high level overview of how data flows in the system. There are three processes that execute the the vision system the device communications manager (DCM) and the motion system state machines. Data is shared using a shared memory segment on the system, where the world model, vision system, motion system, and DCM have their own memory segments. These segments can be read by any other process. For instance, the localization system requires odometry information from the motion system, which is shared using this memory segment.