Parallelized Collision Avoidance Architectures for

Parallelized Collision Avoidance Architectures for Multiple Robots with Field Programmable Gate Array Roopak Dubey *,a, Neeraj Pradhan *,a, K. Madhava Krishna a and Shubhajit Roy Chowdhury 

Abstract— This paper portrays the specific advantages of developing a Field Programmable Gate Array (FPGA) based robotic system. This is showcased through a multi-robot collision avoidance based on Acceleration Velocity Obstacle (AVO). FPGA offers highly parallel hardware architectures realized as gate level implementations that are not possible on conventional high end processors or other embedded controllers. In this paper we propose a highly parallel Globally Asynchronous Locally S ynchronous (GALS ) architecture for the multi-robot collision avoidance problem. We show computation time significantly reduces on a slower 50 MHz RIS C processor running on Xilinx S partan 3E FPGA when compared with a 1.3 GHz Intel Atom processor used in cell phones. S ubstantial power savings are also reported. Implementation of this architecture on a distributed set of robots each controlled by an onboard Xilinx S partan 3E-500 FG320 FPGA further confirms the efficacy of the architecture as well as fidelity of FPGA as a popular choice for control of robotic systems. Keywords – Mobile Robotics, Collision Avoidance, FPGA, Robotics System Design

I. INT RODUCT ION Field Programmable Gate Array (FPGA) is gaining popularity in robotics recently and it can be seen through FPGA implementations of image processing descriptors [1] [2]. The main advantages of using FPGA are attributed to qualities like small size, ability to reconfigure both offline and online, low power dissipation, low cost and high speed. Small sized robots with constrained resources are the need of the day and hence algorithms are needed, which can run on systems with lesser memory and size footprint. A base station PC has advantages of accuracy and speed but is limited by the wireless range to the robot and hence restricts its operating area. A laptop cannot be mounted on very small robots and can be expensive too. A cell phone processor, which can do such amount of processing is expensive and increases the cost of robot. Moreover a full-fledged operating system is to be installed to control it, which in turn increases memory requirement. A micro- controller does not provide for accuracy and speed, whereas in principle an FPGA has advantages of all. Moreover all these processing units have Complex Instruction Set Computing (CISC) or Reduced Instruction Set Computing (RISC) architecture and there is an extensive instruction set. The operations are based on Fetch-Decode-Execute cycle and hence largely sequential in nature while on FPGA fully parallel architectures can be designed and executed. All the processing units mentioned *Equal Contribution. a Robotics Research Centre, IIIT -Hyderabad, India (e-mail: [email protected]; [email protected]; [email protected]). b Centre of VLSI and Embedded Systems T echnology, IIIT -Hyderabad, India (email: [email protected])

b

above follow Arithmetic Logic Unit (ALU) based architecture for arithmetic and logical operations which involve a lot of instructions and hence clock cycles [3]. FPGA offers to develop gate level implementations of arithmetic circuits and hence a significant improvement in operating speed is inevitable. We show that with FPGA as the processing unit, the execution time of the algorithm, the size and cost of the robot can be reduced.

Figure 1(a). T he Robot

Figure 1(b). Nexys-2 Board

The paper focuses on the design of a FPGA based distributed multi-robot system with the main processing unit being an on-board FPGA. Each robot of this system is designed to do a processing of its own and communicate its results to the other robots in the system. The robots convey their results and other data to other robots via Zigbee network. The capability of FPGA to realize highly parallel architectures is achieved by designing a parallel Globally Asynchronous-Locally Synchronous architecture. In this paper the performance of FPGA robotic system is evaluated and verified by executing reciprocal dynamic obstacle avoidance algorithm for multi-robots using acceleration Velocity Obstacles [4]. Clear advantages in terms of response time and power dissipation over processor based system are highlighted. A real implementation has been done using a distributed set of robots with onboard Xilinx Spartan 3E-500 FG320 FPGA and comparison is shown between performances of the proposed FPGA based system and a system based on widely used general purpose processor. Obstacle avoidance is one of the most basic problems in mobile robotics. There are environments where there are moving objects as well as other robots in the vicinity of the robot under consideration. In those cases static obstacle avoidance [5] [6] [7] cannot solve the problem. In many practical situations robots need to deal with other similar agents and dynamic objects. An algorithm which takes the dynamic nature of objects and other robots under consideration is termed as Dynamic Obstacle Avoidance algorithm [8]. There are again numerous approaches for Dynamic Obstacle Avoidance. Velocity Obstacle (VO) approach is one of the common approaches used for collision avoidance in dynamic environment [9]. When the acceleration constraints are considered in the VO it is called Acceleration Velocity Obstacle (AVO) [10]. When robots share the responsibility of Avoidance among themselves equally then it is termed as Reciprocal Collision Avoidance (RCA) [4].

