Giter VIP home page Giter VIP logo

ros_bridge's Introduction

Python Adapter for MTConnect C++ Agent

This is a simple adapter library written in Python to support the ROS robotics integration project. The adapter supports multiple connections, heartbeats and the following MTConnect data item types:

  • Event - A simple data item that usually contains with either a controlled vocabulary like ControllerMode or Execution, or text like Program.

  • Sample - A numeric valued data item for values that are continuously changing like position, angle, or temperatures

  • ThreeDSample - A sample that represents a three dimensional position like a path position. The path is represented by a three space list or tuple: (1.0, 2.0, 3.0)

  • Condition - A condition is a data item that describes the current normal, fault, or warning state of a component for a certain type of problem. A warning is a situation that may self correct, whereas a fault needs manual intervention. Conditions assume a sweep of a set of error codes where the errors will be checked each time the adapter polls. This is usually how most PLCs operate and there is no specific message to say when an alarm becomes active or clears. If there is an alarm messaging mechanism, use the SimpleCondition. Conditions rely on a native code to distinguish themselves. Other systems can be used, but this is the current assumption of the agent for its condition management.

  • SimpleCondition - Similar to Condition, except that when the alarm is cleared, use the remove method with the code.

Adapter Creation

To create an adapter, import the Adapter from the mtconnect_adapter and add data items. You need to tell it what host and port it should bind to. The default port is 7878:

adapter = Adapter(('0.0.0.0', 7878))
di = Event('event_1')
adapter.add_data_item(di)
adapter.start()

This creates an adapter, adds an Event and then starts the adapter. To change values of the data item, you need to begin gathering data and then complete the data gathering process to send all the data.

adapter.begin_gather()
di.set_value('hello')
adapter.complete_gather()

Working with conditions are very similar to the events:

c1 = SimpleCondition('c1')
adapter.add_data_item(c1)

...

Add a fault

adapter.begin_gather()
c1.add('fault', 'A fault', '123')
adapter.complete_gather()

And to clear the condition:

adapter.begin_gather()
c1.remove('123')
adapter.complete_gather()

There are two additional arguments that are options, qualifier and severity. The qualifier represents extra information like HIGH or LOW and the severity is a native severity if available.

There are more examples in the simple_adapter.py.

ROS Example

There is an example for the ROS turtlesim tutorial that subscribes to the ROS poses and then sends them to the MTConnect agent as PATH_POSITION data items. To run the demo, install the turtlesim and then run the adapter: (this assumes the python_adapter is cloned under ~/)

Install the turtle sim -- see ros wiki...

roscore&
rosrun turtlesim turtlesim_node

There is an example for the ROS turtlesim tutorial that subscribes to the ROS poses and then sends them to the MTConnect agent as PATH_POSITION data items. To run the demo, install the turtlesim and then run the adapter: (this assumes the python_adapter is cloned under ~/)

cd ~/python_adapter/examples
python ros_adapter.py

Next, install the MTConnect agent in another directory:

cd ~
git clone http://github.com/mtconnect/cppagent.git
mkdir agent_build
cd agent_build
cmake ../cppagent
make

Run the agent:

cd ~/python_adapter/examples
~/agent_build/agent/agent debug

Now your done, test the agent:

curl http://localhost:5000/current

You should see an MTConnect streams document with Availabity AVAILABLE and a PathPosition for the Path.

Simulator

The simulator directory contains a ruby script to simulate the functionality of a cnc with minimal information only required for the Robot control. The simulator will process the steps required by the CNC assuming there is a robot that can accept material related requests. The states will be similar to the states in the Bar Feeder project but adapted for to mimic a CNC cell. This technique can be used to simulate other MTConnect related devices as well.

The simulator acts as both an agent and an adapter monitoring an external device and taking actions based on the state and commands. A commandline is also provided to allow for actions to be sent that are not initiated by an external device.

Running CNC Simulator

The CNC simulator requires ruby 1.9.x and the statemachine gem. Install ruby and the type

gem install statemachine

Once you have installed the ruby gem you can use a pre-compiled agent with the agent.cfg file and the BothDevices.xml to represent a CNC and a robot. There is a robot response file which just goes through a series of pre-canned actions and will drive some states on the simulator.

To run the CNC simulator, cd to the simulator directory and start the agent (assuming it is in the same simulator directory):

./agent debug

Next start the CNC simulator:

ruby cnc_simulator.rb

You will need to type the following commands to enable the cnc, the first puts it in automatic mode and the second enables the link:

auto
enable

Next you will need to start the robot sim:

ruby robot.rb

Within five seconds give the following command to the CNC:

run

This process will be made simplier as the CNC becomes more complete. This is the first step to a fully functioning sim.

License

Copyright 2012, System Insights, Inc. All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

External Licenses

We have included the scanner.py module Copyright (c) 2011, Mark Watkinson. Additional licensing and copyright information are in the file: src/scanner.py.

ros_bridge's People

Contributors

jrgnicho avatar shaun-edwards avatar swiedmann avatar

Stargazers

Minas Pantelidakis avatar  avatar James Kirkland avatar Robert Baindourov avatar  avatar Sirius Wu avatar Adam Cook avatar Anthony Oliver avatar

Watchers

James Cloos avatar Arne Wiese avatar  avatar William Sobel avatar  avatar Linh Huynh avatar Cedric Silvester avatar Moneer Helu avatar Nobi Tuna avatar  avatar

ros_bridge's Issues

Doxygen comments are missing from header files

Issue Description:
Doxygen comments are missing from header files. This is OK, as long as you plan to go back and finish up documentation at the end.

Actions to be taken:
This has not been addressed yet but will add Doxygen comments in parallel with development.

MTConnect ROS-Bridge package contains cnc/robot configuration data

The mtconnect_ros_bridge package is meant to be a generic implementation that bridges any mtconnect system with any ros system. This package should only contain generic nodes and configuration files. Several files in the package are specific to either a CNC or a robot.

move utilities.h ,.cpp from mtconnect_cnc_robot_example package into industrial utils

Issue Description:
Your utilities file has methods for parsing cartessian positions out of yaml. I find it hard to believe that this doesn’t exist, already. If it doesn’t and this is something that you think may be reusable, you may consider putting it in industrial_utils: http://code.google.com/p/swri-ros-pkg/source/browse/#svn%2Ftrunk%2Findustrial_experimental%2Findustrial_utils

Actions to be Taken:
Will move to industrial_utils package

MTConnect example stack depends on PR2 object recognition stack

In order to install and build the MTConnect example stack, the PR2 object recognition stack must also be installed. The PR2 stack is very large and really isn't required. The dependency comes from the perception tools package under industrial experimental.

Two very similar cnc_simulator ruby files.

There are two nearly identical cnc_simulator ruby files in the ros_bridge/simulator directory. One of them appears to use port 5001 as opposed to port 5000. Which one is correct. Can we get rid of one? If we do, we will have to update the ros_bridge/mtconnect/mtconnect_ros_bridge/scripts/mtconnect_setup.sh script.

String mismatch in mtconnect_ros_bridge package configuration files

Description:
The bridge_publisher.py node complains about a mismatch when parsing the 'NOT_READY' element in the input configuration file bridge_publisher_config.py. The configuration file contains the string 'NOT READY' without the underscore character. The same string 'NOT READY' was found in the bridge_subscriber_config.yaml file

Observed Behavior:
The following error code was produced by the bridge_publisher.py node:
CONVERSION ERROR IN TOPIC CONFIG FILE: XML is 'NOT_READY' --> CONFIG is ['ACTIVE', 'READY', 'NOT READY', 'UNAVAILABLE', 'COMPLETE']

Temporary Solution Applied:
The white space was replaced by a underscore character in every instance found in both files bridge_publisher_config.yaml and bridge_subscriber_config.yaml. After that change was made the error code above was no longer produced. If this fix impacts other components then it should be reverted and the proper fix should be applied instead, otherwise this issue can be closed.

bridge_publisher.py crashes

The node crashes almost immediately after it has been started. The commands used to start the node are as follows:
'roscd mtconnect_ros_bridge'
'rosrun mtconnect_ros_bridge bridge_publisher.py -i scripts/bridge_publisher_config.yaml'

The error message is:
[INFO] [WallTime: 1360710401.232464] Launching Bridge Publisher -- Publishing Machine Tool Messages
[INFO] [WallTime: 1360710401.418919] Checking for URL availability
[INFO] [WallTime: 1360710401.420950] Connection available
[INFO] [WallTime: 1360710401.472109] Class Instance --> mtconnect_msgs.msg.CncRequest
[INFO] [WallTime: 1360710401.488789] Class Instance --> mtconnect_msgs.msg.CncStatus
Traceback (most recent call last):
File "/home/coky/Desktop/Projects/ROS/MtConnect/ros_bridge/mtconnect/mtconnect_ros_bridge/scripts/bridge_publisher.py", line 340, in
mtc_parse = BridgePublisher()
File "/home/coky/Desktop/Projects/ROS/MtConnect/ros_bridge/mtconnect/mtconnect_ros_bridge/scripts/bridge_publisher.py", line 97, in init
self.setup_topic_data()
File "/home/coky/Desktop/Projects/ROS/MtConnect/ros_bridge/mtconnect/mtconnect_ros_bridge/scripts/bridge_publisher.py", line 176, in setup_topic_data
type_handle = getattr(import_module(namespace + '.msg'), topic_type_name)
AttributeError: 'module' object has no attribute 'CncStatus'

It seems that the node attempts to produce an instance of the 'CncStatus' message type which no longer exists under mtconnect_msgs. A reference to this old message type is also found in the configuration file bridge_publisher_config.yaml

Move mtconnect_arm_navigation and mtconnect_cnc_robot_example to a new stack

Issue Description:
Move mtconnect_arm_navigation and mtconnect_cnc_robot_example to a new stack (mtconnect_example). Originally we wanted to include these in the mtconnect stack, but now that there are multiple packages, we probably want them to be separate. This will enable us to keep a single mtconnect stack that is clean and doesn’t include any extra packages that aren’t needed. I’ll leave it up to you to decide which code is general purpose and what is specific to the fanuc and cnc (note, some of your move arm libraries may fall into the general purpose category).

Actions to be taken:
Created the mtconnect_example stack and will move the corresponding packages there.

Pull out convenience functions out of MoveArmActionClient into their own class

Issue Description:
This doesn’t have to be done now, but I think it may just happen in the future. Your MoveArmActionClient currently does three things, it has convenience functions that wrap move arm calls, it loads some Cartesian waypoints, and it spins a ros node. I think the first wrapper part is generally useful, given that the move arm action server can’t figure out tf, so there may be an opportunity to pull this functionality out into a separate class.

Actions to be taken:
Will identify functions that are generic (and useful) enough to be wrapped into their own separate class/classes.
Will add this class to industrial utils or any other ros industrial package where it makes sense.

Robot Home motion does not avoid collisions

The robot home motion does not avoid collisions with the CNC collisions models. When the robot is stopped inside of the CNC and the state machine is restarted, the robot homes itself. The homing motion moves right through the CNC. Steps to reproduce:

  1. Using a real robot execute the demo until the robot is inside the CNC
  2. Hit control C to bring down the demo.
  3. Bring the demo back up.
  4. The robot will try to home as the first motion.

bridge_server.py node hangs after recieving cnc action call

Description:
bridge_server.py hangs inside its 'execute_cb' callback method after receiving a cnc action client call. As a result the call produces a timeout error on the client side (state machine node).

Observed behaviour:
-the last messaged printed by the bridge_server.py node is the following:

In OpenDoor Callback -- determining action request result.

-Simultaneously, The cnc simulator produces the following output:

Cnc::OpenDoor Active - Cnc::CloseDoor READY
D, [2013-02-13T16:44:07.682044 #7826] DEBUG -- send_to_client: Sending 2013-02-13T22:44:07.681916Z|open_door|ACTIVE
to #<TCPSocket:fd 5>
(Cnc::OpenDoor) Event: complete
(Cnc::OpenDoor) exiting 'active' state
(Cnc::OpenDoor) entering 'complete' state
Completed
D, [2013-02-13T16:44:07.682667 #7826] DEBUG -- send_to_client: Sending 2013-02-13T22:44:07.682587Z|open_door|COMPLETE
to #<TCPSocket:fd 5>
CNC Received MaterialLoad FAILED
Received MaterialLoad FAILED
Trying method: robot_material_load= FAILED
Trying action: robot_material_load_failed
(CNC) Event: robot_material_load_failed

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.