Control of a Hexapod Robot Considering Terrain Interaction

Abstract

Bioinspired walking hexapod robots are a relatively young branch of robotics. Despite the high degree of flexibility and adaptability derived from their redundant design, open-source implementations do not fully utilize this potential. This paper proposes an exhaustive description of a hexapod robot-specific control architecture based on open-source code that allows for complete control over a robot’s speed, body orientation, and walk gait type. Furthermore, terrain interaction is deeply investigated, leading to the development of a terrain-adapting control algorithm that allows the robot to react swiftly to the terrain shape and asperities, such as non-linearities and non-continuity within the workspace. For this purpose, a dynamic model derived from interpreting the hexapod movement is presented and validated through a Matlab SimMechanics^TM simulation. Furthermore, a feedback control system is developed, which is able to recognize leg–terrain touch and react accordingly to ensure movement stability. Finally, the results from an experimental campaign based on the PhantomX AX Metal Hexapod Mark II robotic platform by Trossen Robotics^TM are reported.

1. Introduction

Mobile ground robots emerged as an alternative to several tasks originally performed by humans, such as surveillance, reconnaissance, entertainment, personal services, patrolling, and industrial automation, to cite a few [1]. Particularly, nowadays, interest is focused on tasks involving complex and potentially hazardous situations such as planetary exploration, emergency rescue operations, and, more in general, intervention in extreme environments [2].

Mobile ground robots in the literature differ regarding locomotion, surrounding perception, and control methodologies. Focusing on locomotion, they can be grouped into the following:

• Wheeled robots;
• Tracked robots;
• Legged robots;
• Hybrid robots [1].

Wheeled robots are characterized by high speed, high energy efficiency, and a cost-effective design, so they are widespread in industrial, service, and delivery applications on mostly flat surfaces [1]. Conversely, tracked robots are more appropriate for movements on soft and irregular terrains because they have a larger surface in contact with the ground, and they are also able to climb over obstacles [3]. Legged robots show superior mobility compared to wheeled and tracked robots since they can navigate through any terrain, climbing rocks and rough surfaces like humans and animals [1,4,5]. These extraordinary capabilities and their versatility that allow them to operate in different environments make them the preferred choice for search and rescue [6], exploration [7], agriculture [8], or operations in dangerous environments [9,10,11] despite their high complexity and cost. Finally, some hybrid robots combine these locomotion types, being equipped with legs and wheels or tracks as paws. These robots have the same adaptability and agility as legged robots because they can easily overcome obstacles and perform different types of gaits on uneven terrains and, at the same time, can achieve high speed with great efficiency on flat surfaces [12]. Nevertheless, the complexity of the design limits the optimality in both aspects [13].

The choice of using bioinspired paws or hybrid locomotion depends on the particular type of terrain in which the robot is supposed to operate. Still, the main parameter that influences the performance of a legged robot is the number of legs [1], and they can be one of the following:

• Bipedal robots;
• Quadrupedal robots;
• Hexapod robots;
• Multilegged robots with more than six legs.

Bipedal robots are mainly humanoid robots designed to replicate many human abilities, such as grasping, handling objects, or human-like sensing, and locomotion is just one of the several tasks these robots are capable of performing. Nevertheless, many humanoid robots can run, jump, climb, and move in any environment with extreme agility [1]. The disadvantage of bipedal locomotion is the intrinsic instability of this gait, which is why humanoid robots require very complex control algorithms to maintain balance even when they do not move.

Quadrupedal robots are the best-performing walking robots in terms of speed and payloads [1]. Moreover, they have the advantages of allowing different gait types and being statically stable when they are not moving. Nevertheless, they still require very complex control algorithms since they possess many degrees of freedom that must be coordinated, and most performing gaits need dynamic walking control since only two limbs are in contact with the ground.

Hexapod robots, instead, always have three limbs in contact with the ground, so their gaits are stable, making walking control much simpler despite the increased number of degrees of freedom to coordinate [14,15]. This stability makes them particularly suitable on uneven or slippery terrains where bipedal or quadrupedal robots struggle to find a stable gait. Furthermore, their redundancy allows them to operate by still using quadrupedal locomotion if one or two legs are not functioning [1], which is a significant advantage for operations in places difficult or unsafe to reach for humans. Robots with more than six legs do not have particular advantages over hexapod robots apart from the increased variety of gaits and the improved redundancy, but these come at the cost of more complex control due to the additional degrees of freedom.

2. State of the Art

In the field of ground robots, one of the crucial benefits of hexapod robots is their outstanding ability to operate on virtually any terrain. An essential aspect is represented by the detection and mapping of terrain shape and unevenness. Common approaches for ground classification can be classified as Visual-Perception-based, Depth-Perception-based, or Tactile-Perception-based, as reported in [16], where all three families of sensors are combined in order to achieve improved accuracy. Visual-Perception-based systems take advantage of image processing for ground classification, starting with cameras. In [17], an online terrain-classification system for hexapod robots capable of adapting energy-efficient gaits is presented, which is based on feature extraction and SVM classification of a monocular camera output, achieving up to 90% accuracy on terrain images. Another example is reported in [18], where an algorithm based on neural networks is used to identify the terrain from an RGB image to define surmountable obstacles and zones. Vision-based terrain mapping is also used in [19], where visual sensors are used to detect the terrain shape using point clouds and unsupervised learning techniques and to control the interaction between two collaborative robots. Depth-Perception-based classification relies on the use of depth data, usually in addition to images from cameras as presented in [20] with the purpose of characteristics extraction and objects or plane identification. Finally, Tactile Perception relies on using sensors such as IMU, pressure, or torque sensors to perceive the presence of the ground, usually thanks to the measurements (forces and torques) at the tip of the leg as reported in [21]. In this paper, a terrain map is considered as known since it is not the aim of this research.

In order to exploit the potential of hexapod robots in uneven terrain conditions fully, the interaction of their paws with the ground must be taken into account both in the robot’s mechanical design and the implementation of the control algorithm [15,22] to properly provide counteraction to terrain-reconstruction errors. For this reason, the most advanced control techniques of hexapod robots not only include a kinematic and dynamic model of the robot itself but also consider the forces that the paws exert on the ground. They use this information to detect contact, consider terrain deformation, and avoid slipping. Among all the possible improvements that are introduced by adding a model of interaction with the ground to the control algorithm, contact detection is the most useful since it allows the robot to maintain balance on uneven terrains and in the presence of obstacles because, by knowing which paws are in contact with the ground, the robot can adjust its posture and adapt its gait to accommodate terrain unevenness, distributing the weight better and improving stability [22].

In addition, real-time feedback on contact detection reduces the time needed for each leg to search for contact with the ground, making the transition between consecutive steps faster and smoother.

As already introduced, contact detection can be achieved by directly measuring the force between each paw and the ground with pressure or force sensors or by estimating this force by measuring the torque or the current of the motors of each joint of the legs [15]. The first approach gives a more accurate measurement of the contact force, but it requires placing sensors under the robot’s paws, adding complexity to the geometry of the paw [23,24,25,26,27,28]. In addition, this strategy relies on components that continuously receive impact forces, and they might easily break. Conversely, estimating the contact force by measuring the motors’ torque is a less accurate but more reliable approach. Furthermore, in some scenarios, position feedback can be sufficient to accurately identify terrain presence and maintain horizontal positioning at all times [29,30,31].

In the field of legged robotics, companies offer proprietary solutions, such as Boston Dynamics [32], or others are more focused on academic research, like Robotis [33] and Trossen Robotics [34]. From a software perspective, academic research tends to favor the use of open-source solutions to provide greater access and control over the robot’s implementation. In this context, various frameworks enable the programming of hexapod robots. In particular, NUKE [35] is open-source software designed specifically for the control of hexapod robots. It is optimized to manage the locomotion and kinematics of these robots through an intuitive interface and predefined configurations that facilitate programming and customization. Compared to more general-purpose solutions like ROS2 [36] or ArduPilot [37], NUKE provides predefined and customizable solutions that reduce complexity and accelerate the development of hexapod projects. This makes it a convenient choice, although its support is less extensive and its updates are less frequent compared to other solutions, particularly ROS2.

Based on the previous discussion, the main contribution of this work consists of a deep analysis and extension of the inverse kinematics formulation of NUKE to include the orientation and height of the robot’s body from the ground as additional input to the position of the robot’s leg’s end effectors. Moreover, this paper proposes a comprehensive architecture for handling terrain irregularities that leverages the extended functionalities of NUKE and estimates joint torques in the event of individual leg contact with the ground using a dynamic hexapod model. The standard implementation of NUKE suffers from the main limitation that most multilegged robot-control software has. While perfectly able to move the robot smoothly and adjust stride correctly through a gait engine, they can generally not interact with anything other than flat, continuous, obstacle-free terrain [38]. This paper aims to extend the advantages of the NUKE code in the presence of non-flat, non-continuous, irregular terrain. In particular, the underlying objective is to develop a kinematic model that can account for the terrain shape and location and to improve this analysis further to understand how the robot’s physics interacts with the presence of the ground. By utilizing this estimate alongside the one provided by the robot’s servomotors, a feedback control system was developed without the need for sensors at the ends of the legs. In order to implement and test the proposed architecture, PhantomX AX Metal Hexapod Mark II from Trossen Robotics^TM [39], shown in Figure 1, is considered. It is a versatile, inexpensive, and lightweight robot. Moreover, it is fully programmable, compatible with NUKE, and based on open-source hardware. It has neither force feedback sensors on its legs nor an IMU in its standard configuration, but it mounts 18 Dynamixel^TM AX-12A Smart Servomotors [40] that can provide feedback on position and load estimates.

The novelty of this work is represented by the development of a control algorithm for hexapod robots that can maintain the robot’s body horizontally regardless of the slope and the unevenness of the terrain. This goal can be achieved without the addition of any sensors on the robot’s feet because the estimation of the motors’ torque allows it to detect contact with the ground, and by knowing the angles of each joint, the robot’s pose is reconstructed through inverse kinematics. In addition, this control algorithm extends the functionality of NUKE, an open-source software compatible with different kinds of hexapod robots and widespread in this field, making this work helpful for other studies involving hexapod locomotion.

In Section 3, the kinematic model and the procedure to account for ground shape are described. In Section 4, the dynamic model used to estimate the torque at each motor is proposed and numerically validated. In Section 5, the novel architecture system comprehensive of a compensation algorithm is presented, and finally, in Section 6, experimental results in different scenarios are reported.

3. Locomotion Control

Locomotion control of the hexapod robot is mainly accomplished through the direct command of its legs’ endpoints. Leg endpoints are defined as the 3D coordinate points located at the extremities of each leg, as shown in Figure 2.

Since legs are 3-DOF systems that lead to the endpoints, it is possible to attain full control of a leg by imposing its endpoint position and employing an inverse kinematics engine to calculate the associated servomotor angles.

Such control architecture offers the advantage of collapsing the description of each leg configuration to a single point position in space, leading to much simpler and clearer handling of the robot’s movement.

The position that the robot assumes at the deployment state is called the neutral position, and the associated endpoint coordinates are hardcoded into the robot controller software. This position represents a neutral state that the kinematic engine will use as a reference to build its walking gait.

3.1. Endpoints Handling

The coordinate systems employed in the kinematic analysis of the robot are presented in Figure 3. The global coordinate system is fixed at terrain level at 0,0,0 coordinates and will be used to account for the robot’s position with regard to the terrain and the environment. Therefore, for the first iteration, the transformation matrix for the global-to-body coordinate system $T_{globalbody,0}$ (alias: $T_{gb,0}$) is as shown in (1):

$$T_{gb,0}=\left[\begin{array}{cccc}1& 0& 0& {\mathrm{SP}}_x\\ 0& 1& 0& {\mathrm{SP}}_y\\ 0& 0& 1& {\mathrm{SP}}_z\\ 0& 0& 0& 1\end{array}\right]$$

(1)

where ‘SP’ is the starting position. Note that ${\mathrm{SP}}_z$ should be the initial robot height and must be consistent with the neutral position endpoint coordinates.

The body coordinate system and the legs coordinate systems instead move alongside the robot’s body and are used to both describe the robot’s orientation and solve the inverse kinematics for endpoint position and servomotor angles.

The transformation matrix that binds the leg c.s. and the body c.s. $T_{bodyleg}$ (as: $T_{bl}$) is defined as (2):

$$T_{bl}=\left[\begin{array}{cccc}1& 0& 0& x_j\\ 0& -1& 0& y_j\\ 0& 0& -1& 0\\ 0& 0& 0& 1\end{array}\right]$$

(2)

where in (2), $x_j$ and $y_j$ are the joint positions in the body c.s., from which it is inferred that $T_{bl}$ is unique for each leg as each leg has a different joint position.

Once the desired endpoint position has been defined, servomotor angles can be assessed. The convention used in the kinematic analysis is shown in Figure 4, where $ϵ$ represents the servomotor orientation and $\theta$, $\varphi$, and $\psi$ represent the coxa, femur, and tibia servomotor angles, respectively.

By expressing the desired endpoint position in the leg coordinate system, eventually, through (2), the servomotor angles can be calculated through (3)–(7):

$$\begin{array}{cc}\hfill & trueX=\sqrt{x^2+y^2}-l_c\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill & im=\sqrt{true{X}^2+z^2}\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill & \theta =-arctan\left({\displaystyle \frac{y}{x}}\right)-ϵ\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill & \varphi ={\displaystyle \frac{\pi }{2}}-arctan\left({\displaystyle \frac{trueX}{z}}\right)-arccos\left({\displaystyle \frac{l_f^2+i{m}^2-l_t^2}{2im{l}_f}}\right)\hfill \end{array}$$

(6)

$$\begin{array}{cc}\hfill & \psi =\pi -arccos\left({\displaystyle \frac{l_f^2+l_t^2-i{m}^2}{2l_f{l}_t}}\right)\hfill \end{array}$$

(7)

where in (3)–(7), $(x,y,z)$ is the position of the desired leg endpoint in the leg coordinate system, and $l_c$, $l_f$, and $l_t$ are the lengths of the coxa, femur, and tibia, respectively. The endpoint positions are defined in the body coordinate system; therefore, their significance is fully derivative of the position and orientation of the robot’s body. This means that every movement that the robot’s body is instructed to make can be immediately transposed to a relative displacement of the endpoints; the complete kinematic model can be built based on that assumption.

A gait engine is a subroutine of the locomotion algorithm that handles leg synchronization: in general, any pedal locomotion divides each leg in either a pushing or swinging state in a fixed order in such a way to allow for repetitive, continuous movement. The gait engine is responsible for assigning the swing and push roles as well as the direction and amount of space to cover for each iteration tick. The gait engine employed is not fundamental to describe the desired formulation and will not be discussed as descriptions are already available in the literature (the gait engine employed in this treatment is the one provided by NUKE). Therefore, from the user input comprising the x-speed, y-speed, and z-axis rotation speed, the gait engine provides the movement data that the robot is supposed to follow, and the kinematic problem is to find the related endpoint displacement.

In order to solve the kinematic problem, it is imperative to be able to describe the robot’s position and orientation at each iteration step by taking into consideration all the movement data provided by the gait engine and by direct command of the user (the user is supposed to be able to bypass the gait engine instructions to apply direct control of the robot’s pose at each iteration step).

That is performed by building the $T_{globalbody}$ transformation matrix at each ith iteration step (as $T_{gb,i}$) as shown in (8):

$$T_{gb,i}=T_{tr,i}{Q}_{ter,i}Mo{v}_{i}Rot{Z}_{b,i}Rot{Y}_{i}Rot{X}_i$$

(8)

where in (8),

• $T_{tr,i}$ is the translational transformation matrix holding data about the movement instructions coming from the gait engine. It is built as shown in (9) and reconstructs the robot’s position as if it were just under the influence of the gait engine alone:

  $$T_{tr,i}=T_{tr,i-1}{Q}_{tr,i}=T_{gb,0}·Q_{tr,1}·\dots ·Q_{tr,i}$$

  (9)
  In which $Q_{tr,i}$ is the transformation matrix representing the ith step movement due to the gait engine instructions. It is made of two contributions, as shown in (10):

  $$Q_{tr,i}=\delta T_{mov,i}\delta Rot{Z}_{g,i}$$

  (10)
  In which $\delta T_{mov,i}$ is the component related to the translational movement and $\delta Rot{Z}_{g,i}$ is the one related to the z-axis rotation. Those are defined in (11) and (12), respectively:

  $$\delta T_{mov,i}=\left[\begin{array}{cccc}1& 0& 0& \delta x_{gait,i}\\ 0& 1& 0& \delta y_{gait,i}\\ 0& 0& 1& 0\\ 0& 0& 0& 1\end{array}\right]$$

  (11)

  $$\delta Rot{Z}_{g,i}=\left[\begin{array}{cccc}cos\left(\delta ro{t}_{z_{gait,i}}\right)& -sin\left(\delta ro{t}_{z_{gait,i}}\right)& 0& 0\\ sin\left(\delta ro{t}_{z_{gait,i}}\right)& cos\left(\delta ro{t}_{z_{gait,i}}\right)& 0& 0\\ 0& 0& 1& 0\\ 0& 0& 0& 1\end{array}\right]$$

  (12)

  where in (11) and (12), $\delta x_{gait,i}$, $\delta y_{gait,i}$, and $\delta ro{t}_{z_{gait,i}}$ are the gait engine movement instructions for the $i^{th}$ step x-axis displacement, y-axis displacement, and z-axis rotation, respectively.
• $Mo{v}_i$ is the transformation matrix holding the user-imposed translational movement data of the robot’s body, defined as in (13):

  $$Mo{v}_i=\left[\begin{array}{cccc}1& 0& 0& bodyPo{s}_{x_i}\\ 0& 1& 0& bodyPo{s}_{y_i}\\ 0& 0& 1& bodyPo{s}_{z_i}\\ 0& 0& 0& 1\end{array}\right]$$

  (13)
• $Rot{Z}_{b,i}$, $Rot{Y}_i$, and $Rot{X}_i$ are the transformation matrices holding the user-imposed orientation of the robot’s body, being the z-axis rotational matrix, y-axis rotational matrix, and x-axis rotational matrix, respectively.
• $Q_{ter,i}$ is the terrain-compensated reorientation matrix addressing additional body displacement due to terrain shape. It depends on the position of the robot’s body in the terrain environment. It can either be given by user input or computed in real-time based on the terrain shape in the robot’s surroundings. Our objective is to assemble this matrix automatically by employing a terrain-tuning algorithm that takes as its only input the terrain elevation function $h(x,y)$, which can again either be given as user input (assuming perfect knowledge of the terrain shape) or constructed by an estimation architecture. $Q_{ter,i}$ is an identity matrix for completely flat terrains.

Therefore, the entire movement comprising all contributions that the robot’s body goes through at the ith iteration step is represented by the transformation matrix calculated as in (14):

$$Q_{body,i}=T_{gb,i-1}^{-1}{T}_{gb,i}$$

(14)

Due to friction, the pushing legs endpoints are fixed to the terrain; therefore, their global position should not change between iterations. This means that if the body moves as described by (14), then the relative position of the endpoints should change as (15):