⃗

⃗ ⃗

⃗

The main contribution of this effort is its portrayal of how highly parallel architectures at gate level can be designed on FPGA. This results in much lower computational time despite significantly lower FPGA processor speed. That the same can be achieved with much lower power dissipation is an added advantage. The paper is organized as follows: - Section II contains discussion on the Reciprocal Collision Avoidance using Acceleration Velocity Obstacles. In section III hardware architecture for the algorithm is discussed in brief. Section IV covers physical design of robot along-with details about communication among robots and control. Section V shows the results of comparison between performances. Section VI concludes the paper.

All velocities of the set are not achievable by robot due to acceleration constraints. So there is a need to take care of these constraints too. A velocity is chosen which is achievable by robot. So this reduces the set to a smaller set [9]. Equations at (2a) and (2b) are the update equations. An implementation of this algorithm has been developed on FPGA.

II. VELOCIT Y OBST ACLE BASED COLLISION A VOIDANCE

III. FPGA A RCHIT ECT URE FOR COLLISION A VOIDANCE

Collision avoidance is one of the fundamental problems in mobile robotics. Numerous algorithms exist, which avoid collision in various types of environment. Velocity Obstacle approach is one of the algorithms , which is very efficient in the dynamic environments with multiple robots and moving objects [9]. In this algorithm the current velocities and position of various objects in the space is used along with constraints of the robot to find the set of velocities , which can avoid the obstacles as well as satisfy the constraints [9] [10]. The set of velocities other than the aforementioned velocities is known as the Velocity Obstacle [9]. This set of velocities forms a collision cone [9] [10] [4]. Figure 2 shows a collision cone (C1/2 ) when there is one robot and one dynamic obstacle. R is combined radius of Robot and the obstacle, d is the distance at which robot will cross the obstacle, (x1 ,y1 ) and (x2 ,y2 ) are positions of Robot and Obstacle respectively, r is distance between centers of robot and obstacle and V is relative velocity of robot with respect to obstacle. Any velocity outside this cone is the velocity which robot can take to avoid obstacles successfully [9] [10] [4].

FPGA based implementation of multi-robot reciprocal collision avoidance using Acceleration Velocity Obstacle is implemented using a Globally Asynchronous Locally Synchronous (GALS) architecture implemented as a hybrid parallel-pipelined design. In GALS architecture, intrasubsystem interactions happen in synchronous manner while inter-subsystem interactions are asynchronous in nature. The architecture shown in Figure 3 illustrates the functioning of GALS system, which performs operations faster than the conventional synchronous system. This is because unlike conventional synchronous system, here sub-systems are not synchronized to the clock edge and provides output without waiting for clock edge [12]. In the architecture shown in Figure 3, each sub-system operates independently on its own clock signal and the hand-shaking signals (signal edge) are used to signal a sub-system when its output is needed in other sub-system or when a particular sub-system is ready to take input.

(x 2 , y 2 ) R

C1/2

V (x 1 , y 1 ) Figure 2. Collision Cone

Equation (1) [11] is the governing equation of the collision cone. The current work aims to find the velocities which satisfy these equations. In these equations , robots other than one which is controlled are considered as passive. All the velocities satisfying this equation are the avoidance velocities. Finally the velocities and position of the robot using the velocities from the set is updated. ( ⃗ ⃗⃗⃗) | ⃗⃗⃗|

(1)

Here, ⃗ is the relative position and ⃗⃗ is the relative velocity of the robot 1 w.r.t robot 2 respectively.

⃗

(2a) ⃗

(2b)

Where, ⃗ ⃗

CK1

CK3

d

r

| ⃗|

⃗

⃗

̂ ̂

̂

̂

(2c) (2d) (2e)

̂ ̂

Sub-System-1

Sub-System-2

Sub-System-3

Sub-System-4

Figure 3. System Architecture

CK2

CK4

The overall proposed architecture is shown in Figure 4. The overall system comprises of four such subsystems. The sub-systems work asynchronously with each other using the hand-shaking signals. The main advantage of system being asynchronous is the speed-up obtained in the overall functioning as asynchronous systems are faster than the synchronous systems [13]. Moreover the clock remains local and hence power dissipation due to continuous transition of the clock signal is reduced. The system is designed to work in a hybrid parallelpipelined fashion as shown in Figure 6 with the intent of operating the system at a faster rate than the conventio nal state machine based system. In the architecture, instead of conventional state machine for sequential processing, control signals are used to signal only those components which are required. The sequence of control signals is controlled by a counter, which acts as an

