Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture

,


Introduction
The control of mobile robots is an intense research field, having produced a substantial volume of research literature in the past three decades.Mobile robots present a challenge in both theoretical control design as well as hardware implementation.From a theoretical point of view, mobile robots exert highly non-linear kinematics and dynamics, non-holonomy and complex operational environment.On the other hand, hardware designs strive for scalability, downsizing, computational power and low cost.The main control problems in robot motion control can be classified in three general cases; stabilization to a point, trajectory tracking and path following.Point stabilization refers to the stabilization of the robot to a specific configuration in its state space (pose).For example, if the robot at t = t 0 is at p 0 =( x 0 , y 0 , θ 0 ), then find a suitable control law that steers it to a goal point p g =(x g , y g , θ g ).Apparently p 0 must be an equilibrium point of the closed loop system, exerting asymptotic stability (although practical stability can also be sought for).In the path following (or path tracking) problem, the robot is presented with a reference path, either feasible or infeasible, and has to follow it by issuing the appropriate control commands.A path is defined as a geometric curve in the robot's application space.The trajectory tracking problem is similar, although there is a notable difference; the trajectory is a path with an associated timing law i.e. the robot has to be on specific points at specific time instances.These three problems present challenges and difficulties exacerbated by the fact that the robot models are highly non-linear and non-holonomic (although robots that lift the non-holonomic rolling constraint do exist and are called omni-directional robots.However the most interesting mobile robots present this constraint).The non-holonomy means that there are constraints in the robot velocities e.g. the non-slipping condition, which forces the robot to move tangentially to its path or equivalently, the robot's heading is always collinear to its velocity vector (this can readily be attested by every driver who expects his car to move at the direction it is heading and not sideways i.e. slip).For a more motivating example of holonomy, consider a prototypical and pedagogical kimenatic model for motion analysis and control; the unicycle robot, described by the equations, This model is linear on the inputs and describes a linear combination of vector fields which evolve on a 3D configuration space M = R 3 × S 1 (a three dimensional manifold).The robot is controlled by two inputs υ and ω, expressing the linear and angular velocities respectively.The generalized velocities live on the manifold's tangent space T q M at each point q, thus the system's equations express the available directions of movement.The non-holonomic no-slipping constraint is expressed by the Pfaffian equation, which can be put into the general form, G(q) q = 0 (3) Here q ∈ M is the state vector and G(q) ∈ R 1×3 is the constraint matrix (although in this case is just a vector).Each row vector (covector) of G lives in the manifold's cotangent space T * q M at q, which is the dual space of T q M. Equation 3 describes restrictions on the available directions of movement.Apparently, since the velocities must satisfy (3), it is evident that they live in the null space of G.One can move from Eq.(3) to Eq.( 1) by solving (3) with respect to the velocities q.Since the system is underdetermined (note that G is a one by three "matrix"), two generalized velocities can vary freely, which are precisely the two inputs of (1).The non-holonomy of the system derives from the fact that Eq.( 2) is not integrable i.e. does not express the total derivative of some function.By the Frobenius theorem, if ∆ is the distribution spanned by the two vector fields of Σ, the system is holonomic if ∆ is involutive under Lie bracketing, a condition that is not satisfied by (1).Due to these challenges, the path following problem has been attacked by several researchers from many angles, ranging from classical control approaches (Altafini, 1999;Kamga & Rachid, 1997;Kanayama & Fahroo, 1997), to nonlinear control methodologies (Altafini, 2002;Egerstedt et al., 1998;Koh & Cho, 1994;Samson, 1995;Wit et al., 2004) to intelligent control strategies (Abdessemed et al., 2004;Antonelli et al., 2007;Baltes & Otte, 1999;Cao & Hall, 1998;Deliparaschos et al., 2007;El Hajjaji & Bentalba, 2003;Lee et al., 2003;Liu & Lewis, 1994;Maalouf et al., 2006;Moustris & Tzafestas, 2005;Rodriguez-Castano et al., 2000;Sanchez et al., 1997;Yang et al., 1998).Of course, boundaries often blend since various approaches are used simultaneously.Fuzzy logic path trackers have been used by several researchers (Abdessemed et al., 2004;Antonelli et al., 2007;Baltes & Otte, 1999;Cao & Hall, 1998;Deliparaschos et al., 2007;El Hajjaji & Bentalba, 2003;Jiangzhou et al., 1999;Lee et al., 2003;Liu & Lewis, 1994;Moustris & Tzafestas, 2011;2005;Ollero et al., 1997;Raimondi & Ciancimino, 2008;Rodriguez-Castano et al., 2000;Sanchez et al., 1997) since fuzzy logic provides a more intuitive way for analysing and formulating the control actions, which bypasses most of the mathematical load needed to tackle such a highly nonlinear control problem.Furthermore, the fuzzy controller, which can be less complex in its implementation, is inherently robust to noise and parameter uncertainties.The implementation of Fuzzy Logic Controllers (FLC) in software suffers from speed limitations due to the sequential program execution and the fact that standard processors do not directly support many fuzzy operations (i.e., minimum or maximum).In an effort to reduce the lack of fuzzy operations several modified architectures of standard processors supporting fuzzy computation exist (Costa et al., 1997;Fortuna et al., 2003;Salapura, 2000).Software solutions running on these devices speed up fuzzy computations by at least one order of magnitude over standard processors, but are still not fast enough for some real-time applications.Thus, a dedicated hardware implementation must be used (Hung, 1995).
Due to the increased number of calculations necessary for the path tracking control, a high performance processing system to efficiently handle the task is required.By using a System-on-a-Chip (SoC) realised on an FPGA device, we utilize the hardware/software re-configurability of the FPGA to satisfy the needs of fuzzy logic path tracking for autonomous robots for high-performance onboard processing and flexible hardware for different tasks.FPGAs provide several advantages over single processor hardware, on the one hand, and Application Specific Integrated Circuits (ASIC) on the other.FPGA chips are field-upgradable and do not require the time and expense involved with ASIC redesign.Being reconfigurable, FPGA chips are able to keep up with future modifications that might be necessary.They offer a simpler design cycle, re-programmability, and have a faster time-to-market since no fabrication (layout, masks, or other manufacturing steps) time is required, when compared to ASICs.The use of FPGAs in robotic applications is noted in (Kongmunvattana & Chongstivatana, 1998;Leong & Tsoi, 2005;Li et al., 2003;Reynolds et al., 2001).A review of the application of FPGA's in robotic systems is provided be Leong and Tsoi in (Leong & Tsoi, 2005).A notable case study is the use of FPGA's in the Mars Pathfinder, Mars Surveyor '98, and Mars Surveyor '01 Lander crafts, analysed in (Reynolds et al., 2001).In this chapter we analyse a SoC implementation for the non-holonomic robot path tracking task using a fuzzy logic controller, along with a non-linear feedback-equivalence transformation which reduces path tracking to straight line tracking.The major components of the SoC are a parametrized Digital Fuzzy Logic Controller (DFLC) soft IP core Deliparaschos et al. (2006) Deliparaschos & Tzafestas (2006), implementing the fuzzy tracking algorithm, and Xilinx's Microblaze soft processor core as the top level flow controller.The system was tied to a differential drive robot and experiments were performed in order to asses the efficacy and performance of the overall control scheme.This was facilitated using an image analysis algorithm, presented in the following sections, which calculated the robot's position from a video stream captured using an overhead camera.The analysis was made off-line.The overall system setup can be seen in Fig 1.

Kinematics & odometry of the Khepera II robot
The mobile robot used in this work, is the Khepera II differential drive robot, described by the equations,

403
Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture Here, x, y are the coordinates of the middle point of the axis, L is the axis length (the distance between the two wheels), r is the wheel radius and u l , u r the angular wheel velocities.A diagram of the model is seen in Fig.
(2).Equations 4 can be transformed to a model more akin to the unicycle by first noting that the linear velocity of a point on the wheel's circumference is v = rω (ω i u i ).It can be easily shown that the linear velocity of the wheel's center equals the velocity of its circumference.Thus, denoting the centres' velocities as v r , v l , then, and substituting them into Eq.4, the system takes the form, 404 Recent Advances in Mobile Robotics www.intechopen.comwe get the familiar unicycle model, i.e.
For the physical interpretation of the inputs u s , u θ , consider that the robot performs a turn of radius R with respect to the axis' middle point (point K), centred at the point O (Fig 3).The point O is called the Instantaneous Centre of Rotation or ICR.If ω is the robot's angular velocity (actually the angular velocity of K), then its linear velocity is v s = ωR.It also holds that, By adding (9) together and solving for the linear velocity v s , we get, Subtracting ( 9) we come up with the robot's angular velocity ω, Observe that v s , v θ are actually u s , u θ , thus the new input variables in Eq.7 are actually the robot's linear and angular velocities.What we have proved so far is that the unicycle (or the Dubins Car, which is the unicycle with a constant speed) is related to the Differential Drive by an input transformation, hence they are equivalent.This means that the Differential Drive can emulate these models.Consequently, we can develop a controller for either system and apply it to the others by using this transformation (this is feasible if the input transformation is actually bijective.If it is not, then the controller can by ported to one direction i.e. from

405
Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.commodel A to model B, and not the other way around).As mentioned earlier, the Dubins Car is a simplified model where the velocity is considered constant.Furthermore, the path following problem involves the tracking of a purely geometric curve, where indeed the velocity is irrelevant.Hence, the model ( 8) can be transformed to a more suitable control form by using the curvature κ u κ .The curvature is related to the angular and linear velocities by the well known formula ω = κv, or, using our nomenclature, Since the linear velocity u s = v is constant, by applying this transformation to the system (8), we get, This model is of control-affine form, with a non-vanishing drift term, where the only input is the curvature u κ .By controlling the curvature in this model, we expect to control the actual system i.e. the Khepera robot, which is a differential drive and has two inputs.Thus, starting with the curvature, in order to calculate the true input vector to the robot, we need a second equation.This is of course the velocity equation u s = v, which is considered known.By combining ( 10), ( 11), ( 12), the wheel velocities are calculated as, Equation 14 produces the linear wheel velocities of the robot, given its linear velocity and curvature.Since the linear velocity is constant, the only input is the curvature which is output by the fuzzy controller implemented on the FPGA.
In order to calculate its position, MATLAB queries the robot about its wheel encoder readings every 12.5 msec.The robot returns the 32bit encoder position, expressed in pulse units, with each unit corresponding to 0.08 mm.Consequently, by multiplying the units with 0.08 we get the total length each wheel has travelled since the beginning of the experiment.Now let S R (t), S L (t) be the travel length of the right and left wheels at time t, and S R (t − 1), S L (t − 1) be the length at t − 1.We assume that in the interval ∆t the robot moves with a constant curvature, and thus traces an arc.This translates to constant wheel velocities (Eq.14).Then, using (11) we have, If the robot's initial heading θ 0 , with respect to the world frame, is known, then at time t it holds that, Using 10, the length travelled by the point K in ∆t is found to be,

406
Recent Advances in Mobile Robotics

www.intechopen.com
To calculate the robot's x, y position, we must solve the kinematics for the interval ∆t, setting the input constant.The solution can be easily shown to be, In the case that the robot moves in a straight line, hence ∆θ = 0, taking the limit of 18 gives the equations, To get the absolute coordinates of the robot at t, Eq.19 must be integrated, leading to the odometric equations, Using the previous formulas (Eq.16 and Eq.20) we have succeeded in reconstructing the robot's state vector, i.e. the states (x, y, θ).Note that time is absent from the odometry equations.This has been chosen deliberately since it reduces the estimation error significantly.
To consider this further, suppose that we get the wheel velocities from the robot and use the odometry equations involving the time ∆t.The use of the velocities in the formulas inserts two types of errors; the first is the estimation of the velocities themselves from the robot.In the time between two queries to the robot, which is 12.5 msec, the velocity cannot be computed with adequate precision; the second error derives from the calculation of the interval ∆t, which is inserted into the equations.This interval is not constant since there is always a small computational overhead in the software in order to setup and issue the command, communication delays etc.Furthermore, the queries to the robot are implemented in MATLAB using a timer object.The timer period however, is not guaranteed and is affected by the processes running on the computer at each instant.Thus, ∆t can vary from its nominal value, something which was also seen in actual experiments and must be minimized.

Strip-Wise Affine Map
The Strip-Wise Affine Map (SWAM) is the first step towards constructing a feedback equivalence relation which transforms the robot's model to a suitable form, under specific requirements.The equivalence relation however, exerts the useful property of form invariance on the mobile robot equations.The SWAM is defined for a robot model and a reference path, being applied to tracking control.To begin with, consider a reference polygonal path in the original physical domain, i.e. the actual domain where the robot dwells.Denote this physical domain as D p (w-plane) and the transformed canonical domain as D c (z-plane).Then, the strip-wise affine map is a homeomorphism Φ : D c → D p that sends the real line of the canonical domain to the reference polygonal path in the physical domain.The SWAM is a piecewise linear homeomorphism between the two spaces (Groff, 2003;Gupta & Wenger, 407 Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.com1997) .It acts by inducing a strip decomposition on the planes and then applying an affine map between them.Note that the map acts on the entire domains, not just on a bounded region.

Fig. 4. Illustration of the Strip-Wise Affine Map
In more rigorous terms, let A = {w 1 , w 2 ,...,w n } , w i ∈ C be a polygonal chain on the complex physical domain.This represents the original reference path.Each vertex w i of the chain is projected to a point a i on the real axis in the canonical domain according to its normalized length, Each interval [a k−1 , a k ] is transformed by a respective transformation f 1 , f 2 ,, f n−1 .Now, consider the following rectangle pulse function on the canonical real axis, The pulse is a complex function of z = x + jy in the canonical domain.Each function f k−1 is multiplied by the corresponding pulse and the products are summed to account for the general transformation that projects the interval [0,1) onto the polygonal chain, Extension to the intervals (-∞,0) and [1,+ ∞) can be performed by appending an edge that begins from infinity ending at w 1 , for the first case, and another edge starting from w n escaping 408 Recent Advances in Mobile Robotics www.intechopen.comto infinity, on the second case.The edges have a direction of θ −∞ and θ +∞ respectively.The formulas that account for these branches are given by: Here ψ 0 is an open-left pulse with a single falling edge at x=a 1 , and ψ n is the open-right pulse with a single rising edge at x=a n .Combining the above and using the conventions the point at infinity corresponding to a 0 , w n+1 the point at infinity corresponding to a n+1 , θ 0 = arg(w 1 − w 0 )=θ −∞ , θ n = arg(w n+1 − w n )=θ +∞ , the extended transformation takes the following form, where the functions f −∞ , f +∞ , correspond to k=0 and k=n respectively.In order to extend this transformation to the entire complex plane, let z = x + jy be a complex variable in the canonical domain and consider the mapping, where θ s is the shifting angle in [-π/2, π/2].The complex variable w = u + jv in the physical domain, is identified with the transformation Φ(z), i.e. w = u + jv = Φ(z).This transformation is the direct strip-wise affine map and produces a linear displacement of the polygon along the direction θ s .Each edge of the polygon produces an affine transformation that applies only in the "strip" that the edge sweeps as it is being translated.Thus, the transformation Φ(z) can be described as a "strip-wise affine" transformation.The invertibility of the map depends firstly on the geometry of the chain and secondly on the shifting angle.It can be shown (Moustris & Tzafestas, 2008) that necessary and sufficient conditions for the mapping to be invertible are that the chain must be a strictly monotone polygonal chain (Preparata & Supowit, 1981) and the shifting angle must not coincide with the angle of any of the chain's edges i.e. the chain must not be shifted along one of its edges.The inverse strip-wise affine map can be expressed in matrix form by treating Φ(z) as an R 2 to R 2 mapping since it cannot be solved analytically with respect to z.The inverse mapping equations can be calculated as, where Besides Eq.28, one also needs to know the activated pulse since the rectangle pulses are functions of the variable x, and thus (28) does not provide a complete solution to the inversion problem.If this information is provided, the sums in Eq.28 degenerate and the equation provides the inverse system.The activated pulse can be calculated algorithmically by doing

409
Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.coma point-in-strip test.Consider an axis orthogonal to the direction θ s such that the projection of w 1 corresponds to 0. Furthermore let the projections of each w i onto that axis be denoted as b i , and the projection of the current mapping point denoted as b c .The projections of w i apparently partition the axis into consecutive line segments [b i b i+1 ] which are into one-to-one correspondence with the edges of the polygonal chain.Then, in order to find the current pulse one needs to find the segment into which the point b c resides.This can be performed optimally by a binary search algorithm in O(logn).
Since the SWAM transforms the robot's application space, it also affects its model's equations.Denoting all the state variables in the physical and canonical domains with a subscript of p and c respectively, then the u-v plane (physical domain) is mapped to the x-y plane (canonical domain), i.e. the state vector q p =[ x p , y p , θ p ] T is transformed to q ′ p =[ x c , y c , θ p ] T .The homeomorphism Φ defines an equivalence relation between the two states.Notice that the state θ p remains unaffected.By introducing a new extended homeomorphism Ψ that also maps the heading angle θ p , one can send the canonical state-space to the physical state-space, i.e. q p = Ψ(q c ).This transformation acts on all state variables and the new system state is and the new system is, Σ : J is the Jacobian of Φ and γ = 1 + sin 2θ c ∑ n κ=0 cos(θ s − θ κ )ψ κ .The input κ p of the system remains unaffected.However, since it expresses the curvature of the physical system, it can also be transformed under Ψ.Thus by including the transformation of the input and extending the homeomorphism Ψ to Ψ =(Ψ, Ω) , where is the input map that sends the controls from the canonical input space to the controls in the physical input space, one gets the new extended system, The systems Σ p and Σ c are feedback-equivalent (Gardner & Shadwick, 1987;1990) since they are related by a state and input transformation.The input transformation is actually a feedback transformation of Σ c that feeds the states q c back to the input.A more careful look at Eq.( 32) shows that it expresses the Dubins Car in the canonical domain, thus Ψ presents a kind of form invariance on the model.

410
Recent Advances in Mobile Robotics www.intechopen.comNow, let p re f be a reference path in the physical domain and let u c (q c , I c , t) be a straight line tracking controller for Σ c , where I c denotes the line segment y c = {0/x c ∈ [0, 1]} of the C-plane, i.e. the reference path in the canonical domain.This controller is transformed to a path tracking controller for Σ p under the equation, However, since Σ c is the Dubins Car in the canonical domain, the straight line tracking controller u c (q c , I c , t) for Σ c is actually a straight line tracker for the Dubins Car, and in order to build a path tracker for the Dubins Car, one has but to build a straight line tracker and use Eq.( 33) to promote it to a path tracker for strictly monotone polygonal chains.Furthermore, one could also use existing path trackers for the Dubins Car to track the straight line in the canonical domain.In this case, these controllers can be simplified since in general, straight line tracking is simpler than path tracking.

Fuzzy Logic Controller
The controller used in this work for the path following task, is based on a Fuzzy Logic Controller (FLC) developed by the authors, which has been deployed in previous experiments.The original Fuzzy Logic tracker is described in (Moustris & Tzafestas, 2005), and further modified in (Deliparaschos et al., 2007) in order to be implemented on a FPGA.Specifically the tracker is a zero-order Takagi-Sugeno FLC with the two inputs partitioned in nine triangular membership functions each, while the output is partitioned in five singletons (Fig. 5).

Fig. 5. Input and output membership functions of the fuzzy controller
The FL tracker uses two angles as inputs, and outputs the control input u κ .It is assumed that the path is provided as a sequence of points on R 2 .The fuzzy rule base consists of 81 rules, which are presented in In each control loop the closest path point is picked up and the two input angles are calculated.These angles are the angle φ 1 of the closest point with respect to the current robot heading and the direction φ 2 of the tangent of the path at that point, as depicted in Fig. 6a.Using the SWAM, we can move the tracking task to the canonical domain where the path is a straight line.In this case, the oriented straight line splits the plane into two half-planes, which present two general cases for the placement of the robot.Due to the symmetry of the cases only one will be analyzed.Consider that the robot resides in the positive half-plane (Fig. 6b) and that the distance from the closest path point P is D. Furthermore, one can consider that the robot tracks not the closest point P but the one found distance S ahead.The "sightline" of the robot to that point forms an angle φ with the path.In this situation, by varying the angle φ 2 one can discern four cases for the relation between the angles φ, φ 1 and φ 2 with the three of them being the same, namely, When the robot resides in the positive half-plane, the angle φ is also positive.On the contrary, when it is in the negative half-plane, the angle changes sign although Eqs.(34) remain the same.With respect to the point being tracked, we discern two cases; either fixing the sightline, i.e. fixing the angle φ, or fixing the look-ahead distance S, i.e. tracking the point that is distance

412
Recent Advances in Mobile Robotics www.intechopen.comS ahead of the one nearest to the robot (point P).Of course, the nearest point P can be easily found since its coordinates are (x c ,0), where x c is the x-axis coordinate of the robot in the canonical space.In the case of a constant S, the angle φ varies from [−π/2, π/2] and the tuple (φ 1 , φ 2 ) is constrained in a strip.This can also lead to a rule reduction in the FLC rule base since some rules are never activated ( (Moustris & Tzafestas, 2011)).For the control of the robot, the FLC and the SWAM were calculated on-line using a dedicated FPGA SoC, as described in the next section.

DFLC & SoC architecture
This section discusses the System on Chip (SoC) implemented on an FPGA chip for the robot path tracking task using fuzzy logic.The SoC design was implemented on the Spartan-3 MB development kit (DS-KIT-3SMB1500) by Digilent Inc.The Spartan-3 MB system board utilizes the 1.5 million-gate Xilinx Spartan-3 device (XC3S1500-4FG676) in the 676-pin fine-grid array package.A high level and a detailed architecture view of the SoC is shown in Fig. 7 and 8 respectively.In our application the DFLC facilitates scaling and can be configured for different number of inputs and outputs, number of triangular or trapezoidal fuzzy sets per input, number of singletons per output, antecedent method (t-norm, s-norm), divider type, and number of pipeline registers for the various components in the model.This parametrization enabled the creation of a generic DFLC soft IP core that was used to produce a fuzzy controller of different specifications without the need of redesigning the IP from the beginning.The fuzzy logic controller architecture assumes overlap of two fuzzy sets among adjoining fuzzy sets, and requires 2 n (n is the number of inputs) clock cycles at the core frequency speed in order to sample the input data (input sample rate of 78.2960ns), since it processes one active rule per clock cycle.In its present form the SoC design achieves a core frequency speed of 51.1 MHz.
To achieve this timing result, the latency of the chip architecture involves 9 pipeline stages each one requiring 19.574ns.The featured DFLC IP is based on a simple algorithm similar to the zero-order Takagi-Sugeno inference scheme and the weighted average defuzzification method.By using the chosen parameters of Table 2, it employs two 12-bit inputs and one 12-bit output, 9 triangular membership functions (MFs) per input and 5 singleton MFs at the output with 8-bit and 12-bit degree of truth resolution respectively.The FPGA SoC implements the autonomous control logic of the Kephera II robot.It receives odometry information from the robot and issues steering commands output by the FL tracker.
The encoding and decoding of the information packets (i.e., encoding of steering control into data frames) is handled by the MATLAB application.Therefore the MATLAB application implements the actual framer/deframer for the I/O communication with the Kephera robot and downloads the tracking path to the SoC.The top-level program that supervises these tasks, treats synchronization and timing requirements, is written in C and executes in the Microblaze soft processor core.The SWAM algorithm is also implemented on the FPGA, in order to reduce the computation time.
The MATLAB application displays information about the robot's pose and speed, as well as some other data used for the path tracking control.It also calculates the robot's position relative to the world and the local coordinate frames.Another important function of the MATLAB application is to provide a path for the robot to track.with the path tracking task and not path planning.To compensate for this, the path is drawn in MATLAB, encoded properly and downloaded to the SoC.Then, the SoC begins the tracking control.
The Microblaze soft processor core is licensed as part of the Xilinx Embedded Development Kit (EDK) and is a soft core, meaning that it is implemented using general logic primitives rather than a hard dedicated block in the FPGA.The Microblaze is based on a RISC architecture which is very similar to the DLX architecture described in (Patterson & Hennessy, 1997) (Sailer et al., 1996).It features a 3-stage pipeline with most instruction completing in a single cycle.Both the instruction and data words are 32 bits.The core alone can obtain a speed of up to 100MHz on the Spartan 3 FPGA family.The Microblaze processor can connect to the OPB bus for access to a wide range of different modules, it can communicate via the LMB bus for a fast access to local memory, normally block RAM (BRAM) inside the FPGA.Moreover, the Fast Simplex Link (FSL) offers the ability to connect user soft core IP's acting as co-processors to accelerate time critical algorithms.The FSL channels are dedicated unidirectional point-to-point data streaming interfaces.Each FSL channel provides a low latency interface to the processor pipeline allowing extending the processor's execution unit with custom soft core co-processors.In this work the DFLP IP core is playing the role of such

