New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

machinekit lacks ROS integration capability #689

Closed
mhaberler opened this Issue Jun 17, 2015 · 197 comments

Comments

Projects
None yet
@mhaberler
Member

mhaberler commented Jun 17, 2015

machinekit would make a great realtime playout/device control layer for ROS. ROS could become an alternative driving layer, in parallel to the existing CNC control application (rs274 interpreter, task, motion).

What I think is needed is a way to either plug in natively into ROS, or use one of the bridge approaches outlined here (taken from the talk by Arne Hamann/Bosch talk at i-ROS Stuttgart 06-09-2105):

image

The options for the interfacing strategy I currently see are:

  • if nothing else, we can do rosbridge/JSON/websockets - we have the moving parts in place but I think 'native' is the way to go longer term. So I would prefer either
  • rosc - a bit early and shaky, but native, ROS 1.0, or
  • ros2 DDS interaction - no client library but then we have a full linux environment on-target.
  • any other options we could go for? possibly tinq which seems to be used by Erlerobotics (see here)

I guess rosserial is out of scope. I have currently no idea what the ros1/ros2 cutover timeline is.

For reference, this is where we are with machinetalk:

image

possible locations to plug ROS into machinetalk:

  • haltalk, the scalar/message API daemon into HAL (eg for rosc)
  • or in front of the zeromq/protobuf stack
  • or in front of the websockets/JSON translator (for rosbridge).

I have no preferences at this point but layering middlewares ontop of each other is a recipe for issues.

Some background links:

the ros1->ros2 transition
The rosc interfacing library by Synapticon
the ros1 message format and here

the agenda of the ROS-industrial event Jun 9, 2015 - Fraunhofer IPA, Stuttgart

(this issue intended as anchor issue for ROS integration)

@mhaberler mhaberler added the problem label Jun 17, 2015

@luminize

This comment has been minimized.

Member

luminize commented Jun 17, 2015

While we're at it we might think about using Gazebo as a simulator for Machinekit. If we "talk" to ROS then I'm guessing we can also "talk" to Gazebo

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 17, 2015

@mhaberler: for the native category, have you considered using cros? I think the use-cases driving its design are close to what you have in mind. Main site and the ROS news announcement.

Another alternative not in your OP could be simple_message. Not native -- so it would fit in the bridge category -- and perhaps not as full featured, but used in almost all ROS-Industrial robot drivers.

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 17, 2015

@gavanderhoorn - hi ! and thanks for the hint to cros, this looks in fact like a viable option technically

unfortunately, due to legal incompatibility (box col1 row 3) between GPL2 and (L)GPL3 we are unable to consider this option (and with us, just about every other GPL2(+) project for that matter).

The only realistic option to consider this if it-robotics came around and changed licensing to (L)GPL(+) or a more liberal license like MIT or BSD. Given the number of copyright owners on LinuxCNC and machinekit, and the fact that some are deceased, it is impossible to follow the FSF recommendation to relicense the whole project as GPL3, and it would be undesirable for other reasons.

We had many such license clashes in the past and it is a bloody nuisance. Often licensors are not fully aware of the implications of their choice with respect to legal and hence economic consequences (it is safe to say this situation is a complete adoption killer). In some cases we managed to get stacks or libraries relicensed after some explaining. In all other cases we did not pursue any further.

Do you have any contacts with it-robotics which we could work?

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 17, 2015

Hm, I'd not considered the licensing issue. I'm happy most pkgs in ROS are BSD, which makes things a lot easier.

As to cros: the readme states:

Licensing

cROS is licensed under the GNU Lesser General Public License v3.0. For more licensing options and for paid support please write an email to cros@it-robotics.it.

So it might be an idea to contact them and see if things can be worked out.

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 17, 2015

@gavanderhoorn - the simple_message scheme indeed seems to be a good start for trajectory playout, and that is likely a common use case.

If I understand this right, this could handle pre-planned trajectories at the joint position level assuming isochronous samples (type 1 message), and a more general arbitrary joint segment list of arbitrary segment duration (type 2).

it might well be that we wind up with several specialized API's and over time learn to do this in a more general way.

This looks like a great start, thanks!

If I may add an idiot question:

  • let's assume machinekit drives a robot of some kind and exposes the input side with simple_message. So far so clear - that's the command side.
  • what about the status reporting side (eg current position)? that would be a separate publisher cyclically or on-change update a joint position?
@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 17, 2015

If I understand this right, this could handle pre-planned trajectories at the joint position level assuming isochronous samples (type 1 message), and a more general arbitrary joint segment list of arbitrary segment duration (type 2).

I'm not quite sure to which 'type 1' and 'type 2' messages you are referring, but using REP-I0004:

  • JOINT_TRAJ_PT msgs are used to stream individual points of a joint space trajectory (so ROS->controller)
  • JOINT_POSITION or JOINT_FEEDBACK(_EX) msgs (with a preference for the latter) are used to encode current state (controller->ROS)
  • STATUS is used to broadcast 'robot status' (ie: in_motion, in_error, etc).