input to the decoder whose outputs are control signals. The combinational logic of these control signals controlled by the main control unit is fed to the hand shaking signals of these sub-systems. These control signals will tell which of the four sub-systems will be active with the help of the hand shaking signals of these sub-systems. The main control unit also determines when input is to be given and when output is to be read from the sub-system. Hence there is no global clock controlling the operations and hence overall system is a GALS system, which reduces the power dissipation of system substantially and a low power high speed system is realized. Input and output registers are used to hold the inputs and output signals respectively till the corresponding request is made from other sub-systems using the handshaking signals.

To ensure the parallelization of the operations, we used a hierarchical model for implementing the algorithm as explained in [14]. As clear from the algorithm in Section II, there are two main parts of the algorithm viz. updating the velocity and position (Pos_Vel_Update) of the robots using (2a) and (2b) and checking for collision (Coll_detect) using (1). The third sub-system velocity selector module (Cal_Index) is used to select one velocity out of an array of velocities using the “to goal” strategy i.e. the robot will always try to move towards the goal [9]. The required direction is determined using target location and present location of robot. Components of velocities are selected to get the resultant in that direction. Once the components of velocity are obtained the last sub-system, acceleration check module (Cal_acc), checks whether the selected velocity is achievable within acceleration constraints or not. If not, then velocity selector module is signaled to select some other velocity: if yes, then the selected velocity is sent to upd ate module. IV. OMNI -DRIVE ROBOT DESIGN WIT H W IRELESS COMMUNICAT ION The robots are designed so that they are capable of an omni-directional movement and able to communicate to each other using a wireless channel. The omni-directionality is obtained using special kind of wheel design. The wireless communication is obtained using IEEE 802.15.4 Zigbee protocol [16]. The motor is controlled using a PID Control. These are discussed in sub-sections below. A. Robot with omni-drive

Figure 4. Overall Architecture

These sub-systems are the sub-systems, which are controlled by the main control unit. Each of the sub-system has a control unit of its own as shown in Figure 5. The main control unit shown in Figure 4 controls the control unit of other sub-systems in an asynchronous manner. Component-1 DECODER

Control Unit

Component-2

The robots are shown in Figure 1(a) and Figure 7. The design of wheel is shown in Figure 8. As it is clear from the figure the wheel have small rollers on its edge which avoid the slipping of robot when it is moving in orthogonal direction with respect to the wheel. There are 4 wheels on the robot at 90 degrees from each other. Using such a configuration we can give robot horizontal and vertical components of velocity as an instruction. As shown in section III the hardware implementation of the algorithm gives horizontal and vertical components of velocity as output . Hence we can directly integrate algorithm to command the robot velocities.

Component-3

Counter Control Signals CLK

Handshake Signals to and fro other sub-systems Figure 5. Sub-system Architecture

Data_1

Data_2

pos_vel_update_1 Data_1_new

pos_vel_update_2 Data_2_new

Coll_detect (1,2) T rial_1_2

Data_n pos_vel_update_n Data_n_new Coll_detect (1,n) T rial_1_n

Or gate array T rial_final Figure 6. An Example system designed using hybrid parallel-pipelined architecture

Figure 7. T he Robots

Figure 8. Wheel Design

The robot has 3 levels. The base is fitted with the wheels on all fours sides. A lead acid battery of 13V is also fitted on the base. This battery provides power to all other components of robot. The middle level is Nexys 2 development board with Xilinx Spartan 3 FPGA on it. The top level has interfacing circuit and XBee module fitted on it. The interfacing circuit is connected to FPGA using the Pmod connectors on FPGA. The motor-encoder is connected using 6 pin relimate

connectors. Battery provides power to FPGA and all other components are given power from the FPGA. B. Communication Module The communication is done over standard IEEE 802.15.4 Zigbee Protocol [16]. XBee Series 2 RF transceivers are interfaced with FPGA using an open IP core [17] for FPGA based UART controller. Each robot broadcasts its velocity and position to all the other robots on the map. A custom 10 byte packet is designed with 2 byte in start delimiter and 2 bytes in end delimiter. 6 bytes of data contains both position and velocity of the robot. Start Delimiter and End Delimiters are used to make the communication reliable. The data is sent byte by byte as per the protocol. Figure 9(a) shows the packet structure used. A data parser is used to parse velocity and position into six bytes and back. Figure 9(b) shows block diagram of overall module with communication module. Each robot receives the velocity and positions of other robots and performs the operations mentioned in section III. Each robot processes for its own and hence makes the system a distributed system. Figure 10 shows XBee Series 2 mounted on Robot. In case of multiple robots each robot has a separate independent communication module corresponding to each of the other robot i.e. in case of 4 robots, each robot has 3 communication modules and 3 XBee Series 2 mounted on it. Due to this parallelization the data from all other robots arrive at the same instant making the overall process faster than general purpose processor where transmission and reception happens one by one from other robots. In case of FPGA due to the parallelism offered by it the robots communicate with each other almost simultaneously. Start Delim Vel_x Vel_y Pos_x (16 bits) (10 bits) (10 bits) (14 bits)

Pos_y (14 bits)

End Delim (16 bits)

Figure 9(a). Packet Structure for Communication Module rx tx

XBee Module

tx rx

rx_byte

UART Controller tx_byte Position and velocity data from other robots

Data Parser

Algorithm Module

Position and velocity data to other robots Figure 9(b). Communication Module Block Diagram

The advantage of this parallelism can be shown by a simple calculation. Suppose there are n robots on the map. The robots have to send their current positions and velocities to other robots after every update. Suppose B bits per seconds (bps) is the Baud Rate of the XBee module. Now for sending 10 Bytes or 80 bits of data, time required is 80/B seconds. Now in case of FPGA, all robots are communicating in parallel. Hence each robot gets the position and velocity of all other robots in 80/B seconds. In case of general purpose processor which is essentially sequential at hardware level each robot has to wait for (n-1)*80/B seconds to get all the

position and velocities to perform further operations. Even the fast clock of processor is not helpful here because Baud rate is a strict limitation of the transceiver used which in this case is XBee S2. This distinct advantage of FPGA makes the execution of algorithm even faster. It also facilitates the distributed processing without much waits.

XBee

Figure 10. XBee S2 mounted on Robot

Motor

Encoder Figure 11. Motor-encoder pair

Figure 12. PCB of interfacing and driving circuit

C. Motor Interfacing and Control A DC motor is used for driving the wheels. The motor is coupled with an encoder, which gives an output square wave whose frequency is dependent on the velocity of wheel. This encoder is used for the velocity calculation of robot. The speed of robot is controlled using a PID control, which takes a desired velocity as input and provides a pulse width modulated (PWM) signal, which reduces the error in actual velocity. The PID architecture is similar to the one used in [15]. As all outputs of FPGA are CMOS 3.3V logic these are first converted into 5V using buffers and similarly encoder outputs are converted into 3.3V using buffers. The motor driving is done using L293D H-bridge, which converts low power FPGA output to a high power signal, which can drive motor. All this interfacing and driving circuitry is fabricated onto a PCB. The power to the PCB is provided from battery output on FPGA. The 12-13V battery output is converted into 5V and 3.3V using regulators on the PCB. These 5V and 3.3V supplies are required for providing power to the Buffer ICs and other ICs on PCB. Motor-encoder is shown in Figure 11. The PCB for interfacing-cum-driving circuit is the top-most level of robot. The PCB is shown in Figure 12. V. RESULT S AND DISCUSSIONS The hardware design of algorithm is implemented using Xilinx Spartan 3E-500 FG320 FPGA using the Nexys -2 board that has over 10476 logic cells, 20 dedicated multipliers, 20 blocks of BRAM and 50 MHz clock speed. The architecture is described in VHDL as a hardware description language. The design is then made to undergo synthesis, map, place and route using Xilinx ISE 13.4. The nexys-2 board is mounted on the robot itself as shown in section IV. Figure 1(b) shows the Nexys-2 Board.

To determine the performance of FPGA, 2-Robot problem is implemented on FPGA in which each robot has to reach its own destination based on the Reciprocal Collision Avoidance algorithm. The FPGA operates at a clock frequency of 50MHz. To compare the FPGA based hardware implementation’s computational delay with that of a software implementation, a sequential version of algorithm in C++ is generated and studied on a general purpose processor (1.30 GHz Intel® Atom™ Processor E660). This specific processor is used for comparison because it is a commonly used in light weight cell phones similar to FPGA. The actual running time of sequential algorithm is measured via clock ticks using the time function in C/C++ and power dissipation is calculated using power rating of the processor. The power dissipation is measured using XPower Analyzer tool available in Xilinx ISE 13.4. Table I compares the computation time and the power dissipation of system based on Xilinx Spartan 3E-500 FG320 FPGA (Nexys-2 board) and Intel® Atom™ Processor E660 (Tunnel Creek Board).

Through the Table-I we empirically establish that per update processing time for processor is more than the FPGA. (3) When communication between robots is also considered the parallelization of communication with FPGA further reduces its processing time. Taking the real implementation into consideration, two more parameters come into picture, the communication time after each update and response time of the motor due to its inertia. Let the response time of the motor due to its inertia be TM which will be same for FPGA and processor since same motors are used. The response time of robot in case of processor RTproc is (4) and the response time of robot in case of FPGA RTFPGA is (5) From (3) it is clear that (6)

T ABLE I. COMPARISON BETWEEN FPGA AND I NTEL ATOM PROCESSOR E660 2 - Robot

4 - Robot

8 – Robot

Intel Atom Intel Atom Intel Atom Proce ssor FPGA Processor FPGA Processor FPGA Processor E660 E660 E660 Total Computation 23.051 40.325 87.536 170.561 252.098 670.256 Time (ms) Powe r 0.933 0.132 2.369 0.141 3.5866 dissipation 0.112 (W) 42 17 42 17 42 Cost in Euros 17

Figure 13(a). Velocity Profile of Robot -1

The 2-robot case mentioned above is physically implemented on the robots shown in Figure 6. The robots are made to run on the floor and co-ordinates and velocities of the robots are communicated to plotting software at regular intervals. As it can be seen from the Figure 15 the robots follow the path shown in the simulation with a little error which comes in due to irregularities in floor and/or some erroneous communication. Figure 13 shows the velocities (in cm/s) of the Robots and Figure 14 shows position (in cm) of Robots at each instant.

Figure 13(b). Velocity Profile of Robot -2

In case of a general purpose processor, the agent accumulates all necessary data and then performs avoidance [18]. Since accumulation of data is done serially in processor, other robots continue to move making it a bit erroneous as the instantaneous data of other robots' positions are slightly different from the past. Thus when data is getting accumulated for synchronous avoidance the update time tends to increase and the instantaneous coordinates of at-least n-2 robots are not available. On the other hand because of parallelization in FPGA, all the necessary data are accumulated much faster and accurately as actions are taken as soon as the information is available from the other n-1 robots. Therefore, communication time per update is 80/B seconds for FPGA and (n-1)*80/B seconds for a general purpose processor as calculated in section IV-B where n is number of robots on map and B bps is baud-rate.

The difference is not considerable when n is small. But when number of robots is large i.e. n is a big number then the difference becomes a critical parameter in comparing performance of Processor and FPGA in real implementation. Even TFPGA and Tproc are largely dependent on number of robots on map as seen from Table I.

Figure 14. Path Followed

The case where wireless transceiver range is not enough to cover whole map, a particular robot will become aware of other robots’ positions and velocities only when they are close enough. Once a robot comes in range its position and velocity is conveyed to the robot into consideration. If they

are on collision course the avoidance velocities are taken only after the response time is elapsed. From (6) processor takes more time than FPGA to take the action to avoid collision. When transceiver range is very small or when the number of robots increase there could be more collisions due to larger response time of the processor when compared with FPGA. Thus through highly parallel architectures significant and critical advantages can be accrued through FPGA based systems.

significantly faster processing and response times despite lower clock speeds of the processor. Efforts are on to implement the algorithm of higher complexities like SLAM on the FPGA based robotic system which is presented in this paper. REFERENCES [1]

[2] Robot-2

[3] Robot-1

[4]

(b)

(a)

[5]

[6] [7] (c)

(d) [8] [9] [10]

(e)

(f) [11] Robot-1

[12] Robot-2

(h) (g) Figure 15. Actual Run of 2-Robot Case

[13] [14]

VI. CONCLUSIONS This paper presents a FPGA based distributed robotic system capable of multi-robot collision avoidance. FPGA based robotic system shows a clear advantage in terms of power dissipation as well as computation time. FPGA based system are particularly helpful when number of robots in the environment increases and the processor based system tends to become unwieldy. Comparative tabulations between a processor based system and FPGA based system vividly portray the benefits of FPGA based robotics systems. FPGA based systems provide opportunities to exploit its inherent parallelism to come up with novel parallel architectures. Such architectures realized at gate level provide for

[15]

[16] [17] [18]