$$\left[\begin{array}{c}{x}_i\\ y_i\\ z_i\\ 1\end{array}\right]=Q_{body,i}^{-1}\left[\begin{array}{c}{x}_{i-1}\\ y_{i-1}\\ z_{i-1}\\ 1\end{array}\right]$$

(15)

This way, it is possible to solve the kinematic problem for the pushing legs endpoints. Note that since (15) is built recursively, it needs starting values. These are the neutral position endpoints, which is why their coordinates are hardcoded into the control software. The swinging legs endpoint positions are defined as (16):

$${\left[\begin{array}{c}{x}_i\\ y_i\\ z_i\\ 1\end{array}\right]}_{gCS}=T_{tr,i}{Q}_{ter,i}Rot{Z}_{g,i}{T}_{mov,i}{\left[\begin{array}{c}{x}_{neu}\\ y_{neu}\\ z_{neu}\\ 1\end{array}\right]}_{bCS}$$

(16)

where $x_{neu}$, $y_{neu}$, and $z_{neu}$ are the endpoint coordinates of the neutral position. The reason why (16) refers to the neutral position endpoint coordinates and addresses $Rot{Z}_{g,i}$ and $T_{mov,i}$ instead of $\delta Rot{Z}_{g,i}$ and $\delta T_{mov,i}$ is because of the core difference between (8) and (14): instead of building the endpoint transformation from the previous endpoint position, the gait engine now needs to displace the leg in such a way that the swinging stride motion is obtained. This means that the movement data coming from $Rot{Z}_{g,i}$ and $T_{mov,i}$ are no longer about increments of movement but effective displacements from the neutral position. The gait engine should return these values when assessing the swinging legs endpoints.

To account for terrain presence and ensure that the leg will always be over the terrain height while swinging, the correction shown in (17) should be applied:

$$z_{i,gCS}=z_{gait,i}+h\left(x_{i,gCS},y_{i,gCS}\right)$$

(17)

where $h(x,y)$ is the elevation function of the terrain.

Once the global coordinates of the swinging legs endpoints are found, the body-centered coordinates are found as in (18):

$${\left[\begin{array}{c}{x}_i\\ y_i\\ z_i\\ 1\end{array}\right]}_{bCS}=T_{gb,i}^{-1}{\left[\begin{array}{c}{x}_i\\ y_i\\ z_i\\ 1\end{array}\right]}_{gCS}$$

(18)

Completing the kinematic problem assessment.

3.2. Terrain Compensation Algorithm

The objective of this section is to develop a way to orientate the body pose of the robot in such a way that while moving the robot freely on the ground, its body becomes ‘isolated’ with respect to the ground itself.

Assuming perfect knowledge of terrain geometry in terms of angular and discontinuity interface position would not be realistic nor aligned with our objective of developing an adaptive algorithm. Our purpose is the design of an algorithm able to deal with any terrain just relying on the elevation function, which could be measured by sensors mounted on the robot itself, but this is not the purpose of this work [16,41].

First of all, it is important to unequivocally define the ‘body isolation’ condition: this can be achieved by defining a set of points in the robot’s body and then considering the height of these points with respect to the ground as a way to evaluate the body’s relative position to the terrain. A possible approach is to ask for those points to maintain a distance from the ground as close as possible to the one defined by ${\mathrm{SP}}_z$ in (1). If these points of interest are correctly chosen in order to represent the vertices of the robot’s body, the entire base should follow the terrain profile and prevent unwanted situations like the ones discussed beforehand.

With the proposed algorithm, the robot’s body will be able to position itself in such a way that it complies with the terrain geometry no matter the harshness.

In the algorithm presented, six points are selected in the locations of the robot’s shoulders, as shown in Figure 5.

The main assumption of the compensation model is that the robot will be able to position itself in the optimal pose by moving from its horizontal pose defined by $T_{tr}$ with three degrees of freedom only: a first displacement in the z-direction followed by a rotation around its body c.s. y-axis and a final relative rotation around its body c.s. x-axis. In transformation matrices, this is described by (19):

$$Q_{ter,i}=D_{ter,i}Rot{Y}_{ter,i}Rot{X}_{ter,i}$$

(19)

where

• $D_{ter,i}$ is the z-axis rigid translation matrix defined as in (20):

  $$Dis{p}_{ter,i}=\left[\begin{array}{cccc}1& 0& 0& 0\\ 0& 1& 0& 0\\ 0& 0& 1& \delta z_{ter,i}\\ 0& 0& 0& 1\end{array}\right]$$

  (20)
• $Rot{Y}_{ter,i}$ and $Rot{X}_{ter,i}$ are the rotation matrices defined as in (21) and (22):

  $$\begin{array}{cc}\hfill Rot{Y}_{ter,i}& =Rot\left({\alpha }_{ter,i},Y\right)\hfill \end{array}$$

  (21)

  $$\begin{array}{cc}\hfill Rot{X}_{ter,i}& =Rot\left({\beta }_{ter,i},X\right)\hfill \end{array}$$

  (22)

  where in (21) and (22), ${\alpha }_{ter,i}$ is the angular rotation around the body c.s. y-axis and ${\beta }_{ter,i}$ is the angular rotation around the body c.s. x-axis.

From the global coordinate system, the joint positions after the terrain reorientation are (23):

$${\left[\begin{array}{c}{x}_{j_{ter,i}}\\ y_{j_{ter,i}}\\ z_{j_{ter,i}}\\ 1\end{array}\right]}_{gCS}=T_{tr,i}Dis{p}_{te{r}_i}Rot{Y}_{te{r}_i}Rot{X}_{te{r}_i}{\left[\begin{array}{c}{x}_j\\ y_j\\ z_j\\ 1\end{array}\right]}_{bCS}$$

(23)

Since we want our points to have relative heights as close to ${\mathrm{SP}}_z$ as possible, we can build an algorithm that minimizes the total relative height quadratic error. It is accomplished by accounting for each point, shown in (24) with reference to (25):

$$\begin{array}{cc}\hfill f& =\sum {\left(z_{j_{ter}}-Z_{terrain}-{\mathrm{SP}}_z\right)}^2=\hfill \\ \hfill & =\sum {ϵ}_j^2\left(a,b,c,d,e\right)=\hfill \\ \hfill & =\sum (a-x_{j}b+z_{j}cd+y_{j}de+\hfill \\ \hfill & -h{\left(x_{j_{ter}},y_{j_{ter}})-{\mathrm{SP}}_z\right)}^2\hfill \end{array}$$

