uRON v1.5: A Device-Independent and Reconfigurable Robot Navigation Library Sunglok Choi, Jae-Yeong Lee, and Wonpil Yu Abstract— Many laboratories and companies are developing a mobile robot with various sensors and actuators. They implement navigation techniques usually tailored to their own robot. In this paper, we introduce a novel robot navigation library, Universal Robot Navigation (uRON). uRON is designed to be portable and independent from robot hardware and operating systems. Users can apply uRON to their robots with small amounts of codes. Moreover, uRON provides reusable navigation components and reconfigurable navigation framework. It contains the navigation components such as localization, path planning, path following, and obstacle avoidance. Users can create their own component using the existing ones. uRON also includes the navigation framework which assembles each component and wraps them as high-level functions. Users can achieve their robot service easily and quickly with this framework. We applied uRON to three service robots in Tomorrow City, Incheon, South Korea. Three robots had different hardwares and performed different services. uRON enables three robots movable and satisfies complex service requirements with less than 500 lines of codes.

I. I NTRODUCTION Navigation is one of the most important tasks of a mobile robot to perform complex services such as cleaning, delivery, guidance, and patrol. For example, a delivery robot needs to know its location in its operating environment. It also needs to generate a feasible path from its current location to the target location. It should be controlled to follow the path and avoid unexpected obstacles. Navigation is one of the oldest topics in robotics due to its importance [1]. Many valuable researches have been performed to enrich this field up to recently. Many laboratories and companies are developing their mobile robot with various sensors and actuators. They build navigation techniques usually tailored to their own robot. For example, MobileRobots, a famous robot builder, provides its own navigation solutions (ARIA, ARNL, and Mapper) [2] for its mobile robots. Similarly, Evolution Robotics also sells its own navigation solution, ERSP [3], incorporated with its mobile robots. However, it is difficult to employ such tailored solution to other robots. Users need to implement each algorithm considering their robot hardware and navigation requirements. It is necessary to develop a robot navigation library which can apply to various systems and is reconfigurable to satisfy various This work was supported partly by the R&D program of the Korea Ministry of Knowledge and Economy (MKE) and the Korea Evaluation Institute of Industrial Technology (KEIT). (2008-S-031-01, Hybrid u-Robot Service System Technology Development for Ubiquitous City) Sunglok Choi, Jae-Yeong Lee, Wonpil Yu, and Jae-Il Cho are with Robot and Cognitive System Research Department, Electronics and Telecommunications Research Institute (ETRI), Daejeon, Republic of Korea

{sunglok, jylee, ywp}@etri.re.kr

requirements. A computer vision library, OpenCV, is a good example to support such necessity. Previous Navigation Libraries CARMEN, Karto SDK, and MRPT are representative robot navigation libraries. The Carnegie Mellon Robot Navigation Toolkit (CARMEN) [4] is an open-source navigation library since 2005. Its last version 0.7.4-beta was released at October 2008. It consists of several modules: localize, vasco (mapper), navigator, and so on. It is based on Linux system and written in C language. However, it is hard to apply to various systems because it is designed to specific systems (Linux, a dozen of robot bases, and several LRFs). It is also difficult to reuse its modules, that is, users should modify the original source codes directly due its implementation in C language. Karto SDK [5] was initiated by SRI International’s Artificial Intelligence Center. Its recent version 2.0 was released as dual licenses (LGPL and commercial) at July 2010. The Mobile Robot Programming Toolkit (MRPT) [6] is an open-source library started at the University of Malaga, Spain. Its recent version 0.9.1 was released at August 2010. Both are designed to be portable and reusable and written in C++ language. They also contain various navigation functionalities related to localization, mapping, path planning, and obstacle avoidance. Especially, they focus on SLAM. Karto SDK implements their SLAM algorithm with GPU and multi-threaded optimization. MRPT provides various kinds of the state-of-theart SLAM algorithms and their examples. They are quite valuable works. However, they do not have a navigation framework to utilize them easily and quickly, so users need to assembly each module by themselves. Moreover, they only concentrate on a grid map, and does not support a topology map such as a road map. uRON Library In this paper, we introduce a novel robot navigation library, Universal Robot Navigation (uRON) [7]. Its recent version 1.5 was released August 2010. uRON is designed to be portable and independent from robot hardware and operating systems. We abstract operating system resources (i.e. thread and timer) by wrapping them in common interfaces. We also categorize various robot devices into a location sensor, range finder, and motor controller. uRON communicates with them through predefined data structures and interfaces. Users only need to develop small amounts of codes to interface their hardware with uRON (usually less than 500 lines of codes). uRON provides reusable navigation components and reconfigurable navigation framework. It contains various and useful navigation components such as a map, localizer, path planner, path follower, and obstacle avoider. Especially, it includes the state-of-the-art

(a) A Grid Map

(b) A Topology Map

Fig. 2. uRON supports two types of maps: a grid map and topology map.

Fig. 1. uRON Navigation Components: uRON has various and useful components which perform localization, path planning, path following, and obstacle avoidance.

path planners (i.e. CFA* and Theta*) and popular obstacle avoiders (i.e. VFH+). It also supports two different types of maps: a grid map and topology map. Each component is highly modular and object-oriented, and users can modify the components by inheriting from them. uRON has the reconfigurable navigation framework which enables users to use it easily and quickly. Users can replace each navigation component in the framework. They also can achieve their robot services using high-level navigation functions on the framework. We also present its application to three different types of robots in Tomorrow City, Incheon, South Korea. Three robots equipped with different hardware and needed to perform different services such as guidance, delivery, and advertisement. uRON with small additional codes could operate three robots and satisfy their navigation requirements. Actually, less than 500 lines of C++ codes were enough to achieve it. This application presents effectiveness of our navigation library. II. U RON NAVIGATION C OMPONENTS uRON contains various navigation components which are useful to enable robot navigation. The components perform localization, path planning, path following, and obstacle avoidance as shown in Figure 1. uRON assumes that the operating environment are planar, which is common in indoor and on-road situations. Therefore, pose of robot is represented as its position and orientation, [x, y, θ]T . Its velocity is also described through its linear and angular components, [v, w]T . A. Map uRON supports two different types of maps: a grid map and topology map as shown in Figure 2. A grid map describes a continuous space as a collection of discrete cells similar to a bitmap image. It is also divided into binary

and occupancy grid maps according to a way of represent occupancy. A binary grid map uses a Boolean value, 1 and 0, to represent state of each cell, block or unblock. An occupancy grid map uses a real number between 0 and 1 which represents probability or certainty of occupancy of each cell. The grid map is regarded as a dense graph whose node is the center of cells and connected with unblock neighborhood. A topology map simplifies the space using connectivity information similar to a subway map. It is represented as a sparse graph. For example, a road map is composed of roads and their intersections, and the intersection is modeled as a node, and the road is modeled as an edge. A grid map maintains appearance of the given space, so it can deduces geometric and topological information. However, a topology map only keeps connectivity of sub-regions of the space, but it is more concise representation. B. Localizer A localizer estimates pose of robot from various sensor data. uRON contains EKF localization whose state is defined as pose of robot, x = [x, y, θ]T . It can integrate two types of measurements together: displacement and pose of robot. EKF localization predicts the next state using a relative displacement, [∆x, ∆y, ∆θ]T . Odometry motion model is implemented as a default transition function as follows:     xk xk−1 + δtrans cos(θk−1 + δrot1 )  yk  =  yk−1 + δtrans sin(θk−1 + δrot1 )  , (1) θk θt−1 + δrot1 + δrot2 where a control input u = [δtrans , δrot1 , δrot2 ]T comes from the relative displacement [8]. A default observation function is as follow:      x ˆk 1 0 0 xk  yˆk  =  0 1 0   yk  , (2) 0 0 1 θk θˆk which assumes that observation is an absolute pose, z = ˆ T . Users can simply substitute transition and obser[ˆ x, yˆ, θ] vation functions by overriding them. C. Path Planner A path planner generates a collision-free path from the start and target points on the given map. The path is represented as a series of points on the map. Grid and topology maps are regarded as graphs, and A* and Dijkstra’s algorithm are popular tools for searching them. uRON contains basic A* and Dijkstra’s algorithm and their extensions. It also includes advanced path planners such as Theta* and CFA*.

where vmax is the operating linear velocity. The robot is gradually converged to the given path when its velocity is controlled to be [vc , wc ]T . uRON includes a smooth path tracker using landing concept [13]. In our experiments, the landing path tracker had worse performance than pure pursuit [14]. E. Obstacle Avoider

(a) A*

(b) Theta*

Fig. 3. Paths by A* and Theta*: (a) A* generates a path with zig-zag pattern, but (b) Theta* generates the shortest path in Euclidean sense. Cyan means their search regions.