J. Fischer, A. Ruppel, F. Weisshardt, and A. Verl, “A rotation invariant feature descriptor o-daisy and its fpga implementation,” in Intelligent Robots and Systems (IROS), 2011 IEEE/RSJ International Conference on. IEEE, 2011, pp. 2365–2370. J. Svab, T . Krajnik, J. Faigl, and L. Preucil, “Fpga based speeded up robust features,” in Technologies for Practical Robot Applications, 2009. TePRA 2009. Maya B. Gokhale and Paul S. Graham, “ Reconfigurable Computing, Accelerating Computation with Field Programmable Gate Arrays”, 1 st Ed. pp. 1-10, ISBN: 978-0387261058, Netherlands, Springer Publications 2005. van den Berg, J., Guy, S. J., Lin, M. C., Manocha, D.: Reciprocal n body Collision Avoidance. In: Proc. Int. Symp. Robot. Res., 2009. Cohen, B.J.; Subramanian, G.; Chitta, S.; Likhachev, M., "Planning for Manipulation with Adaptive Motion Primitives," Robotics and Automation (ICRA), 2011 IEEE International Conference on , vol., no., pp.5478,5485, 9-13 May 2011. Bruce, J.; Veloso, M.; "Real-time randomized path planning for robot navigation," Intelligent Robots and Systems, 2002. IEEE/ RS International Conference on , vol.3, no., pp. 2383- 2388 vol.3, 2002. Chansu Suh; Um, T .T .; Beobkyoon Kim; Hakjong Noh; Munsang Kim; Park, F.C., "T angent space RRT : A randomized planning algorithm on constraint manifolds," Robotics and Automation (ICRA), 2011 IEEE International Conference on , vol., no., pp.4968,4973, 9-13 May 2011. C. R. Karr, M. A. Craft, and J. E. Cisneros, “Dynamic obstacle avoidance”, in Proc. Conf. Distrib. Interact. Simul. Syst. Simul. Train. Aerosp. Envir., Int. Soc. Opt. Eng., Orlando, USA, 1995,pp. 195–219. P. Fiorini and Z. Shiller,”Motion planning in dynamic environments using velocity obstacles", Int. J. Robot. Res., vol. 17, no. 7, pp.760 772 1998. J. van den Berg, J. Snape, S. Guy, D. Manocha. Reciprocal collision avoidance with acceleration-velocity obstacles. IEEE Int. Conf. On Robotics and Automation, 2011. C. Carbone, U. Ciniglio, F. Corraro and S. Luongo “ A Novel 3D Geometric Algorithm for Aircraft Autonomous Collision Avoidance” In Proceedings of the 45th IEEE Conference on Decision and Control, USA, 2006. J. Muttersbach, T. Villiger, W. Fichtner, “Practical design of globallyasynchronous locally-synchronous systems”, Advanced Research in Asynchronous Circuits and Systems, 2000. (ASYNC 2000) Proceedings. Sixth International Symposium on , vol., no., pp.52-59, 2000. S. Hauck, Asynchronous design methodologies an overview, Proceedings of the IEEE, vol.83, no.1, pp.69-93, Jan 1995. Roopak Dubey; Neeraj Pradhan; K. Madhava Krishna; Shubhajit Roy Chowdhury, "Field Programmable Gate Array (FPGA) based Collision Avoidance using acceleration velocity obstacles," Robotics and Biomimetics (ROBIO), 2012 IEEE International Conference on , vol., no., pp.2333,2338, 11-14 Dec. 2012. Wei Zhao; Byung Hwa Kim; Larson, A.C.; Voyles, R.M., "FPGA implementation of closed-loop control system for small-scale robot," Advanced Robotics, 2005. ICAR '05. Proceedings., 12th International Conference on , vol., no., pp.70,77, 18-20 July 2005. Wireless Medium Acess Control(MAC) and Physical Layer(PHY) specifications for Low-Rate Wireless Personal Area Networks, IEEE standard 802.15.4, 2006. T imothy Goddard (2010, July 30), Documented Verilog UART , Available : http://opencores.org/project,osdvu Stephen. J. Guy; Jatin Chhugani; Changkyu Kim; Nadathur Satish; Ming Lin; Dinesh Manocha; Pradeep Dubey, “ ClearPath: highly parallel collision avoidance for multi-agent simulation,” In Proceedings of the 2009 ACM SIGGRAPH/Eurographics Symposium on Computer Animation (SCA '09), Dieter Fellner and Stephen Spencer (Eds.). ACM, New York, NY, USA, 177 -187.