Embedded Files
High-Level Architecture
High-Level Architecture
Full State Diagram: Pick and Place Node
Design Description
Design Description
The robotic pipeline used in the project involves two general nodes: a collaborative decision maker, and a pick-and-place node. The design was implemented this way because the resource gathering task can be broken up into many sub pick-and-place tasks that can be directed by the collaborative decision making node.
The collaborative decision maker is responsible for viewing the AprilTags, and understanding from that which blocks are relevant for the task and in which order the task should be completed. This node will do this for completing both our on resource assembly, as well as for mimicking our collaborating team's assembly. Once this node has decided what order to pick up the blocks and where to place them, the collaborative decision making node will then direct the pick-and-place node.
The pick-and-place node takes in inputs of which block to pick up, and where to place that block. For each block that is to be gathered, the pick-and-place node accomplishes picking and placing for each block, and then waits for the collaborative decision maker to send it another task where it will pick and place consecutive blocks until the collaborative decision maker deems that the full resource gathering task is complete.
Perception Strategy
Perception Strategy
Once cubes were spawned in the Gazebo environment, the visualization node uses the RealSense camera to detect blocks within the camera frame. Blocks of a requested color were detected using HSV color filtering.
Once cubes were spawned in the Gazebo environment, the visualization node uses the RealSense camera to detect blocks within the camera frame. Blocks of a requested color were detected using HSV color filtering.
To integrate this into the overall pipeline, the visualization node was created into an action server, and a client to the service output all the block locations for a requested color when it made a request to the server.
To integrate this into the overall pipeline, the visualization node was created into an action server, and a client to the service output all the block locations for a requested color when it made a request to the server.
In addition, specific requests could be made to specify which frame the server should send the data in.
In addition, specific requests could be made to specify which frame the server should send the data in.
Navigation Strategy
Navigation Strategy
Navigating the robot was carried out by creating a feedback control action server for the mobile base to move to a generic pose. This server implemented simple PI control taking the current pose of the mobile base as the state while accounting for the holonomic constraint on the locobot's velocity. Further, a client to the service was created which could send any target destination to the server.
Navigating the robot was carried out by creating a feedback control action server for the mobile base to move to a generic pose. This server implemented simple PI control taking the current pose of the mobile base as the state while accounting for the holonomic constraint on the locobot's velocity. Further, a client to the service was created which could send any target destination to the server.
Although this implementation worked quite well for the provided tasks, it may not be generalizable. Instead, using a Navigational package in ROS and using SLAM with the LiDAR sensor on the Locobot would make the Navigational component much more accurate.
Although this implementation worked quite well for the provided tasks, it may not be generalizable. Instead, using a Navigational package in ROS and using SLAM with the LiDAR sensor on the Locobot would make the Navigational component much more accurate.
Collaboration Strategy
Collaboration Strategy
The Collaboration Strategy involves using an Event-based Check and Response System:
1. Event Checkers are used to alert the Locobot when a certain event is triggered (such as a block is picked up or the other team's Locobot has completed its task)
The Collaboration Strategy involves using an Event-based Check and Response System:
1. Event Checkers are used to alert the Locobot when a certain event is triggered (such as a block is picked up or the other team's Locobot has completed its task)
2. Event Response Functions are called once the Event Checker signals and Event being triggered and the Response Functions performs the necessary actions depending on what the Current State is in the State Machine and which Event was triggered
2. Event Response Functions are called once the Event Checker signals and Event being triggered and the Response Functions performs the necessary actions depending on what the Current State is in the State Machine and which Event was triggered
3. A general Hardware Abstraction Layer is also used to connect the sensors (such as Camera and Lidar data) to the State Machine and the Event-drive system.
3. A general Hardware Abstraction Layer is also used to connect the sensors (such as Camera and Lidar data) to the State Machine and the Event-drive system.
Page updated
Google Sites
Report abuse