Theta* [9] is the state-of-the-art solution to overcome zigzag patterns on A* path. Theta* utilizes Euclidean distance as its cost and heuristic functions, so it can generate the shortest path in Euclidean sense. Figure 3 presents example paths by A* and Theta*. Theta* performs a collision test when it decides a parent node, which degrades its computing time. uRON has a fast implementation of Theta* using noncollision pruning [10]. Theta* with non-collision pruning is about 2 times faster than the original Theta*. Coarse-to-Fine A* (CFA*) [11] uses a multi-resolution grid map to accelerate A*. It automatically generates a coarse-resolution grid map considering radius of robot. It searches a path on the coarse grid map, and marks the path on a fine-resolution grid map. Again, CFA* searches a path only on the marked region of the fine grid map. CFA* is about 60 times faster than A* because it restricts search region significantly. D. Path Follower A path follower returns target velocity to follow the given path considering current pose and velocity of robot. The target velocity is represented as [vc , wc ]T . uRON contains pure pursuit and a path tracker using landing concept. A path follower is usually performed as two steps: selecting a pivot point and calculating the target velocity. As a simple method, a pivot is selected as a point on the path which is slightly ahead from the nearest point from the robot. Pure pursuit [12] tries to reach the selected pivot under circular motion. It represents radial and angular error between the pivot and robot as follows: q D = (xp − x)2 + (yp − y)2 , (3) ∆θ = atan2(yp − y, xp − x) − θ , where [xp , yp ]T is location of the pivot. The error derives the target velocity to approach the pivot through circular motion as follows: vc = vmax

and

wc =

2vc sin ∆θ , D

(4)

An obstacle avoider returns target velocity to avoid obstacles using range measurements. Its output, target velocity, is quite similar with a path follower. In unmanned ground vehicles (UGVs), both are called as a local path planner because they decide an instantaneous and short-range path. They are usually performed as on-line, in contrast, a (global) path planner works off-line. A navigation framework in uRON merges them together as subsumption architecture [15] as shown in Figure 5. A path follower contains an obstacle avoider as its lower-level behavior. uRON contains ‘pause and resume and VFH+ as obstacle avoiders. Pause and resume is a simple strategy to stop in front of obstacles and resume its action after the obstacles are disappeared. Vector Field Histogram+ (VFH+) [16] selects safe and smooth moving direction using a polar occupancy histogram. It builds and updates a local certainty map during navigation. The certainty map represents amount of obstacles around the robot. VFH+ projects 2D certainty map into 1D polar histogram around the robot. The polar histogram deduces block and unblock moving direction, and they become candidates of future moving direction. VFH+ selects the best moving direction which minimizes the defined cost function. The cost function takes into account degree of safety and smoothness. III. U RON NAVIGATION F RAMEWORK To achieve navigation, users should assembly and execute each navigation component with appropriate data and parameters. At first, the users need to run a path planner with target and current positions after getting location from a sensor. After generating a path, the users need to transfer the path to a path follower. Moreover, the users should periodically execute the path follower with current pose and velocity to pursue the given path. Such implementation seems natural and common, but complex. A. Internal Structure uRON provides a navigation framework which enables user to employ uRON easily and quickly. The framework connects each component as shown in Figure 5. Users only needs to fill each component using assignment functions (i.e. SetPathPlanner()). The assignment functions make the users to adopt and replace each component easily and quickly. For example, the users try to use a grid-based path planner in indoor and a topology-based planner in outdoor. Such substitution is achieved by only one line of codes using the assignment functions. Moreover, the navigation framework also provides three levels of movement functions: manual, relative, and absolute movement functions. The manual movement functions are used when users try to move

Fig. 4. A navigation example using uRON: A robot (a blue circle) generates a path (a red line) and follows it (blue dots). Moreover, the robot avoids obstacles for safety.

Fig. 6.

A finite state machine (FSM) in uRON navigation framework.

Fig. 7. A connection of uRON navigation framework with robot hardware.

Fig. 5. uRON Navigation Framework: The framework assemblies each component and executes appropriate one with respect to its state. It also provides useful high-level functions for its easy usage.

tion. The callback functions make the users add their desired actions easily and quickly after each event. Such high-level functions help the users to employ uRON.

their robot manually. The relative movement functions make the robot move with respect to the robot coordinate. The absolute movement functions make the robot move with respect to the absolute coordinate on a map. uRON provides blocking and non-blocking functions in case of relative and absolute movements. The blocking functions are terminated after it achieves its goal, but the non-block functions are ended just after calling the functions. The movement functions help users to develop their desired service easily and quickly. For example, when users try to make a charging action, a series of blocking movements can achieve the action. The navigation framework has a finite state machine (FSM) which executes a necessary component with respect to its state as shown in Figure 6. The FSM has 19 states such as STATE STOP and STATE PATH FOLLOWING. Users can recognize important events through callback functions (i.e. CallbackError()) without monitoring the state. The framework executes an appropriate callback function when it encounters errors or state transition or movement termina-

B. External Structure The navigation framework categorizes robot hardware into a location sensor, range finder, and motor controller. A lot of robot hardware exists, but their roles in navigation belong to three categories. For example, a LRF measures distance from its center to obstacles and a stereo camera provides a depth image in front of it. A LRF provides one dimensional range data, and a stereo camera gives two dimensional range data. It is only difference of them. Both perform the same role, which is to provide range measurements around the robot. Users need to connect their robot hardware with the navigation framework as shown in Figure 7. First, uRON sends and receives pose estimates through a predefined interface, uRON::PoseCase. The navigation framework follows the interface. Users need to send pose of robot [x, y, θ]T through its internal function SetPose(). Moreover, it is possible to give displacement of robot [∆x, ∆y, ∆θ]T using its function AddPose(). Pose by GPS and indoor GPS usually passes through the function SetPose(), and displacement

uRON independent from root hardware. IV. A PPLICATION TO T OMORROW C ITY S ERVICE ROBOTS

Fig. 8. A beam description: A range finder is located at (offset.x, offset.y, offset.theta). A viewing angle of beam is beamWidth. ith beam is toward beamDirection[i].

Fig. 9. An example connection of uRON navigation framework incorporated with EKF Localizer.

by odometry and IMU usually goes through the function AddPose(). Second, uRON sends and receives range data through a predefined interface, uRON::RangeDataCase. An obstacle avoider and map builder follows the interface. Users need to send range data through its internal function SetRangeData(). The range data are represented as the beam unit with its description as shown in Figure 8. Third, the navigation framework controls a robot through its internal function ControlVelocity(). Users need to implement the function which sends target velocity to their motor controller. The function ControlVelocity() may send a packet to the controller or execute API related to the controller. Sometimes, users are necessary to develop an algorithm which transforms raw sensor measurements to pose or range data. For example, a pair of measurements from wheel odometers is transformed to displacement of robot using robot kinematics. Wheel odometers and GPS can be utilized together to get more accurate pose estimates. Bayesian filters (i.e. EKF and particle filter) are popular methods to fuse their measurements. uRON provides the EKF localizer whose connected situation is described at Figure 9. The localizer is outside of the navigation framework. uRON separates its framework from such operation close to sensors. It makes

We applied uRON to three types of service robots in Tomorrow City located at Incheon, South Korea. Three robots were developed by different companies with different motor controllers and sensors. Figure 10 presents three robots with their hardware specification. Each robot was developed to perform three different services: guidance, delivery, and advertisement. Three robots performed their service during 80 days incorporated with Global Fair & Festival 2009 Incheon. They are good examples to present two significant features of uRON: device-independent and reconfigurable. Device-independence uRON was successfully applied to three robots by adding less than 500 lines of codes. Their implementation utilized the navigation framework of uRON, and the additional codes connected robot hardware with the framework. The codes commanded the motor controller with respect to the given target velocity. The codes also transferred pose and range data after retrieving measurements from each sensor. uRON with small amounts of codes enabled three robots to perform navigation. It means that uRON, especially its navigation framework, was effective even if different hardware (Figure 10). uRON v1.5 provides code examples which were utilized by three robots in Tomorrow City. Reconfigurability uRON satisfied complex navigation requirements in Tomorrow City by adding less than 500 lines of codes. Among the requirements, an obstacle avoider was necessary to perform below operations when a robot encounters obstacles. Step1. Stop until the defined waiting time. If there are still the obstacles, perform the next step. Step2. Start to avoid the obstacles. If the avoidance is failed, perform the next step. Step3. Report the failure to the control center of Tomorrow City. However, uRON does not contain such obstacle avoider, so we needed to develop it. We implemented a new obstacle avoider using two existing components, uRON::PauseAndResume and uRON::VFHPlus. Figure 11 presents our new avoider briefly. uRON::PauseAndResume performed the waiting action at the first step, and uRON::VFHPlus performed the avoiding action at the second step. We only used simple conditional statements and executed two components according to the conditions. Similarly with the obstacle avoider, we made a new path planner to satisfy the remaining requirements. V. C ONCLUSION We introduce a novel robot navigation library, uRON. uRON is designed to be independent from robot hardware and operating systems. uRON also contains reconfigurable and useful navigation components and framework. It includes the state-of-the-art algorithms such as Theta* and CFA*. We applied uRON to three service robots with different hardware and services. uRON with small amounts of codes enables

(a) Three service robots with their hardware specification Fig. 10.

(b) Tomorrow City

Three robots (a) were applied to Tomorrow City (b). They equipped different hardwares and perform difference services.

Fig. 11. A new obstacle avider to satisfy navigation requirements in Tomorrow City.

three robots movable and satisfies complex their navigation requirements. As further works, uRON needs to include mapping and SLAM algorithms for being the complete navigation solution. The navigation components of uRON now assume that a target robot is holonomic. It is necessary to develop anther components which take into account of nonholonomic constraint (i.e. car-like kinematics). Moreover, a path follower can be advanced by considering dynamics of robot, and an obstacle avoider can be incorporated with replanning (i.e. D*). ACKNOWLEDGEMENT The authors would like to thank Jaeyong Seo, Cass Woo, Eun-Soo Jang, Haksoo Lee, and Hyun-Joong Kim for their collaboration of developing Tomorrow City service robots. R EFERENCES [1] N. J. Nilsson, “A mobile automation: An application of artificial intelligence techniques,” in Proceedings of International Joint Conference on Artificial Intelligence (IJCAI), May 1969.

[2] “MobileRobots Research and Academic Customer Support,” http://robots.mobilerobots.com/wiki/All Software [3] “Evolution Robotics ERSP,” http://www.evolution.com/products/ersp/ [4] “CARMEN,” http://carmen.sourceforge.net/ [5] “Karto SDK,” http://www.kartorobotics.com/ [6] “MRPT,” http://www.mrpt.org/ [7] “ETRI uRON,” http://robotask.etri.re.kr/wiki/uRON [8] S. Thrun, W. Burgard, and D. Fox, Probabilistic Robotics. The MIT Press, 2005. [9] A. Nash, K. Daniel, S. Koenig, and A. Felner, “Theta*: Any-angle path planning on grids,” in Proceedings of AAAI Conference on Artificial Intelligence (AAAI), 2007. [10] S. Choi, J.-Y. Lee, and W. Yu, “Fast any-angle path planning on grid maps with non-collision pruning,” in Proceedings of IEEE Conference on Robotics and Biomimetics (ROBIO), 2010. [11] J.-Y. Lee and W. Yu, “A coarse-to-fine approach for fast path finding for mobile robots,” in Proceedings of IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2009. [12] R. C. Coulter, “Implementation of the pure pursuit path tracking algorithm,” Camegie Mellon University, Tech. Rep. CMU-RI-TR-9201, 1992. [13] K. C. Koh and H. S. Cho, “A smooth path tracking algorithm for wheeled mobile robots with dynamic constraints,” Journal of Intelligent and Robotic Systems, vol. 24, pp. 367–385, 1999. [14] S. Choi, J.-Y. Lee, and W. Yu, “Comparison between position and posture recovery in path following,” in Proceedings of International Conference on Ubiquitous Robot and Ambient Intelligence (URAI), 2009. [15] R. A. Brooks, “A robust layered control system for a mobile robot,” MIT AI Memo, vol. 864, September 1985. [16] I. Ulrich and J. Borenstein, “VFH+: Reliable obstacle avoidance for fast mobile robots,” in Proceedings of IEEE International Conference on Robotics and Automation (ICRA), 1998.

uRON v1.5: A Device-Independent and Reconfigurable ...

The authors would like to thank Jaeyong Seo, Cass Woo,. Eun-Soo Jang, Haksoo Lee, and Hyun-Joong Kim for their collaboration of developing Tomorrow City ...

2MB Sizes 4 Downloads 134 Views

Recommend Documents

Ads Integrity v15 Services
updating our advertising policies and emerging threats. BUSTING BAD ADVERTISING PRACTICES IN 2013. OVERVIEW. MAINTAINING A HEALTHY ADVERTISING ECOSYSTEM. 2013 TRENDS. STOPPING BAD ADS AND CONTENT and content in our network with a combination of autom

Reconfigurable computing iee05tjt.pdf
There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. Reconfigurable ...

Reconfigurable Plasmonic Filters and Spatial ...
combined with the scaling law, and the commercial software HFSS. ..... analytical relation between the circuit elements and graphene's conductivity [55] allows to ...

Characterizing the Opportunity and Feasibility of Reconfigurable ...
best memory hierarchy configuration for each application, ..... Includes dynamic power only, no accounting ..... and Software (ISPASS), White Plains, NY, 2010.

Characterizing the Opportunity and Feasibility of Reconfigurable ...
tablet, laptop, and server environments. As Moore's law continues to deliver ... the memory wall [10], multi-level caches have been a key element of computer architecture for decades with research studies spanning organization [11], write and ...

JAM-V15-Results-2010.pdf
Peter Kirk Port. Madison. Yacht Club. 9.0 4.0 4.0 5.0 2.0 7.0 1.0 7.0 4.0 3.0 5.0 8.0 7.0 (14.0. DNF). 14.0. DNC. 94.0 80.0. 8th V15 699 Jacob Bruce Thomas.

Reconfigurable optical add and drop modules with servo control and ...
Dec 31, 2004 - currently in the art are characteristically high in cost, and prone to ..... For purposes of illustration and clarity, only a selective. feW (e.g., three) of ...

Reconfigurable optical add and drop modules with servo control and ...
Dec 31, 2004 - cantly enhances the information bandwidth of the ?ber. The prevalence of ... OADM that makes use of free-space optics in a parallel construction. .... control assembly serves to monitor the optical power levels of the spectral ...

Reconfigurable interconnects in DSM systems, a ...
(OS) and its influence on communication between the processing nodes of the system .... and secondly the Apache web server v.1.3 concurrently run with the.

A Memory-Efficient Reconfigurable Aho ... - Research at Google
Firewalls, i.e. security systems permitting or blocking packets based on their header information, have been a standard security solution for several years but are ...

Reconfigurable Models for Scene Recognition - Brown CS
Note however that a region in the middle of the image could contain water or sand. Similarly a region at the top of the image could contain a cloud, the sun or blue ..... Last column of Table 1 shows the final value of LSSVM objective under each init

081216 A Design of Asynchronous Double-Grain Reconfigurable ...
081216 A Design of Asynchronous Double-Grain Reconfigurable Computing Array _for ANSCSE 13.pdf. 081216 A Design of Asynchronous Double-Grain ...

A Five-Band Reconfigurable PIFA for Mobile Phones - IEEE Xplore
PLANAR inverted F antennas (PIFAs) are widely used in mobile phones [1]–[8]. This is primarily because they ex- hibit an inherently low specific absorption rate ...

19106853-Reconfigurable-Computing-Accelerating-Computation ...
Connect more apps... Try one of the apps below to open or edit this item. 19106853-Reconfigurable-Computing-Accelerating-Computation-With-FPGAs.pdf.

vlsi design and implementation of reconfigurable ...
Apr 10, 2009 - In this paper a reconfigurable cryptographic system is proposed. .... the RAM blocks which are used for keys storage, and the. RCS. Core that is.

reconfigurable antennas for sdr and cognitive radio
and WiMAX (again, several bands are proposed). Many of these systems will be required to operate simultaneously. Multi-mode, multi-band operation presents a formidable challenge to mobile phone designers, particularly for the RF parts. Of these, the

Protection Primitives for Reconfigurable Hardware
sound reconfigurable system security remains an unsolved challenge. An FPGA ... of possible covert channels in stateful policies by statically analyzing the policy enforced by the ...... ranges, similar to a content addressable memory (CAM).

Studying Nonlinear Dynamical Systems on a Reconfigurable ... - Sites
So, the analog de- signer must depart from the traditional linear design paradigm, ..... [4] B.P. Lathi, Modern Digital and Analog Communication Systems, Oxford.

OpenDF – A Dataflow Toolset for Reconfigurable ...
Software development for uniprocessor sys- tems is completely dominated by imperative style program- ming models, such as C or Java. And while they provide ...

Reconfigurable processor module comprising hybrid stacked ...
Jul 23, 2008 - (75) Inventors: Jon M. Huppenthal, Colorado Springs, .... Conformal Electronic Systems, University of Arkansas, Fay ..... expanding the FPGA's capacity and performance. The tech nique of the present invention may also be ...