416
Recent Advances in Mobile Robotics www.intechopen.comsuch as a data control flow description.This description which serves as a unified system representation allows to perform HW/SW functional partitioning.After the completion of the partitioning, the HW and SW blocks are synthesized and evaluation is then performed.If the evaluation does not meet the required objectives, another HW/SW partition is generated and evaluated (Rozenblit & Buchenrieder, 1996) (Kumar, 1995).
A general HW/SW co-design schema followed in this SoC implementation is illustrated in Fig. 10).

Fig. 10. HW/SW Co-design Flow
The DFLC core implementation follows a sequential design manner (see Fig. 11) (Navabi, 1998).The starting point of the design process was the functional modelling of the fuzzy controller in a high level description (i.e., MATLAB/Simulink).This serves a two purpose role, first to evaluate the model and second to generate a set of test vectors for RTL and timing verification.The model was coded in register transfer level (RTL) with the use of hardware description language VHDL.Extensive use of VHDL generic and generate statements was used through out the coding of the different blocks, in order to achieve a parameterized DFLC

418
Recent Advances in Mobile Robotics www.intechopen.comcore.The DFLC core is scalable in terms of the number of inputs/bus resolution, number of input/output fuzzy sets per input and membership resolution.More specifically A VHDL package stores the above generic parameters together with the number of necessary pipeline stages for each block.An RTL simulation was performed to ensure the correct functionality of the fuzzy controller.The DFLC core was independently synthesized with Synopsys Synplify logic synthesis tool (as it produced better synthesis results and meet timing constraints), whereas the rest of the SoC cores were synthesised with Xilinx synthesis tool XST.The Xilinx EDK studio was used for the integration flow of different SoC cores (i.e., DFLC, Microblaze, etc) and Xilinx ISE tool for the placement and routing of the SoC on the FPGA.More analytically, the place and route tool accepts the input netlist file (.edf), previously created by the synthesis tool and goes through the following steps.First, the translation program translates the input netlist together with the design constraints to a database file.After the translation program has run successfully, the logical design is mapped to the Xilinx FPGA device.Lastly, the the mapped design is placed and routed onto the chosen FPGA family and a device configuration file (bitstream) is created.Xilinx's SDK used for C programming and debugging the SoC's Microblaze soft processor.RTL and timing simulation to verify the correct functionality was handled with the use of Mentor's Modelsim simulator.

FPGA design and performance evaluation
The Component Pipeline Registers (CPR) blocks in Fig. 8 indicate the number of pipeline stages for each component; the Path Synchronization Registers (PSR) blocks point to registers used for synchronizing the data paths, while the "U" blocks represent the different components of the DFLC Deliparaschos & Tzafestas (2006).The U_fpga_fc component is embedded in the flc_ip top structural entity wrapper which is compliant with the FSL standard and provides all the necessary peripheral logic to the DFLC soft IP core in order to send/receive data to/from the FSL bus.The flc_ip wrapper architecture is shown in Fig. 8 while the chosen (generic) parameters (VHDL package definition file) for the parameterized DFLC IP (U_fpga_fc) and its characteristics are summarized in Table 2 and Table 3 respectively.The U_fpga_fc alone was synthesized using Synplify Pro synthesizer tool, while the rest of the design components were synthesized with Xilinx Synthesis Tool (XST) through the EDK Platform Studio.The produced .edffile for the U_fpga_fc is been seeing by the flc_ip wrapper as a blackbox during the XST flow.The placement and routing of the SoC design into the FPGA was done through the EDK by calling the Xilinx ISE tool.
According to the device utilization report from the place and route tool (see

Experimental results
The experiments consist of tracking predefined paths and analysing the displacement error.The paths are drawn by hand in the MATLAB application and downloaded to the FPGA.Then the control algorithm running on the board, calculates the steering command (curvature), relays it to MATLAB, which in turn passes it to the robot.Conversely, the MATLAB application receives odometric data from the robot which are then relayed to the FPGA.Essentially, the MATLAB application acts as an intermediary between the board and the robot, transforming commands and data to a suitable form for each party.Note also that the actual odometry is being performed by MATLAB (estimation of the robot's pose (x, y, θ) using the data from the robot's encoders).A key detail in the above process is that odometry provides an estimation of the actual pose.Thus in order to analyse the efficacy of the tracking scheme, we need to know the actual pose of the robot.Position detection of the robot is achieved using a camera hanging above the robot's activity terrain and utilizing a video tracking algorithm which extracts the robot's trajectory in post-processing.This algorithm tracks a red LED placed at the center of the robot.The video tracking algorithm uses the high contrast of the LED with its surrounding space.Specifically, each video frame is transformed from the RGB color space to the generalized rgb    As one can see, the performance of the tracking scheme is satisfactory maintaining the minimum distance to the reference path at about 50mm in the worst case.However, by taking a closer look at Figures 13 and 14, it is clear that the performance degradation is attributed not to the algorithm per se but to the odometry.The error accumulation of odometric data forces the robot to diverge from the actual path.But the actual odometry solution is very close to the reference path, meaning that based solely on odometry (as is the case in these experiments), the tracker maintains the robot very close to the reference path (the minimum distance is below 10mm in both cases).This implies that if a better localization technique is used, our tracking scheme would perform with more accuracy.

Conclusions
In this chapter we have analysed and demonstrated the applicability of the strip-wise affine transform in the path tracking task for mobile robots.The transformation was translated to hardware and implemented into an FPGA chip with the use of VHDL and advanced EDA software.The scalability of the fuzzy controller core allowed easy parameter adaptation of the theoretic fuzzy tracker model.The experiments show that the tracking scheme performs satisfactory but is degraded by the accumulation of errors of the odometry used in estimating the robots position.

Fig. 2 .
Fig. 2. Depiction of the generalized coordinated for the Differential Drive model If we further apply a new input transformation,

Fig. 3 .
Fig. 3. Depiction of the velocities of the Differential Drive model i= 1, 2,3, ..., n (21) where S k = |w k − w k−1 | , S = ∑ n k=1 S k and S 1 = 0.The polygon edge from w k−1 to w k is linearly projected onto [a k−1 , a k ].The transformation of [a k−1 , a k ] onto its respective polygon edge is done using the function

Fig. 6 .
Fig. 6.Illustration of the controller inputs for path tracking in the general case (a) and in the straight line case (b).

Fig. 7 .
Fig. 7. Overview of the SoC's hardware architecture A design on an FPGA could be thought as a "hard" implementation of program execution.The Processor based systems often involve several layers of abstraction to help schedule tasks and share resources among multiple processes.The driver layer controls hardware resources and the operating system manages memory and processor bandwidth.Any given processor core can execute only one instruction at a time, and processor based systems are

421Feedback
Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.com

Fig. 13 .
Fig. 13.(UP) The odometry (blue), camera (red) and reference (dashed black) paths for the first experiment.(DOWN) Minimum distance of the odometry and camera paths to the reference path versus path length experiment.

Fig. 14 .
Fig. 14. (UP) The odometry (blue), camera (red) and reference (dashed black) paths for the second experiment.(DOWN) Minimum distance of the odometry and camera paths to the reference path versus path length.

423Feedback
Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.com

pbig pmid ps zero ns nmid nbig nvb p180 pb
pb pb pm ze nm nb nb pb p135 pb pb pb pb pm nm nb Pb pb p90 pb pb pb pm pm pm pb pb Pb p45 pb pb pb pm pm ze nb pb pb z pb pb Pb pm ze nm nb nb nb n45 nb nb pb ze nm nb nb nb nb n90 nb nb nb nm nm nb nb nb nb n135 nb nb pb pm nm nb nb nb nb n180 pb pb pb pm zero nm nb nb pb Table 1.The implication operator is the min operator.411 Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.compvb

Table 1 .
FLC Rule Base

Table 2 .
DFLC soft IP core chosen parameters The current work deals only 415 Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.com

Table 4
419 Feedback Equivalence and Control of Mobile Robots Through a Scalable FPGA Architecture www.intechopen.comFig.11.HW/SW Hardware design flow 420 Recent Advances in Mobile Robotics www.intechopen.com

Table 4 .
SoC design summary