If I may add an idiot question:

  • let's assume machinekit drives a robot of some kind and exposes the input side with simple_message. So far so clear - that's the command side.
  • what about the status reporting side (eg current position)? that would be a separate publisher cyclically or on-change update a joint position?

See my comment above, but to clarify: all current implementations use cyclic publications.

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 17, 2015

@gavanderhoorn - get it now, thanks.

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 17, 2015

Additional comment: to implement support for new robots/controllers, you typically only need to implement the 'server side'. The client side (bridging ROS msgs to the controller) is taken care of by the industrial_robot_client.

@luminize

This comment has been minimized.

Member

luminize commented Jun 18, 2015

since Machinekit is mainly on debian the link above might be of interest.

I've just finished an installation of ROS on my debian Jessie VM as per:
https://wiki.debian.org/DebianScience/Robotics/ROS

when there are download errord like

ERROR [vcstools] Tarball download unpack failed: <urlopen error [Errno -2] Name or service not known>[/vcstools]

during the step

wstool init -j8 src indigo-desktop-full-wet.rosinstall

then do wstool update -j 4 -t src as described here http://wiki.ros.org/jade/Installation/Source#Installation

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 19, 2015

@luminize - do I get this right this repo is amd64 only, no packages for i386? if so - here comes the next VM ;)

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 19, 2015

@mhaberler: building from source is also an option and (on a relatively modern PC) shouldn't take too long.

@luminize

This comment has been minimized.

Member

luminize commented Jun 19, 2015

@mhaberler I have no way of seeing. I've put the question on the Gazebo list (where I got pointed to the debian repo) here https://groups.google.com/a/osrfoundation.org/forum/#!topic/gazebo/YcXCRYqkcGs i'll keep you updated

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 19, 2015

@gavanderhoorn - eventually I will - after having immersed in the out-of-box experience ;)

@ArcEye

This comment has been minimized.

ArcEye commented Jun 19, 2015

@luminize "I've just finished an installation of ROS on my debian Jessie VM "

Be very careful to only try installing the Jessie Virtualbox packages on a stock Jessie kernel.

I found to my cost that at some point they are hard coded against 3.16.0-4-amd64 and in other places use ${uname -r}so the wrong things get built against
This will result in a failure and lock up during the DKMS build and an unbootable kernel, because initrd-img has been screwed.

Thankfully I have several kernels on that partition so was able to boot another one, but still had all sorts of fun and games getting packaging sorted, because dpkg --configure -a just tries to build the modules again unless you manually delete everything, so that it fails and then use apt-get to 'delete' them and clear the package logs.

Wasn't very keen on VM's on Monday morning when all this occurred ;)

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 19, 2015

Instead of a full VM, I've had good success running things from a chroot (see wiki/ROS/Tutorials/InstallingIndigoInChroot for some info. Replace Indigo with any release obviously), or even docker (see wiki/docker).

@zultron

This comment has been minimized.

zultron commented Jun 20, 2015

The link to Dr. Hamann's slides is broken. Are those available somewhere?

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 20, 2015

@zultron fixed

@zultron

This comment has been minimized.

zultron commented Jun 20, 2015

When I was exploring this almost a year ago, I didn't find nearly such an abundance of possibilities. Nice research!

At the time, I had settled on ros_control 1. That project benefits from having the same API as the PR2 controller. Many existing ROS robots use that API, probably against customized versions of the PR2 controller code, and notably Baxter uses ros_control, so real investment there. It also works with ROS-i's 'MoveIt!', so it would plug right into industrial robot arm ROS-i stacks.

In the diagram on that page, Machinekit joints would be exposed through a Machinekit controller interface, a subclass of any of the joint_{trajectory,position,velocity} classes. I envisioned the controller manager setting up a new Machinekit controller, which would interface to a local or remote Machinekit instance through Machinetalk or HALtalk, as appropriate.

The controller architecture seems to have clear parallels in the Machinetalk architecture. Except for the actual joint_trajectory etc. ROS interfaces, the right-hand side of that diagram looks pretty much done by Machinekit.


Michael's question of where it connects to Machinekit is still unanswered in this ros_control picture. The controller inputs to a ros_control controller are commonly joint positions or velocities (see full list on ROS wiki), so TP and kins have already been done. In the above diagram, controller inputs would most directly correspond to the AXIS N boxes inside the EMCMOT box, expanded further down in the 'Code Notes' 2:

Joint Controller Block Diagram