(24)

$$\begin{array}{cc}\hfill & \left\{\begin{array}{c}a=\delta z_{ter,i}\\ b=sin{\alpha }_{ter,i}\\ c=cos{\beta }_{ter,i}\\ d=cos{\alpha }_{ter,i}\\ e=sin{\beta }_{ter,i}\end{array}\right.\hfill \end{array}$$

(25)

The problem is a multivariable optimization problem with equality constraints coming from trigonometric function consistency, solvable by writing the Newton–Euler equations with Lagrangian multipliers [42]. The formulation obtained and reported in Equation (26) comes from adjoining the equality constraints in Equation (25) to the cost function in Equation (24):

$$L=f+\left[\begin{array}{cc}{\lambda }_1& {\lambda }_2\end{array}\right]\left[\begin{array}{c}{c}^2+e^2-1\\ b^2+d^2-1\end{array}\right]$$

(26)

The necessary conditions hold for the minimum [42] as $\nabla L=0$.

The Lagrangian function is differentiable, and its gradient is calculated by taking the partial derivatives of Equation (26).

In order to find the solution to $\nabla L=0$, M-V-O-P numerical methods need to be employed. In this situation, given that the cost function is quadratic, it is possible to effectively employ the steepest descent algorithm to iterate and find the solution very quickly and with a relatively low computational cost.

Having already defined the gradient of the Lagrangian, the steepest descent algorithm is implemented as in (27):

$$X_{it+1}=X_{it}-\nabla L\left(X_{it}\right)·Weight$$

(27)

With the stopping condition being $\left|\right|X_{it}-X_{it-1}\left|\right|\le tol$. In (27), the $Weight$ parameter represents the adjustment index of the increment to the next-iteration solution. Generally, a $Weight$ of $1\times {10}^{-5}$ is good enough to obtain convergent solutions in a few iterations in most general applications.

This method ensures good performances in most terrain situations, only experiencing non-convergence problems in extreme scenarios. As shown in Figure 6, with reasonable weight ($Weight$) and tolerance ($tol$), the solution is generally found very quickly.

The robot’s stability in the current formulation is ensured through NUKE’s original gait engine, which arithmetically enforces the robot COG to always stay within bounds. Indeed, the only gait types accepted by the algorithm are those that allow the hexapod robot to maintain static stability in all intermediate positions during movement, with the “less-redundant” one being the tripod gait, where three legs are moved at each time, but the algorithm always ensures that the support triangle bounds the COG projection.

Since the problem was defined in general terms, the algorithm can run even in situations where rough interfaces are present, moving the robot in such a way as to allow for a smooth transition between angular interfaces and navigation over non-continuous terrains. An important assumption considered in this analysis is the simplification of the terrain behavior: an ideal undamped and rigid terrain is assumed, and the potential slipping of the leg upon exceeding the static friction limit is neglected since a purely geometrical approach is proposed.

In the scenario of a steep ramp given a full horizontal speed input, the robot can smoothly go from being completely horizontal to adapting to the terrain inclination, as shown in Figure 7 and Figure 8.

Since the algorithm runs on the elevation function only, realistic terrains defined through conventional discrete models [43] can be used without particular adjustments.

4. Torque Estimation

4.1. Dynamic Model

Smart servos generally employed in physical hexapods can provide feedback in both position and speed; however, these signals are almost completely insensitive to terrain interaction effects. In particular, they are blind to sliding and instability issues. Moreover, they might not be affected by trips or grip losses. Even in overstepping cases, the robot will rigidly fall while reporting to be working perfectly.

For this reason, to intercept terrain contact, another signal must be taken into account. Torque is a value that is highly dependent on which legs support the body or not, as well as reacting swiftly to terrain interaction. Servomotor torque can, therefore, become our way to make the robot inspect its surroundings, and by compensating unstable-pose scenarios by repositioning the legs correctly, we can ensure robust movement through the entire control operation.

However, to correctly interpret the torque values coming from servos, developing a full dynamic model of the robot’s movement is necessary, as presented in the following section.

The degrees of freedom of the robot’s body are defined as in (28):

$${\mathcal{X}}_b=\left[\begin{array}{c}{x}_b\\ y_b\\ z_b\\ ro{t}_x\\ ro{t}_y\\ ro{t}_z\end{array}\right]$$

(28)

where the DOFs follow the order set in (8).

The degrees of freedom of a single leg are defined as the state vector shown in (29) with consistency with the previous definitions of $\theta$, $\varphi$, and $\psi$:

$${\mathcal{X}}_{a,l}=\left[\begin{array}{c}{\theta }_i\\ {\varphi }_i\\ {\psi }_i\end{array}\right]$$

(29)

The state vector comprising all legs’ degrees of freedom is defined as ${\mathcal{X}}_a$, shown in (30):

$${\mathcal{X}}_a=\left[\begin{array}{c}{\mathcal{X}}_{a,1}\\ ⋮\\ {\mathcal{X}}_{a,6}\end{array}\right]$$

(30)

The main problem with the modeling of the hexapod robot and legged locomotion, in general, is that to use lightweight dynamic algorithms like Newton–Euler equations, it is an absolute necessity to have one and only one grounded joint at all times [44,45,46]. Legged locomotion usually does not fall under these requirements, and multiple ground constraints must be addressed, adding great complexity to the model.

In order to avoid this kind of problem, it is possible to take an alternate route for modeling: instead of considering the robot as positionally constrained at the ground at the pushing legs endpoints, we consider the robot as not having any constraints at all and adjoining the kinematic constraints to the Lagrangian dynamic equations.

Since the ground contact points act as hinges for the robot, the kinematic constraints will be the nullity of these points’ linear velocities.

The coxa, femur, and tibia coordinate systems with reference to Figure 9 are identified with the matrices (31)–(33). Those are used to find the relative positions of either the coxa, femur, and tibia joints or the feet endpoint, e.g., $r_{f-c}$ being the position of the femur joint in the coxa coordinate system:

$$\begin{array}{cc}\hfill & T_{bodycoxa}=\left[\begin{array}{cccc}cos(ϵ+\theta )& -sin(ϵ+\theta )& 0& x_j\\ sin(ϵ+\theta )& cos(ϵ+\theta )& 0& y_j\\ 0& 0& 1& 0\\ 0& 0& 0& 1\end{array}\right]\hfill \end{array}$$

(31)

$$\begin{array}{cc}\hfill & T_{coxafemur}=\left[\begin{array}{cccc}cos\varphi & 0& sin\varphi & l_c\\ 0& 1& 0& 0\\ -sin\varphi & 0& cos\varphi & 0\\ 0& 0& 0& 1\end{array}\right]\hfill \end{array}$$

(32)

$$\begin{array}{cc}\hfill & T_{femurtibia}=\left[\begin{array}{cccc}cos\psi & 0& sin\psi & l_f\\ 0& 1& 0& 0\\ -sin\psi & 0& cos\psi & 0\\ 0& 0& 0& 1\end{array}\right]\hfill \end{array}$$

(33)

By defining $T_{trbody}$ as in (34), the transformation matrix that describes the effects of the body DOF on its pose, the axes of rotation of the coxa, femur, and tibia joints can be found under a fixed coordinate system as shown in (35)–(37), and are those represented in Figure 10:

$$T_{trbody}=MovRotZRotYRotX$$

(34)

$$\begin{array}{cc}\hfill & A_c=T_{trbody}{T}_{bodycoxa}{A}_z\hfill \end{array}$$

(35)

$$\begin{array}{cc}\hfill & A_f=T_{trbody}{T}_{bodyfemur}{A}_y\hfill \end{array}$$

(36)

$$\begin{array}{cc}\hfill & A_t=T_{trbody}{T}_{bodytibia}{A}_y\hfill \end{array}$$

(37)

where $A_z$ is the $[0,0,1,0]$ axis and $A_y$ is the $[0,1,0,0]$ axis.

From this definition, we can define the kinematic constraint for pushing the legs’ grounded endpoints as (38), where the derivation of (39) is trivial, which shows the relation between the velocities of the actuators and the robot’s body DOF:

$$\begin{array}{cc}\hfill & A_{c,l}{\dot{\mathcal{X}}}_b+B_{c,l}{\dot{\mathcal{X}}}_{a,l}=0\hfill \end{array}$$

(38)

$$\begin{array}{cc}\hfill & {\dot{\mathcal{X}}}_{a,l}=-B_{c,l}^{-1}{A}_{c,l}{\dot{\mathcal{X}}}_b\hfill \end{array}$$

(39)

The $B_{c,l}$ and $B_{c,l}$ Jacobian constraint matrices’ definition is reported in (40) and (41):

$$\begin{array}{cc}\hfill & B_{c,l}=\left[\begin{array}{ccc}-{\widehat{r}}_{ft-c}{A}_c& -{\widehat{r}}_{ft-f}{A}_f& -{\widehat{r}}_{ft-t}{A}_t\end{array}\right]\hfill \end{array}$$

(40)

$$\begin{array}{cc}\hfill & A_{c,l}=\left[\begin{array}{cc}\left(RotZRotYRotX\right)& -{\widehat{r}}_{f-b}\left(RotZRotYRotX\right)\end{array}\right]\Psi \hfill \end{array}$$

(41)

In which $\Psi$ is the matrix that transforms the time derivatives of the robot’s body DOF into the robot’s body twist (‘twist’ being the name given by [46] of the kinematic screw, and $\widehat{r}$ is the skew matrix representation of the r position vector. The kinematic screw is the velocity vector field of dimension $6\times 1$ composed of the linear velocities and the angular velocities).

A single constraint equation for all degrees of freedom of the robot requires applying the definitions provided by (42) and (43), which results in the expression (44):

$$\begin{array}{cc}\hfill & A_c=\left[\begin{array}{c}i{p}_1{A}_{c,1}\\ ⋮\\ i{p}_6{A}_{c,6}\end{array}\right]\hfill \end{array}$$

(42)

$$\begin{array}{cc}\hfill & B_c=\left[\begin{array}{ccc}i{p}_1{B}_{c,1}& & \\ & \ddots & \\ & & i{p}_6{B}_{c,6}\end{array}\right]\hfill \end{array}$$

(43)

$$A_c{\dot{\mathcal{X}}}_b+B_c{\dot{\mathcal{X}}}_a=0$$

(44)

where $i{p}_i$ is a boolean value that accounts for whether the ith leg is in a pushing, constrained state (and therefore its endpoint is grounded) or in a swinging state.

Since the kinematic constraint Equation (44) was written with reference to both ${\mathcal{X}}_a$ and ${\mathcal{X}}_b$, the Lagrange equations will consider the full state vector as in (45):

$$\mathcal{X}=\left[\begin{array}{c}\frac{{\mathcal{X}}_a}{{\mathcal{X}}_b}\end{array}\right]$$

(45)

By defining the kinematic constraint equation, the dynamic model is expressed as (46):

$$\tau ={\tau }_a+{\left(-A_c^{+}{B}_c\right)}^T{\tau }_b$$

(46)

where ${\tau }_a$ is the contributions coming from the real actuated joints ${\mathcal{X}}_a$ and ${\tau }_b$ is the ones coming from the body DOF ${\mathcal{X}}_b$. $A_c^{+}$ is the left pseudoinverse of the $A_c$ matrix.

By defining the inertia matrix as in (47) and the potential energies as (48) [46], the two contributions can be calculated as (49) and (50):

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill & M\left(\mathcal{X}\right)=\sum _{l=1}^6\left(J_{c,l}^T{M}_c{J}_{c,l}+J_{f,l}^T{M}_f{J}_{f,l}+J_{t,l}^T{M}_t{J}_{t,l}\right)+\hfill \\ \hfill & +J_b^T{M}_b{J}_b=\left[\begin{array}{c}\frac{M_a\left(\mathcal{X}\right)}{M_b\left(\mathcal{X}\right)}\end{array}\right]\hfill \end{array}\end{array}$$

(47)

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill & U=-\left[\begin{array}{cc}{g}^T& 0\end{array}\right]\sum _{l=1}^6(m_c{T}_{trbody}{T}_{bodycoxa,l}{r}_{g-c}+\hfill \\ \hfill & +m_f{T}_{trbody}{T}_{bodyfemur,l}{r}_{g-f}+\hfill \\ \hfill & +m_t{T}_{trbody}{T}_{bodytibia,l}{r}_{g-t})+\hfill \\ \hfill & -\left[\begin{array}{cc}{g}^T& 0\end{array}\right]m_b{T}_{trbody}{r}_{g-b}\hfill \end{array}\end{array}$$

(48)

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill & {\tau }_a=M_a\ddot{\mathcal{X}}+\left(\left({\mathcal{X}}^T\otimes I_{18}\right){\displaystyle \frac{\partial M_a}{\partial \mathcal{X}}}+\right.\hfill \\ \hfill & \left.-{\displaystyle \frac{1}{2}}\left(I_{18}\otimes {\dot{\mathcal{X}}}^T\right){\displaystyle \frac{\partial M}{\partial {\mathcal{X}}_a}}\right)\dot{\mathcal{X}}+{\left({\displaystyle \frac{\partial U}{\partial {\mathcal{X}}_a}}\right)}^T\hfill \end{array}\end{array}$$

(49)

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill & {\tau }_b=M_b\ddot{\mathcal{X}}+\left(\left({\mathcal{X}}^T\otimes I_6\right){\displaystyle \frac{\partial M_b}{\partial \mathcal{X}}}+\right.\hfill \\ \hfill & \left.-{\displaystyle \frac{1}{2}}\left(I_6\otimes {\dot{\mathcal{X}}}^T\right){\displaystyle \frac{\partial M}{\partial {\mathcal{X}}_b}}\right)\dot{\mathcal{X}}+{\left({\displaystyle \frac{\partial U}{\partial {\mathcal{X}}_b}}\right)}^T\hfill \end{array}\end{array}$$

(50)

In which ⊗ is the Kronecker product following notation by [47]. Note that since ${\mathcal{X}}_a$ is measurable and ${\mathcal{X}}_b$ can be estimated through $Q_{body,i}$ calculated through (14), the full-state-vector knowledge is assumed at all times.

4.2. Dynamic Model Validation

The dynamic model was developed through various simplifying assumptions. Hence, its validity is subordinate to the fact that those assumptions and simplifications are small enough to be neglected from a real application perspective. Following other works that deal with crawler robot physics [48], the dynamic model validation is carried out through a direct comparison of results with a Matlab SimMechanics^TM simulation.

The Matlab SimMechanics^TM simulation employs a physics engine and uses a full 3D model of the hexapod robot, as well as fully simulating friction and terrain physics through the Simscape Multibody Contact Forces Library [49] (the foot–terrain interaction system is shown in Figure 11).

The comparisons shown in Figure 12 show that the dynamic model closely matches the result from the SimMechanics^TM physics engine. While there are differences in the torque spikes coming from the simulated friction model physics, the overall torque behavior perceived by the SimMechanics^TM physics engine closely matches the one generated by our dynamic algorithm. This not only means that our algorithm is indeed accurate enough to provide good results, but the assumptions we made while developing the dynamic model, such as the way we modeled the grounded endpoints through kinematic constraints, mean that the PKM interpretation of the hexapod movement and the simplification of the hexapod feet providing single-point contact between the leg and terrain is small enough not to cause mismodeling errors in the final calculations.

5. Closed-Loop Control

A closed-loop-control approach is essential to obtain stable, robust movement throughout the entire range of movement tasks that the robot will be subjected to. After a few steps, a completely feed-forward approach may lead to positioning errors related mainly to robot–interface mismatching between reality and expected values, which would translate to grip losses and other unwanted behaviors to avoid in the presence of uneven terrain.

The two major situations to avoid are the cases where the feed-forward locomotion-control system expects the terrain to be higher and, therefore, leaves the leg hanging. The case where it expects it to be lower and, therefore, pushes the body back in an overstepping action destabilizes the entire robot pose. These situations are bound to happen due to either terrain mismodeling or desynchronization between the expected behavior from the simulation environment and the actual robot motion, which is mainly due to the increasing drift between the real and expected position of the robot as it accumulates positioning errors due to all non-ideal behaviors and performances coming from its hardware and components. Note how both situations happen in the leg-lowering part of the swing phase only, meaning a feedback control algorithm acting on real ground touching just needs to be called during that movement section.

The feedback control system works by comparing the expected value of the actuators’ torques coming from the dynamic model with the actual sensed torques coming from the sensors system.

By reading the actuator position and speed and estimating the body movement from $Q_{body,i}$, it is possible at each iteration to build the estimated ${\mathcal{X}}_a$ and ${\mathcal{X}}_b$ state vectors, to which the algorithm immediately calculates the ${\tau }_a$ and $ta{u}_b$ components as defined in (49) and (50), with these being the only actual dependencies.

Once these two values are stored in memory, the lowering legs’ sudden terrain touch can be simulated in the dynamic model by simply interacting with the $i{p}_i$ values defined earlier in (42) and (43). The $i{p}_i$ boolean represents the grounded state of the ith leg’s endpoint; therefore, by temporarily setting it to one and building the $A_c$ and $B_c$ constraint matrices, it is possible to obtain the hypothetical terrain-reached torques for all actuators through (46). This is an easy, relatively CPU-light way to obtain full references for the leg–terrain touch situations.

If there is a sensible correspondence between the expected torques and the sensed ones, then the terrain is considered reached for that particular leg, and its movements are stopped. This accounts for the overstepping part of the problem, while it may still be possible for the legs to reach their desired end positions when no terrain has been sensed.

In order to solve the ‘leg-hanging’ problem, it is only necessary to lower the expected altitude of the desired leg endpoint position (in the employed algorithm, the gait altitude instruction is lowered by 1 cm each time), $z_{gait,i}$, and recompute the needed servomotor angles. This can be obtained by lowering the legs until the terrain is touched and the previous condition is met, effectively assuring that the legs reach the ground and stop right before moving to the push phase.

Finally, since the servomotor stopping condition is changed to sensed terrain touch, the lowering leg endpoints will probably differ from the ones expected by the locomotion system instructions. Therefore, the new positions need to be updated by employing forward kinematics tools such as the $T_{bodycoxa}$, $T_{bodyfemur}$, and $T_{bodytibia}$ transformation matrices derived through (31)–(33).

A scheme summarizing the leg-handling system is shown in Figure 13. An implementation example of the closed-loop-control solution is presented in Algorithm 1.

Algorithm 1: Lowering-leg-control algorithm pseudocode.

6. Experimental Results

The developed motion-control architecture was experimentally verified by accomplishing a series of testing scenarios. The experimental tests aim to stress two essential aspects of the architecture presented and highlight the improvements with respect to a stock controller. They also aim to analyze the effect of feed-forward locomotion control and the feedback-stabilization contribution. In particular, the two scenarios reported are as follows:

• Obstacle recognition: Where the robot is fed with flat terrain data and it needs to adapt to the presence of software ‘invisible’ terrain. The task will be considered completed if the robot can remain stable due to overstepping into obstacles and tripping, completing the traversal correctly.
• Ramp climbing: Where the robot is fed with data of the ramp terrain while the body is asked to remain horizontal throughout the full movement. The task will be considered completed if the robot can handle the angular interface, climb the ramp effectively, and maintain the body horizontally at all times. The difficulty comes from the fact that even a tiny deviation in the trajectory direction, which is highly possible since no positional feedback is enforced in the robotic platform, can cause significant errors between the actual and expected position of the terrain.

Moreover, in order to analyze the behavior of the overall architecture further, two additional scenarios were introduced to highlight the system’s behavior. These can be considered as variations of the two previous scenarios and are presented to further demonstrate the system’s ability to adjust the orientation of its base according to the terrain’s slope in the first case and its capability to handle the complete lack of reliable terrain mapping in the second case (simulated by the presence of multiple obstacles).

6.1. Obstacle Recognition

The feedback control algorithm adds to the robot’s walking-motion robustness by allowing it to sense and react to unexpected obstacles in the workspace. This means that when facing a mismodeled obstacle, like a section of the terrain wrongly modeled as flat and instead being at a higher altitude, the feedback logic is expected to compensate for the feed-forward error and update the gait to maintain movement stability.

In order to reproduce this condition, a solid object was placed within the robot’s walking path. The obstacle considered has a parallelepiped shape (a rigid book). In our tests, the obstacle is approached vertically, and so the static coefficient between rubber and cardboard (that could be estimated at approximately [0.5–0.8] [50]) is not considered. Moreover, its surface is approximated to be undamped and rigid. The obstacle and robot setup schematics are shown in Figure 14.

As shown in Figure 15a, while the stock controller puts the robot in an unstable stride, the novel closed-loop solution is indeed able to maintain the body horizontally and, by not overstepping onto the solid object, all legs hold to the ground, assuring equilibrium (Figure 15b). These aspects are further highlighted when a payload is mounted on top of it, showing how the stability of movement transfers to the stability of the robot’s body. The robustness of the walking stride made it possible to completely disregard the presence of the obstacle in the robot’s path.

A comparison of the front right and middle right femur servo angle variation through the entire operation between NUKE and the feedback control logic is shown in Figure 16. It is evident how, thanks to the feedback control algorithm, in the middle of the stride cycle, the legs found the obstacle, which resulted in the respective femur actuator stopping in its tracks.

In Figure 15a, it is also possible to check the ‘blindness’ of the robot while being moved by the stock controller: despite being in an unstable position, the angular feedback of the servomotors still reports no extraordinary values, and therefore the robot still attempts to walk as if no obstacle was in its path in the first place.

6.2. Ramp Climbing

In the ramp-climbing task, the robot is positioned right in front of the angular interface, with the instruction of a forward constant movement. The setup scheme is presented in Figure 17. In order to request the robot’s body to remain horizontal, the $Q_{ter}$ matrix is built via (51) rather than (19):

$$Q_{ter,i}=D_{ter,i}$$

(51)

As shown in Figure 17, the ramp inclination angle considered is small so that the static friction coefficient between rubber and plexiglass (that could be estimated approximately around $\left[0.8\right]$ [50]) is neglected and so that the slipping effect between the leg and terrain is not affecting the results. Moreover, the surface of the ramp is approximated to be undamped and rigid. The most challenging part of the task is the traversal of the interface between the flat plane and the ramp, as desynchronization effects are present the most in that location.

This is visible in Figure 18a, where when the control feedback is absent, the legs are left hanging often, leading to movement unsteadiness and ultimately increased traversal difficulty. By inducing the novel control architecture, as shown in Figure 18b, the robot is instead able to climb the ramp correctly because feedback control allows for correct contact between the legs and terrain and because the control of the body pose introduced in the proposed algorithm allows the robot to maintain a horizontal body pose regardless of the incline angle of the terrain.

6.3. Additional Tests

In order to investigate the performance of the system better, two specific additional tests are reported. The first test is an evolution of the ramp-climbing test previously described and schematized in Figure 17. In this case, an object with predominant vertical development (a paper box) is placed on the robot. Due to its geometry, it represents an unstable equilibrium configuration that can easily fall in case of a robot misstep or an excessive tilting of its base.

The second test is developed to extend further the terrain-mapping error previously presented in the obstacle-recognition scenario. The test was carried out by instructing the robot to move forward, expecting a fully flat terrain but then littering the entire path with unknown and unforeseen obstacles of different sizes, resulting in a completely unknown terrain map. Figure 19 collects some photos representing the robot while correctly completing the mission. In detail, for the first additional scenario, the frames show the horizontal position of the robot’s body and the obstacle in balance before approaching and on the ramp. The frames of the second additional scenario show the robot during its motion on an unknown terrain. It is possible to notice that all legs are properly touching the terrain as expected.

7. Assumptions and Limitations

In the presented study, the terrain was assumed to be rigid and non-deformable. Additionally, we neglected friction effects during walking, thus neglecting potential slippages that may occur. Furthermore, the current architecture lacks a localization and feedback control that considers the robot’s position on the terrain map, resulting in an open-loop trajectory execution. Additionally, the map definition is simplified at this stage, being represented merely as a set of elevations $\left(z\right)$ in the 2D $(x,y)$ plane, treated as known data.

8. Conclusions

This paper presents a simple but effective kinematic model derived from a standard open-source formulation (NUKE), a widely recognized and utilized model in the field of robotics. The original formulation is further improved through the manipulation of hexapod leg endpoints: through the use of transformation and pose matrices, the legs’ position in space and the robot’s pose can be accessed at any time. Furthermore, a comprehensive architecture is developed to handle terrain irregularities. This architecture is designed to adjust the robot’s body pose, ensuring its isolation from rough terrain imperfections without the addition of any sensors to the original hardware configuration. For this purpose, a dynamic but computationally lightweight model is presented with the aim of accurately estimating servomotor torques. Moreover, a terrain-sensing feedback control algorithm is introduced to correct instability situations resulting from measurement and actuation errors. The algorithm guarantees leg–ground reach based on a feedback architecture based on estimated torque (from the model) and the torque provided by servomotors as inputs. The proposed architecture, composed of a terrain-adapting, torque estimation, and terrain-sensing algorithm, was evaluated in terms of applicability and performance through experimental tests conducted on the PhantomX Mark II robotic platform. The experimental results presented confirm the expected behavior of the system in different scenarios of interest, such as ramp climbing and the presence of unknown obstacles on the ground. The proposed control architecture is based on several assumptions (such as the knowledge of the terrain shape by other systems or the assumption that the terrain is undeformable). Relaxing these assumptions could be an interesting research direction for future developments.