opencv robots代写

Assignment 5: Project

Version 2018-10-04

Intent: To analyse a set of specifications, design, test, document and practically evaluate code to perform analysis of sensor data and simple actions based on data on a simulated robotic platform.

Individual Task, Weight: 40%
Due: Refer Program in Subject Outline for Due Date

Assignment Background

Rationale: In a Mechatronics System, sensors produce data at varying rates. Decisions need to be made based on correctly associated data in near real-time. Threading and synchronisation are ways to ensure the system performs as intended, with guarantees on the responsiveness of the system to incoming data changes, processing constraints and system behaviour. Functions that exploit the data require unit testing to ensure they behave correctly. Documentation of your own code allows other developers to utilise it as intended and anticipate outcomes, in the same fashion you use a number of APIs (ROS/OpenCV).

Task: Write a series of components using the ROS CBSE framework that will process data originating from a range of sensors on a simulated robot. Employ appropriate multi-threading and data structures to enable time synchronisation and subsequently interrogation of data which allow simple actions of a robotic platform. Supply appropriate auto-generated documentation utilising inline source mark-up. Exploit unit testing framework with test cases evaluating code.

Students can select from two projects

1. 1)  Exploration of Frontiers
2. 2)  Rapidly exploring random Trees
3. 3)  Path Following

Project 1: Frontier Based Exploration

The starting configuration is the current position of the robot; the goal position is to be determined and requested via a Service call.

Create a ROS node that:

•   Subscribes to the OgMap and the Robot Position on /odom and /map_image/full topics
•   The inner working of component is such that it performs following every 10 seconds

o Computes the frontier cells of the OgMap and stores them in a STL container o Computes a Goal Pose from the frontiers as:

•   Closest location to the current robot position (shortest distance) within free space neighbouring a frontier cell.
•   Angle (heading – yaw) such that that the goal pose has a heading towards unknown space

o Computes all the frontier cells that are visible from that goal pose (use the goal pose computed and current map)

o Publish an image on /map_image/fbe topic that shows: (1) input OgMap, (2) Frontiers (blue), (3) Goal Pose (green) and (4) cells that will be seen from Goal Pose (red)

o Transforms coordinates between coordinate systems of:  local (ogmap – pixel / map centre )
 global (robot position)

o Request the Goal Pose in global coordinates via the service call /request_goal

•   Have ability to receive requests for the path on /path topic using the PoseArray message

  (http://docs.ros.org/api/geometry_msgs/html/msg/PoseArray.html) and thereafter publish

  an image of current OgMap on /map_image/fbe topic

•   Unit test:

o Local to Global and Global to Local Transform
o Goal pose computation on two sample OgMap images
o Frontier cells that will be covered from that Goal pose on two sample OgMap images

 (For D/HD)
o When storing the Frontiers cells in STL container, group them based on connectivity

(frontier cells that are 8-connected are deemed to be connected https://en.wikipedia.org/wiki/Pixel_connectivity ).

Bonus Mark (additional 15% of marks)

In order to improve the frontier selection, pose selection should incorporate some optimality, such that the Goal Pose selected would cover the largest amount of frontier cells from a single viewpoint. Determine this optimal viewpoint. NO additional guidance will be provided for Bonus Mark questions.

Project 2: Rapidly exploring Random Tree (RRT)

The starting configuration is the current position of the robot; while the goal position is the desired end position, specified with a Service call.

Create a ROS node that:

•   Subscribes to the OgMap and the Robot Position on /odom and /map_image/full topics
•   The inner working of component is such that it responds to Requests for Goal Pose (in global

  coordinates) that arrive via the service call /request_goal by

o Computing the configuration space from the OgMap taking into account the

diameter of the Robot (20cm)
o Transforming coordinates between coordinate systems of:

 local (ogmap – pixel / map centre )

 global (robot position) o Creating a RRT

•   With basic implementation where control is randomly drawn from below set V [m/s] and ω [rad/s] with t=1.0s. V,ω=(0.1,0)(0.25,0),(0.1,0.1)(0.1,0.2),(0.1,-0.1),(0.1,-0.2)
•   Terminate when control action is within 0.2m of goal pose

o Publishing the path to /path topic using the PoseArray message

(http://docs.ros.org/api/geometry_msgs/html/msg/PoseArray.html).
o Publishing an image of the RRT overlaid on the OgMap, nodes in (blue), goal (green),

path (red) on /map_image/prm topic

•   Abandon current RRT construction and recommence new RRTif new Goal Pose is supplied

  via the service call /request_goal

•   Unit tests:

o Local to Global to Image Transform
o RRT computation on two sample OgMap images

 (For D/HD)
o In addition to the default random control from a set, implement a second approach

for building the RRT that selects a control action that steers the robot towards the random point. Compare results of the two approaches based on (1) number of nodes and (2) path length.

o Allow selecting either method on initialising component Bonus Mark (additional 15% of marks)

Narrow passages present significant challenges for RRT implementations. Implement a bi directional RRT to address this issue. NO additional guidance will be provided for Bonus Mark problem.

Project 3: Path Following

The starting configuration is the current position of the robot while the on /path topic using the PoseArray message (http://docs.ros.org/api/geometry_msgs/html/msg/PoseArray.html)

Create a ROS node that:

•   Subscribes to the OgMap and the Robot Position on /odom and /map_image/full topics
•   The inner working of component is such that it on receipt of path:

o Computes velocity V, time t and , angle θ to steer the robot between all points oF the path supplied, performing turning on the spot and driving in straight lines (no angular velocity in straight lines)

o Executes the control action, ensures the robot undertakes the computed motions to reach all points in the path within a tolerance of 0.1m and 5deg, recomputing control actions as the points are reached

o Publishes an image on /map_image/path_following topic that shows: (1) OgMap, (2) completed points (blue), (3) current point being completed (green) and (4) upcoming points (red)

 Unit tests:
o Control action computation on two sample Paths overlaid on images

 (For D/HD)
o Implement the waypoint following code for the robot as a combination of on the

spot turns and pure pursuit.

Bonus Mark (additional 15% of marks)

In order to make the waypoint following smoother, devise a strategy that analyses the path supplied and creates smoother paths (augmenting the path based on the OgMap). NO additional guidance will be provided for Bonus Mark questions.

Assessment Criteria Specifics

The format of the assessment will

Conceptual Support

Occupancy Grid Map (OgMap), Environment Representation

An OGMap is a discrete representation of the environment, used to denote space known to a robot. In its most basic implementation the value of each cell in the map represents the robot’s knowledge of the occupancy of the space. That is, either occupied, free-space or unknown

Figure 1 – Gazebo Simulation (Maze, Robot)

The framework for receiving data and publishing the OgMap (encoded as an OpenCV image) is provided. The map size is known (20×20 meters), each cell is stipulated to be of size 0.1m. Both projects require querying the Occupancy Grid Map (OGMap).

In the implementation of OgMap supplied the robot position coincides with the centre of the OgMap.

Rapidly exploring Random Tree (RRT)

Figure 2 – `”Rapidly-Exploring Random Trees: A New Tool for Path Planning (1998) by S. Lavalle

Frontiers and Exploration

Exploration is the act of moving through an unknown environment, thus allowing building a map of the environment which can be used for subsequent navigation. A good exploration strategy is one that generates a complete or nearly complete map in a reasonable amount of time.

One approach for exploration is based on the detection of frontiers, regions on the border between known free space and unknown space. A frontier cell is a free cell bordering unknown space.

From any frontier, the robot could see into unexplored space and add the new observations to its map. From each new vantage point, the robot may see new frontiers lying at the edge of its perception. By pursuing each frontier the robot can build a map of every reachable location in the environment. OgMaps can be leveraged as spatial representation suitable for determining frontiers. For an explanation of frontiers in OgMaps revert to http://robotfrontier.com/frontier/simple.html

Figure 3 – Example of frontier, from Juliá, M., Reinoso, O., Gil, A., Ballesta, M., & Payá, L. (2010). A hybrid solution to the multi-robot integrated exploration problem. Engineering Applications of Artificial Intelligence, 23(4), 473-486.

Path Following of a RRT generated path

The RRT produces a path that is valid yet contains a number of nodes and edges that could be incredibly hard and overcomplicated for a robot to follow. Nevertheless, in the basic implementation a path follower can simply ensure the control for the robot traverses each point on the path supplied, coordinating the velocity, time and orientation of the robot for this action.

However, more often after a path is created by a sampling based planner (such as RRT), smoothing of the path is completed to ensure a continuous controllable path is executed. Nodes of the paths are removed or reorganised to allow smoother control with a robotic platform taking into account kinematic constraints.

Figure 4 – The complexity of RRTs (Replanning with RRTs, D. Ferguson et al, CMU, 2006), (top) a RRT with all nodes and (bottom) a pruned RRT removing surplus nodes, showing 3 paths.