@mhaberler points out this division within the motion component in off-list correspondence:

  • motion has an "upper half" preparing segments, handling blending etc (command.c calling upon emc/tp/*), and a "lower half" (control.c) which interpolates along segments.

My best idea a year ago was to copy and paste the 'lower half', joint/axis controller code from motion into a new, separate joint component with ring buffers between it and user space. Referring back to the ros_control diagram, the hardware_interface::Machinekit class would simply pass input joint commands with minimal modification through the ring buffer to this joint comp, which would pass joint states back out through a separate ring buffer back to hardware_interface::Machinekit.

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 20, 2015

@zultron - my take on this legacy drawings is: we should forget about that and turn the page.

There is a ton of convoluted crap there, and I think trying to force the ROS tp playout use case through using motion again is going to lead nowhere. I think we should leave motion stand where it is for the CNC use case and be done with it.

For trajectory playout we can assume offline planning which hugely simplifies things. The way Bas and myself have envisaged this is through the (as of yet unmerged) halpipes branch which will enable components to connect through ringbuffers and strongly typed messages, just as like pins.

It boils down to resurrecting some parts of motion and placing them into separate comps with such a pipe API. And those would be very simple in function: kins, interpolate, sample segments at servo rate, maybe blend, limit vel/acc/jerk. instantiate, connect through ringbuffers, run like a shell pipe arrangement.

And: most of this will be done in userland. The legacy architecture does way too much in RT, simply because they never thought through the best design for the problem at hand - which is why there is like 90% of the motion code in a place where it doesnt belong. And motion doesnt even have a documented API about what, 20 years after they designed it?

The industrial_robot_client is a good example what all can be done in userland in this context.

@zultron

This comment has been minimized.

zultron commented Jun 20, 2015

I was also proposing to leave motion as is, and crib the joint controller code into a new comp, only those small parts needed. Just like you say? In the interface I point to, kins should have already been done on the ROS side, since input data is in joint-space coords/waypoints. (This is also true of simple_message that @gavanderhoorn points to.) Not sure whether vel/acc/jerk limits should be left to ROS's offline planning, also. Again, see the second diagram in my previous post.

It sounds like 'halpipes' would be perfect for this or any other interface we eventually go with. Nice work!

Glad to have as much as possible out of RT, and motion out of the way!

As for Baxter, that's a very complete, if also overwhelming, example of a robot interface (like I said, there's VC funding behind it ;). It not only implements a ros_control interface, but also has a gazebo interface for @luminize. It would be supremely cool to have a simulated robot connected to a 'sim' Machinekit instance with simultaneous display of the 3D robot in gazebo and a halscope window next to it!

@luminize

This comment has been minimized.

Member

luminize commented Jun 20, 2015

I think that machinekit has a unique position in the scheme of things.
Machinekit can fulfil the bridge between use cases where RT is needed (like balancing, flight, high path accuracy etc) where a quick reaction time and stability of the calculations is needed.

The use cases I see:

  • configurable "firmware". Not as dumb as uC's, but very flexible in brewing unique layouts of hardware and sensor. Thus a command "go to (x,y,z)" by a ROS message can result in a movement to a certain position by MK kinematics. Of course this command could also be a pose (joints) thus no use kinematics.
  • translating physical hardware to messages. Nothing more, nothing less. Interpreting of the messages can be done by ROS.

For other things like robots that interact with humans, collision detection etc,where a lot of external events happen (humans) this is way more difficult to compute, and I don't see a need for RT for that, because via CANOpen in ROS the "slow" motion is fast enough for most cases.

Did I forget anything of make a wrong assumption?

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jun 27, 2015

@gavanderhoorn - let's talk message type ID's for a moment: I'm perusing https://github.com/ros-industrial/rep/blob/master/rep-I0004.rst#standard-messages and see you're establishing a type registry for ROS messages - which makes a lot of sense

this seems to assume a 32bit space for message type id's. Do you think this space could be reduced to say 16bits or maybe a bit more, but less than 24? Realistically much of this space will remain unused anyway, so it boils down to a change of the assignment procedure

you have

 65536-2147483647  -                            Reserved for future use

meaning the end of the space is currently at 0x7ffffff

reason why I'm asking: we have the means to transport a 32bit tag with each message all the way from say UI's/driving code through ringbuffers into RT space and back; I am hesitant to enlarge the size of this tag as it would be a quite invasive change, alignment issues come into play, and it'd be in the most time critical path of the code; using an extension bit to signify a larger tag does not help because the API is currently able to handle only 32bits

The current disposition of this type tag is as follows:

typedef enum {
    MF_STRING         =  0,    // payload is a printable string
    MF_PROTOBUF       =  1,    // payload is in protobuf wire format
    MF_NPB_CSTRUCT    =  2,    // payload is in nanopb C struct format
    MF_JSON           =  3,    // payload is a JSON object (string)
    MF_GPB_TEXTFORMAT =  4,    // payload is google::protobuf::TextFormat (string)
    MF_XML            =  5,    // payload is XML format (string)
    MF_LEGACY_MOTCMD  =  6,    // motion command C structs, with cmd_code_t type tag
    MF_LEGACY_MOTSTAT =  7,    // motion status C structs, with cmd_status_t type tag
    MF_BLOB =  8,              // payload is an opaque blob

    // add here as needed and change the #define to point to the last encoding
    // used in the base code
#define MF_LAST  MF_BLOB
    MF_UNUSED1        =  9,    // unused in code base  - user extensions
    MF_UNUSED2        =  10,    //
    // ...
} mf_encoding_t;

typedef struct {
    __u32 msgid     : 12; // must hold all proto msgid values (!)
    __u32 format    : 4;  // an mf_encoding_t - how to interpret the message
    __u32 more      : 1;  // zeroMQ marker for multiframe messages
    __u32 eor       : 1;  // zeroMQ marker end-of-route, next frame is payload
                          // zeroMQ route tags are marked by msgid == MSGID_HOP
    __u32 unused    : 14; // spare
} mfields_t;

To encompass ROS message id's into this scheme, we could:

  • extend the msgid range from 12 to whatever is the maximum ROS message type ID needs, by reassigning spare bits
  • include a typespace tag (machinetalk=0, ROS=1 etc) so the typespace/msgid tuple would be unique
  • define an encoding_t enum MF_ROS_SERIAL to cover the ROS serial wire format

with this reduced type ID range machinetalk would perfectly be able to transport and runtime-identify ROS serial messages, which would ease integration a lot!

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 27, 2015

If I understand you correctly you'd like to use the ROS-I assigned ID as an identifier in your own messaging system, and inject ROS-I msgs 1-on-1 into that?

We typically only use Simple Message between the ROS client nodes and the server parts running on the controller. Server programs mostly translate the contents into some internal representation, independent of the original msg. MachineKit seems to be a bit special: it uses an internal communication system that could potentially accommodate the actual Simple Message structures and is completely 'under our control' (with that I mean that you have complete control over the internals of the system, not something that we typically see in ROS-Industrial).

If I understood you correctly, I'd suggest creating a MF_ROS_INDUSTRIAL encoding id, and then encapsulating the entire ros-i msg (so header+payload) in a 'machine kit msg' (forgive me: I'm not too familiar with the terminology here). The IDs and msg contents are completely ROS-I specific, so I would even suggest translating msg contents into MachineKit-specific (but corresponding) msgs, which would completely avoid the issue afaics.

A bit of rationale for the msg_type field: a lot of industrial (robot) controllers have a very limited type system (only a single int type fi, with a fixed size and always signed), which we had to accommodate for. Hence the 32bit ID field (of which only the positive side is used). Restricting the ID space would then be a convention only, as we cannot change the size of the field itself.

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Jun 27, 2015

@gavanderhoorn wrote:

[..] The IDs and msg contents are completely ROS-I specific, [..]

To clarify: Simple Message isn't like rosserial in that it is a wire format for which we could write / generate automated (de)serialisation infrastructure. Similar to rosserial, we obviously must convert ROS msgs into a bytestream. Unlike rosserial, that is not a 1-to-1 conversion: fields are left out, added or changed (the duration/velocity fields in JOINT_TRAJ_PT fi: those don't exist in trajectory_msgs/JointTrajectoryPoint), and we only support a very limited subset of all the ROS msgs that are in existence.

@mhaberler

This comment has been minimized.

Member

mhaberler commented Jul 2, 2015

@gavanderhoorn - yes, it is about transporting ROS messages in the machinetalk transport, and have them runtime type/encoding tagged so they coexist peacefully with existing native messages

I might have jumped to conclusions too early wrt the applicable ROS message formats, and how we might come up with the most general way of interfacing machinekit to ROS

looking at it again your suggestion to tag the whole class of ROS messages with an encoding tag, instead of trying to merge the message ID spaces without collisions makes a lot of sense (and is more general anyway)

so that means: a ROS-message-wrapped-in-machinetalk container. Fine with me. Translating into native is another exercise I'm not sure makes sense. What I could think of (far out) is the following: translate the msg format descriptors into .proto (similar like what is happening with the msg->DDS IDL transition), and write an encoder/decoder which uses protobuf introspection but generates/parses msg wireformat. That is something which for instance has been done with the goby project and would open a second route for ROS to migrate to protobuf in case the ROS2/DDS effort goes nowhere (which I rate has a certain chance of happening)

In terms of message type universes - I guess we should look at the range of messages used by rosserial then?

@luminize

This comment has been minimized.

Member

luminize commented Oct 9, 2015

this might be an interesting announcement for this issue (since we are Debian minded). Running ROS and Machinekit from the same box doesn't seem strange to me at least:
https://lists.debian.org/debian-science/2015/10/msg00024.html

@cdsteinkuehler

This comment has been minimized.

cdsteinkuehler commented Dec 11, 2015

I am beginning to look seriously at adding ROS support to talk to Machinekit's HAL layer. There are many possible ways this can be done, but my initial thought is to craft a ROS package that receives and transmits appropriate ROS messages, tying the contents more or less directly into HAL (perhaps with a component similar to the existing motion if needed to handle the real-time side of path planning and closing feedback loops). As I have very little experience with ROS, I would appreciate if anyone who does have some experience weighs in on the following questions:

  • Should the Machinekit/ROS real-time code run on the same machine as
    the "main" ROS controller, or would it be better to have two systems
    (presumably communicating via Ethernet?)?
  • Should I try to write the "glue" code for ROS messaging in Python or
    C++ ? Both are easily possible and can directly talk to HAL, virtually
    any language is an option if communicating to HAL via protobuf messages.
  • When I look at "Supported Hardware" on the ROS-i wiki:
    http://wiki.ros.org/Industrial/supported_hardware
    there are several communications formats listed (position streaming,
    trajectory download, etc). What would be the preferred method to
    implement first?
  • Which release of ROS-i should I begin working with? Are there any
    "official" (or recommended) pre-built images or virtual machines available?
  • Do you think a fully x86 based system (likely using a Mesanet FPGA
    card for machine I/O) would be a better starting platform, or something
    like the BeagleBone Black would make a better "first example"? This
    relates somewhat to the first question (one or two systems), since I'm
    not sure how well the "Desktop-Full" target would run on a 'Bone (it
    seems like it could be a bit under-powered).
@evanmj

This comment has been minimized.

evanmj commented Dec 11, 2015

I wish I could help more, but I'm not into these sorts of details of ROS-I just yet... I'm very interested in what this bridge could do for the open robotics / machine control community.

The ROS-I training course materials are available online here.

The training VM is availalbe with setup instructions here. Using this VM should save you many hours of install time and configuration.

It might be worth looking at ros_control as well, as I think machinekit could sit well in the "Real Robot" section of their data flow flowchart.

If you get stuck, hit up @shaun-edwards, he is very helpful.

@luminize

This comment has been minimized.

Member

luminize commented Feb 27, 2016

I have just finished the installation as per instructions above on a x86_64 VM and in addition to #689 (comment) I had to add 2 more packages: sudo apt-get install libbz2-dev libfltk1.3-dev

@gavanderhoorn @shaun-edwards the debian packages installs the jade distro. How do the ros-i packages fit into that situation? Can I mix these packages in the jade setup? or do they need work for that situation?

@mhaberler

This comment has been minimized.

Member

mhaberler commented Feb 28, 2016

@luminize - interesting, remember which packages required libbz2-dev libfltk1.3-dev? any logs? I'd think @lepalom would be interested

I would think the i-ros packages require a catkin build (maybe go from the procedure from above with catkin_make_isolated --install)

@luminize

This comment has been minimized.

Member

luminize commented Feb 28, 2016

On 28 Feb 2016, at 09:15, Michael Haberler notifications@github.com wrote:

@luminize - interesting, remember which packages required libbz2-dev libfltk1.3-dev? any logs? I'd think @lepalom would be interested

Hi Michael, yes i logged the terminal. These 2 were the culprits.

http://pastebin.com/CW850mzx for libbz2-dev in package pcl_ros

https://pastebin.com/NCfMx2gM for libfltk1.3-dev in package stage

I informed Leopold and Jochen, they're aware.

I would think the i-ros packages require a catkin build (maybe go from the procedure from above with catkin_make_isolated --install)

Yes i would next week try to build the industrial packages from the catkin workspace. I built the listener2 without problems. But before i embark on a side project (industrial indigo packages on jade) i need to have an inkling on how much of a chore it would be, and if it is(n't) a waste of time. In other words, do industrial packages for jade have value for others than me. I cannot afford to get sidetracked too much ;)

@mhaberler

This comment has been minimized.

Member

mhaberler commented Feb 28, 2016

hm, it looks industrial_core is release on jade: http://wiki.ros.org/industrial_core

@luminize

This comment has been minimized.

Member

luminize commented Feb 28, 2016

On 28 Feb 2016, at 12:03, Michael Haberler notifications@github.com wrote:

hm, it looks industrial_core is release on jade: http://wiki.ros.org/industrial_core

How about that... I was checking various packages but seem to have completely missed the most important one.
Going to give it a go.

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Feb 28, 2016

@luminize wrote:

@gavanderhoorn @shaun-edwards the debian packages installs the jade distro. How do the ros-i packages fit into that situation? Can I mix these packages in the jade setup? or do they need work for that situation?

Only industrial_core has been released into Jade (but I'd expect it to only be available on the shadow repository, as it hasn't been synced yet). The rest will probably build from source.

Note that Jade is not an LTS, so things may not be as stable as Indigo.

@mhaberler

This comment has been minimized.

Member

mhaberler commented Feb 28, 2016

well @lepalom's stream just happened to be jade
that said - the point for debian packages on arm was to create embedded devices with the ROS Comms stack so they can tie into some other instance of ROS (which likely will not be running debian but ubuntu) - pretty much as intelligent playout devices

if that is the target scenario then the question becomes - where is a sensible dividing line? IOW: does any of the ros-industrial stuff you are referring to actually have to run on an embedded device?

if the target scenario is "everything runs on a PC" then it's not an issue to start with - a source build of machinekit on Ubuntu works anyway

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Feb 28, 2016

@mhaberler wrote:

if that is the target scenario then the question becomes - where is a sensible dividing line? IOW: does any of the ros-industrial stuff you are referring to actually have to run on an embedded device?

This obviously depends on what other functionality of ROS you'd like to use on your embedded system, but as long as you have something that exposes the required Action server(s), topics & services, then you don't need any of the industrial_core packages (save industrial_msgs perhaps).

well @lepalom's stream just happened to be jade

That's fine, but do know that message compatibility is not guaranteed between ROS releases (ie: messages may change between ROS_n and ROS_n+1). It'll probably work for Indigo & Jade, but that may break at any time.

@luminize

This comment has been minimized.

Member

luminize commented Feb 28, 2016

I just gave industrial_core a try, building the setup I now have on Ubuntu on Debian Jessie, with the packages from DebianScience (jade).
I had to add these packages: sudo apt-get install libfcl-dev libglew-dev libyaml-cpp-devand the ros packages up to this point (wherematilda_*andlistener2` are the ones I did):

bas@debian-ros:~/catkin_ws$ ls src
CMakeLists.txt                   manipulation_msgs      object_recognition_msgs
control_msgs                     matilda_moveit_config  octomap_msgs
household_objects_database       matilda_support        sql_database
household_objects_database_msgs  moveit_core            srdfdom
industrial_core                  moveit_msgs            urdfdom_py-release
listener2                        moveit_ros

I ran into an issue with building standard_msgs but have solved this as per ros-industrial/industrial_core#46 and building with catkin_make_isolated

I now run into an error with the package moveit_ros_manipulation where although the manipulation_msgs are built (I previously ran into the same message, and downloaded the source from https://github.com/ros-interactive-manipulation/manipulation_msgs)

but looking into the date of the last commit for hydro on april 2013 looks like this is not a really up-to-date solution.

Maybe this is a problem because of me running catkin_make_isolated

==> Processing catkin package: 'moveit_ros_manipulation'
==> Building with env: '/home/bas/catkin_ws/devel_isolated/moveit_ros_move_group/env.sh'
Makefile exists, skipping explicit cmake invocation...
==> make cmake_check_build_system in '/home/bas/catkin_ws/build_isolated/moveit_ros_manipulation'
==> make -j4 -l4 in '/home/bas/catkin_ws/build_isolated/moveit_ros_manipulation'
[ 10%] Built target moveit_ros_manipulation_gencfg
[ 90%] Built target moveit_pick_place_planner
[100%] Building CXX object move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/src/pick_place_action_capability.cpp.o
/home/bas/catkin_ws/src/moveit_ros/manipulation/move_group_pick_place_capability/src/pick_place_action_capability.cpp:42:45: fatal error: manipulation_msgs/GraspPlanning.h: No such file or directory
 #include <manipulation_msgs/GraspPlanning.h>
                                             ^
compilation terminated.
move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/build.make:54: recipe for target 'move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/src/pick_place_action_capability.cpp.o' failed
make[2]: *** [move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/src/pick_place_action_capability.cpp.o] Error 1
CMakeFiles/Makefile2:2036: recipe for target 'move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/all' failed
make[1]: *** [move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
<== Failed to process package 'moveit_ros_manipulation': 
  Command '['/home/bas/catkin_ws/devel_isolated/moveit_ros_move_group/env.sh', 'make', '-j4', '-l4']' returned non-zero exit status 2

Reproduce this error by running:
==> cd /home/bas/catkin_ws/build_isolated/moveit_ros_manipulation && /home/bas/catkin_ws/devel_isolated/moveit_ros_move_group/env.sh make -j4 -l4

Command failed, exiting.

where cd /home/bas/catkin_ws/build_isolated/moveit_ros_manipulation && /home/bas/catkin_ws/devel_isolated/moveit_ros_move_group/env.sh make -j4 -l4 yields:

bas@debian-ros:~/catkin_ws$ cd /home/bas/catkin_ws/build_isolated/moveit_ros_manipulation && /home/bas/catkin_ws/devel_isolated/moveit_ros_move_group/env.sh make -j4 -l4
[ 10%] Built target moveit_ros_manipulation_gencfg
[ 90%] Built target moveit_pick_place_planner
[100%] Building CXX object move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/src/pick_place_action_capability.cpp.o
/home/bas/catkin_ws/src/moveit_ros/manipulation/move_group_pick_place_capability/src/pick_place_action_capability.cpp:42:45: fatal error: manipulation_msgs/GraspPlanning.h: No such file or directory
 #include <manipulation_msgs/GraspPlanning.h>
                                             ^
compilation terminated.
move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/build.make:54: recipe for target 'move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/src/pick_place_action_capability.cpp.o' failed
make[2]: *** [move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/src/pick_place_action_capability.cpp.o] Error 1
CMakeFiles/Makefile2:2284: recipe for target 'move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/all' failed
make[1]: *** [move_group_pick_place_capability/CMakeFiles/moveit_move_group_pick_place_capability.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
@luminize

This comment has been minimized.

Member

luminize commented Feb 28, 2016

@gavanderhoorn could you explain to me in layman terms what/if ros_control brings as "preferred" solution? This w.r.t. reading and writing data to/from Machinekit. Taken into account that Machinekit is your configurable hardware not-only-joints highly configurable connection to the outside world.

TL;DR
I'm not understanding the 1+1=3 benefit if I look at ros_control and reading/writing to/from Machinekit. Is a general setup one-size-fits-all feasible? Or does everybody still need to write the controller for their Machinekit configuration?

I looked into the video and wiki of ros_control, and what I understand is that the orange box at http://wiki.ros.org/ros_control and at 9:20 in https://vimeo.com/107507546 is where the interface should be (with the same method of putting filling the ringbuffer as we do now). Reading and writing.

Ros_control brings things like the startup minimal state engine, which can set the controllers to correct values, also having sane values after resuming of an e-stop for example (14:57). Limiting ros controller values (25:45), A joint_trajectory_controller etc. Re-use of code but because there is no such thing as a "standard" machinekit configuration should not every machinekit configuration that's translated into a ros_control hardware controller be specifically coded for that configuration?

There's this mention on the wiki page of "ros_control gets more complicated for physical mechanisms that do not have one-to-one mappings of joint positions, efforts, etc but these scenarios are accounted for using transmissions". That's similar to the stepgen scaling we can do in Machinekit. Right now I pass the unmodified angles (in radians) to Machinekit, where Machinekit take care that the scaling (microstepping and gearbox transmissions) is correct for my setup. Plus the stepgen is limited to a user defined max velocity and max acceleration (overlap with ros_control).

If we look at the capabilities of Machinekit, with not only driving motors and generating feedback on that, but also the ability to set outputs and read digital and analog inputs for example, and the reading and showing of other values of peripherals like a 3D mouse (HID hardware), how does this fit?

Do we end up with ros_control + another package which handles the events that can't be controlled like setting of physical inputs for example (act as a gateway of a hardware mouse value or user pressing a button?)

@gavanderhoorn

This comment has been minimized.

gavanderhoorn commented Feb 29, 2016

@luminize: in short: ros_control is about abstraction of access to (controllable) resources, and the associated advantages you get from being able to reuse other components. It's not only about controlling robots in jointspace.

Is a general setup one-size-fits-all feasible? Or does everybody still need to write the controller for their Machinekit configuration?

[..] should not every machinekit configuration that's translated into a ros_control hardware controller be specifically coded for that configuration?

Yes, a generic hw interface should be possible (or at least I believe it is), no need to write code for every individual configuration. If not from the URDF, it should be possible to write your HW iface in such a way that it gets the info from either your .hal file, or from some other kind of easily editable file. As long as the appropriate resources are exposed to the layers above the hw iface, things should work as expected. It's very much possible to create the appropriate resource representations at runtime, and the generation / instantiation could be driven by a simple configuration.

[..] where the interface should be (with the same method of putting filling the ringbuffer as we do now). Reading and writing.

Not exactly (re: the same method): ros_control is fully capable of running in a hard real-time context, which should make it possible to integrate your hw iface implementation much better with the rest of your machinekit application.

[..] Re-use of code but, [..]

A lot of code-reuse, especially on the ROS-interfacing side. And the JointTrajectoryController fi supports action interfaces with all the correct semantics and behaviour (dynamic trajectory replacement, etc).

If we look at the capabilities of Machinekit, with not only driving motors and generating feedback on that, but also the ability to set outputs and read digital and analog inputs for example, and the reading and showing of other values of peripherals like a 3D mouse (HID hardware), how does this fit?

Do we end up with ros_control + another package which handles the events that can't be controlled like setting of physical inputs for example (act as a gateway of a hardware mouse value or user pressing a button?)

Although the naming becomes a bit awkward, the abstractions in ros_control are not limited to things that can be controlled with PID-controllers: see the force_torque_sensor_controller and the imu_sensor_controller fi. Basically anything for which the interaction can be modelled by a read()/write() pair (polling) should be possible. So that would include the 3d mouse example and the IO.

There will be some work involved in getting this working smoothly with machinekit, but I believe the abstraction allowed for by ros_control - and the resulting reuse opportunities - would offset this.

There's this mention on the wiki page of "ros_control gets more complicated for physical mechanisms that do not have one-to-one mappings of joint positions, efforts, etc but these scenarios are accounted for using transmissions". That's similar to the stepgen scaling we can do in Machinekit.

The comment on the wiki is actually more about things like underactuated mechanisms and having multiple concurrent interfaces to the same joint (ie: position and stiffness fi) than scaling alone.

Do we end up with ros_control + another package which handles the events that can't be controlled like setting of physical inputs for example (act as a gateway of a hardware mouse value or user pressing a button?)

No. See earlier comment about encapsulating access to those kind of resources in the appropriate ros_control plugins.

@luminize

This comment has been minimized.

Member

luminize commented Feb 29, 2016

@gavanderhoorn thanks for de-murkifying.

@yishinli

This comment has been minimized.

yishinli commented Mar 5, 2016

I use Descartes to convert way points to joint positions, and save those in G-code for Machinekit. Also, I modified the emccanon.cc, tp.c, and tc.c for synchronized joints motion. Here's the G-code snippet:

G1 X52.11885 Y-73.20373 Z-74.47628 A180.00000 B32.31998 C52.09593
G1 X52.11267 Y-73.19468 Z-74.49908 A180.00000 B32.30624 C52.08975
G1 X52.10650 Y-73.18563 Z-74.52187 A180.00000 B32.29250 C52.08358
G1 X52.10032 Y-73.17658 Z-74.54465 A180.00000 B32.27877 C52.07740

Here's the videos: cycle time testing, trajectory testing

The trajectory is not accurate at this moment. I might not use Descartes or implement the synchronized motion in a wrong way.

@gavanderhoorn - How was your experience regarding trajectory accuracy with Descartes and the other robot controllers?

@shaun-edwards

This comment has been minimized.

shaun-edwards commented Mar 8, 2016

The videos look impressive. I haven't done any detailed testing, but I
suspect we would see similar levels of accuracy in an industrial robot.
The source of error is twofold. The first is just kinematic differences
between the ROS kinematics and the robot geometry. The second is due to
the interpolation that the robot makes between Descartes waypoints.
Interpolation errors can be addressed by increasing waypoint density, but
this can slow down the Descartes planning.

On Fri, Mar 4, 2016 at 8:55 PM Yishin Li notifications@github.com wrote:

I use Descartes http://wiki.ros.org/descartes to convert way points to
joint positions, and save those in G-code for Machinekit. Also, I modified
the emccanon.cc, tp.c, and tc.c for synchronized joints motion. Here's the
G-code snippet:

G1 X52.11885 Y-73.20373 Z-74.47628 A180.00000 B32.31998 C52.09593
G1 X52.11267 Y-73.19468 Z-74.49908 A180.00000 B32.30624 C52.08975
G1 X52.10650 Y-73.18563 Z-74.52187 A180.00000 B32.29250 C52.08358
G1 X52.10032 Y-73.17658 Z-74.54465 A180.00000 B32.27877 C52.07740

Here's the videos: cycle time testing https://youtu.be/WWACs-_hs-c, trajectory
testing https://youtu.be/lsefj2tBT6I

The trajectory is not accurate at this moment. I might not use Descartes
or implement the synchronized motion in a wrong way.

@gavanderhoorn https://github.com/gavanderhoorn - How was your
experience regarding trajectory accuracy with Descartes and the other robot
controllers?


Reply to this email directly or view it on GitHub
#689 (comment)
.

@mhaberler

This comment has been minimized.

Member

mhaberler commented Mar 8, 2016

Mirko just informed me that the cROS stack has been relicensed under BSD (formerly LPGPL3) and obviously transferred to the ros-industrial code base.

cROS is a single thread pure C implementation of the communications ROS framework and has no dependencies on the ROS stack except the msg definitions. I had eyed cROS as an option but did not consider it until the GPL2-incompatible licensing had been resolved, which it now is.

This means we have an second option next to Leopold's Debian ROS package stream to communicate with a remote ROS instance.

The cROS library has a very minimal footprint, and if experiences are positive we might even add it to the RT/HAL machinekit build to have something included for 'out of the box' examples.

Feel free to give it a go!

@yishinli

This comment has been minimized.

yishinli commented Mar 10, 2016

Could CRCL (Canonical Robot Command Language) be served as the role of G-code/RS274 interpreter of MachineKit? Or, which ROS package would be the alternative solution for this purpose?

Thanks and Regards,

@luminize

This comment has been minimized.

Member

luminize commented Mar 10, 2016

Hi All,

I'm wondering if there is any more need for this issue. I get the feeling that it's very generic and we got a bit smarter the last few months.
This issue is a great source and gathering of information, discussion and explanations (many Thanks @gavanderhoorn and @shaun-edwards ) on the internals/considerations w.r.t. ROS and Machinekit.
We have done some demo's and we have some proof of concept on getting ROS trajectory in Machinekit ("off line" motion planning). We can get values out of MK and have wrapped this is python/c++ nodes.

I think we're ready to split this issue into a smaller ones. Most important one would be "a ros_control machinekit controller". I've got some questions bubbling up on that subject so I want to propose that if there are no objections to close this issue and open more focussed ones, depending on subject.

Would that make sense?
Did I forgot anything?
Cheers,
Bas

@shaun-edwards

This comment has been minimized.

shaun-edwards commented Mar 10, 2016

First off, I think you guys have done excellent work. +1 for closing. It will be easier for myself to wrap my non-MachineKit head around smaller issues more focused on bits and pieces of ROS.

@yishinli

This comment has been minimized.

yishinli commented Mar 11, 2016

+1 for closing.

@luminize

This comment has been minimized.

Member

luminize commented Mar 13, 2016

closing, please see also #898

@machinekoder

This comment has been minimized.

Member

machinekoder commented Jul 1, 2018

@yishinli In case you are still interested in the robot command language problem: After some research figured that there no suitable solution inside ROS. Everyone using ROS with industrial robots already has a robot command language interpreter at hand. There aren't many people yet who use ROS with industrial robots bare-metal. In my opinion, that's holding back low-cost industrial robotics quite a lot. moveit_commander is the closest we could find, but we ended up inventing our own language for a project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment