10:05:15 <FranciscoD> #startmeeting ROS/RPM workshop #1
10:05:15 <zodbot> Meeting started Thu Apr 17 10:05:15 2014 UTC.  The chair is FranciscoD. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:05:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
10:05:25 <FranciscoD> #meetingname ROS/RPM workshop #1
10:05:25 <zodbot> The meeting name has been set to 'ros/rpm_workshop_#1'
10:05:35 <FranciscoD> #topic Who's here!?
10:05:42 <FranciscoD> .hellomynameis ankursinha
10:05:43 <zodbot> FranciscoD: ankursinha 'Ankur Sinha' <sanjay.ankur@gmail.com>
10:06:34 <banas> .fasinfo sarupbanskota
10:06:35 <zodbot> banas: User: sarupbanskota, Name: Sarup Banskota, email: sbanskota08@gmail.com, Creation: 2013-03-28, IRC Nick: banas, Timezone: Asia/Kolkata, Locale: en, GPG key ID: , Status: active
10:06:38 <exxa> Hello!
10:06:38 <zodbot> banas: Approved Groups: designteam cla_done cla_fpca
10:06:41 <mpduty> .fas mohanprakash
10:06:42 <zodbot> mpduty: mohanprakash 'mohan prakash' <mpduty@gmail.com>
10:06:59 <FranciscoD> #topic Introduction to ROS
10:07:01 <FranciscoD> exxa: hello!
10:07:11 <FranciscoD> ROS stands for "Robot operating system"
10:07:26 <FranciscoD> Basically, it's a huge set of packages that provide support for robotics research
10:07:35 <FranciscoD> http://www.ros.org/
10:07:57 <FranciscoD> The best part about ROS is that you can collect data from your robots and run simulations on them, i.e., you don't always have to work with hardware.
10:08:15 <FranciscoD> Another advantage is that the code you write for your simulators works on the robots as is
10:08:18 <FranciscoD> No changes are required at all
10:08:25 <FranciscoD> This makes it quite an awesome setup
10:08:49 <FranciscoD> Unfortunately, ROS upstream only provides packages for Ubuntu: debs
10:08:55 <FranciscoD> They do not provide rpms.
10:08:59 <FranciscoD> #info Unfortunately, ROS upstream only provides packages for Ubuntu: debs
10:09:14 <FranciscoD> Therefore, it's quite difficult for people that want to use Fedora, like me, to use ROS
10:09:25 <FranciscoD> I actually have a ubuntu install on my workstation at work for ROS
10:09:42 <FranciscoD> #info So, the robotics sig is working on packaging up all of ROS for Fedora
10:09:54 <FranciscoD> If you have any questions at any time, please ask them
10:10:20 <banas> !
10:10:24 <FranciscoD> banas: go
10:10:45 <banas> so does one have to pacakge one module?
10:11:01 <banas> or is it like there are several things to package and different people take up one each?
10:11:07 <banas> EOF
10:11:15 <FranciscoD> banas: it's a *huge* set of software
10:11:25 <FranciscoD> and we need to package them all, one by one, maintaining the dep chain
10:11:32 <FranciscoD> It's actually not a simple task
10:11:35 <FranciscoD> (as we found out)
10:11:49 <mpduty> !
10:11:54 <banas> cool, thanks
10:11:57 <FranciscoD> Also, upstream tends to carry local patches for some stuff, and we don't want to carry them at Fedora
10:12:10 <FranciscoD> We prefer that these patches be merged everywhere
10:12:11 <FranciscoD> mpduty: go
10:12:30 <mpduty> there are installation instructions for groovy in fedora http://wiki.ros.org/groovy/Installation/Fedora
10:12:51 <mpduty> can it be of some use
10:12:53 <FranciscoD> mpduty: Yeah, but I've tried them, they're not easy to follow
10:13:07 <FranciscoD> the other part is that they require compilation from source
10:13:16 <FranciscoD> So keeping your system up to date is *really* difficult
10:13:25 <FranciscoD> you effectively need to re compile the entire package set
10:13:34 <FranciscoD> I've tried it twice now, and failed each time :/
10:13:39 <FranciscoD> http://ankursinha.fedorapeople.org/fedora-ros-groovy/TEMPLATES/BUILDORDER
10:13:48 <FranciscoD> That's a small subset of the software ros uses
10:14:19 <mpduty> thanks
10:14:21 <FranciscoD> This is only the "ros-base", ie the underlying base on top of which rest of ROS works
10:14:48 <FranciscoD> https://github.com/ros/
10:14:54 <FranciscoD> That's close to all the packages the ROS requires
10:15:44 <FranciscoD> let's talk some ROS basics, just to give you an idea of how it works
10:15:51 <FranciscoD> Anyone working with any robots here?
10:16:07 <banas> not me
10:16:10 <FranciscoD> http://www.turtlebot.com/
10:16:11 <FranciscoD> for example
10:16:16 <FranciscoD> it's a really cool robot
10:16:34 <FranciscoD> http://www.willowgarage.com/pages/pr2/overview
10:16:40 <FranciscoD> That's another one that I work with
10:16:58 <FranciscoD> Robots are effectively a combination of: sensors, actuators and the processor
10:17:13 <FranciscoD> the sensor can be anything from pressure sensors to just normal cameras
10:17:24 <FranciscoD> actuators will include wheels, grasps, arm etc
10:17:29 <FranciscoD> Like you can see in the PR2
10:17:59 <FranciscoD> #info ROS divides all of this into two broad parts: the ROS server and ROS nodes
10:18:21 <FranciscoD> The server actually doesn't do much.
10:18:34 <FranciscoD> All sensors, actuators are nodes
10:18:47 <FranciscoD> Imagine a network of nodes, and all these nodes communicate with each other
10:19:01 <FranciscoD> Lets say we have a normal stereo camera
10:19:11 <FranciscoD> Again, if you don't understand something, please stop and ask
10:19:46 <FranciscoD> The stereo camera node will have a unique identification name, say "stereo_cam_1"
10:20:22 <FranciscoD> As expected, all the camera does is record video: generally as a set of imagees
10:20:44 <FranciscoD> The node will talk to the server when it comes up, and "register" with it
10:21:05 <FranciscoD> apart from the identification, the node tells the server what *capabilities* it has
10:21:33 <FranciscoD> so our camera will tell the server that it's called stereo_cam_1, and that it "publishes" image data
10:21:55 <FranciscoD> of course, it'll include low level details like the image format, resolution, frequency etc
10:22:24 <FranciscoD> Lets say we want our robot to recognize a target and approach it
10:22:34 <FranciscoD> We have another node: the wheel node
10:23:16 <FranciscoD> We develop some logic between the camera and wheel node that recognizes our target and controls the wheels
10:23:46 <FranciscoD> so, camera publishes -> logic system "subscribes" , publishes to wheel -> wheel acts
10:23:57 <FranciscoD> Is that too much to take? :P
10:24:12 * FranciscoD will wait a few minutes for it to sink in
10:24:19 <mpduty> its quite intuitive
10:25:01 <FranciscoD> its quite well designed, yeah
10:25:18 <FranciscoD> that's basically how it works really
10:25:25 <FranciscoD> each node tells the server:
10:25:27 <FranciscoD> - identity
10:25:31 <FranciscoD> - what it publishes
10:25:38 <FranciscoD> - what it wants to subscribe to
10:25:50 <FranciscoD> - "services" it provides
10:26:11 <FranciscoD> the thing with publishing is that nodes are *always* publishing
10:26:18 <FranciscoD> any node can subscribe to them and use their data
10:26:26 <FranciscoD> the data is called  a "topic" in ROS terms
10:26:29 <banas> !
10:26:39 <FranciscoD> banas: go
10:26:44 <FranciscoD> http://wiki.ros.org/ROS/Tutorials/UnderstandingTopics
10:26:55 <banas> "so, camera publishes -> logic system "subscribes" , publishes to wheel -> wheel acts" this  logic system stays in server?
10:27:16 <FranciscoD> banas: the logic system runs on the processor, but it doesn't run "on the server"
10:27:21 <FranciscoD> the server is called "ros master"
10:27:28 <FranciscoD> the logic system will actually be a node by itself
10:27:30 <FranciscoD> :)
10:28:01 <banas> cool, makes sense now. one more question: where does all the data gathered by the camera etc go?
10:28:01 <FranciscoD> All the server really does is keep a database of the nodes and their properties
10:28:13 <FranciscoD> banas: if youre running a recorder node, it'll be recorded
10:28:24 <FranciscoD> otherwise it's just sent out on the "network"
10:28:30 <FranciscoD> since most of these nodes work in real time
10:28:45 <FranciscoD> the communication between nodes is done via "ros_msgs"
10:28:53 <FranciscoD> it's an abstraction based on simple tcp/ip
10:29:17 <FranciscoD> http://wiki.ros.org/Messages
10:29:31 <FranciscoD> Quoting:
10:29:32 <FranciscoD> "Nodes communicate with each other by publishing messages to topics. A message is a simple data structure, comprising typed fields. Standard primitive types (integer, floating point, boolean, etc.) are supported, as are arrays of primitive types. Messages can include arbitrarily nested structures and arrays (much like C structs).
10:29:37 <FranciscoD> Nodes can also exchange a request and response message as part of a ROS service call. These request and response messages are defined in srv files. "
10:30:48 <FranciscoD> I'll quickly touch on "services" that nodes provide
10:31:03 <FranciscoD> So, "topics" are always published, and any other node can subscribe to them
10:31:20 <FranciscoD> However, there are "services" which are basically functions, that can be called on demand
10:31:40 <FranciscoD> for example, say the logic node published a message saying "move 5 steps forward"
10:31:53 <FranciscoD> The wheel subscribes to this topic, receives the message, and begins to roll forward
10:32:18 <FranciscoD> Imaging there's an obstacle in the path of the robot
10:32:39 <FranciscoD> as soon as our logic node notices the obstacle, it wants the wheels to stop
10:33:09 <FranciscoD> if it publishes a message saying "stop", the message will only be processed by the wheels *after* the previous message, which says "go forward 5 steps"
10:33:21 <FranciscoD> which isn't good enough
10:33:38 <FranciscoD> so, the logic node will call a "service" on the wheel: "emergency stop!"
10:33:53 <FranciscoD> this service will make the wheels stop, and discard any commands that were in the process queue
10:33:57 <FranciscoD> Makes sense?
10:34:09 <banas> yep, makes sense to me so far
10:34:27 <mpduty> !
10:34:31 <FranciscoD> mpduty: go
10:34:59 <mpduty> each node listens for some specific "publish"es?
10:35:11 <mpduty> eof
10:35:27 <FranciscoD> mpduty: yes, when you write a node, you specify what topics itll publish and what it'll subscribe to
10:36:00 <mpduty> ok
10:36:07 <FranciscoD> I think that's all I'll cover about "ros logic".
10:36:21 <FranciscoD> I'll quickly explain how ROS packaging works, so we can work on this in the other sessions
10:36:28 <FranciscoD> #topic ROS packaging
10:37:11 <FranciscoD> Like I said earlier, packages are categorized according to their function
10:37:17 <FranciscoD> so, ros-comm is the list I put up
10:37:29 <FranciscoD> On top of that, you'll have others: perception, navigation, robots etc.
10:37:44 <FranciscoD> Obviously, we need to package ros-comm before we can package perception
10:38:15 <FranciscoD> The good thing is that ros nodes contain metadata that tells you their dependencies
10:38:43 <FranciscoD> https://github.com/ros/catkin/blob/indigo-devel/package.xml
10:38:45 <FranciscoD> for example
10:38:52 <FranciscoD> notice the lines "build_depend" and "run_depend"
10:39:05 <FranciscoD> it's similar to how RPMs store metadata
10:39:13 <FranciscoD> and similarly, these cause dependency chains
10:39:37 <FranciscoD> So, in a very very simple way, we need to:
10:39:46 <FranciscoD> - chalk out a dependency tree
10:39:57 <FranciscoD> - go from the root of the tree to all the leaves
10:40:23 <FranciscoD> The one *huge* issue here is that ros packages are setup such that they're installed in /opt/ros
10:40:50 <FranciscoD> /opt/ros is registered with lanana: http://lanana.org/
10:41:07 <FranciscoD> it's the body that keeps track of /opt/<directories> and other stuff
10:41:28 <FranciscoD> Now, until we started with fedora.next, installing *anything* in /opt/ was *forbidden*
10:41:43 <FranciscoD> everything *had* to be installed in the standard linux FHS (file system hierarchy)
10:42:02 <FranciscoD> That made it really difficult for us, because it meant patching all the build scripts used by ros software
10:42:35 <FranciscoD> Recently, with the "SCLs", the "playground" repo and COPR etc., FPC is a little more open to installation of stuff in /opt
10:42:45 <FranciscoD> I think they're even registering /opt/fedora with lanana
10:42:54 <FranciscoD> Any questions?
10:43:07 <FranciscoD> I have one, I'll ask it if no one else does ;)
10:43:18 <banas> !
10:43:22 <FranciscoD> banas: go
10:44:18 <banas> um, I think it's a bit OT here, any links you can give me to later read about /opt and stuff? I didn't really understand that stuff..
10:44:41 <FranciscoD> banas: check `man hier`
10:45:03 <FranciscoD> it has a one line entry on /opt
10:45:14 <FranciscoD> banas: it's *just* another directory
10:45:21 <FranciscoD> but like we have a hierarchy in /
10:45:30 <FranciscoD> they have a hierarchy in /opt/ros/
10:45:51 <FranciscoD> so you'll have /opt/ros/..usr/ and /opt/ros/..lib
10:45:52 <FranciscoD> etc
10:45:55 <FranciscoD> banas: clearer?
10:46:20 <banas> yep better :)
10:46:25 <FranciscoD> The question I had was "Why does ros install in /opt instead of just using / like all other software?"
10:46:30 <FranciscoD> Couple of reasons:
10:46:45 <FranciscoD> 1. ros uses a lot of general libraries, like opencv for example
10:46:58 <FranciscoD> http://opencv.org/
10:47:15 <FranciscoD> the version of opencv that ros needs may not be the same as the one we package in fedora
10:47:22 <FranciscoD> maybe we have a newer one, or an older one
10:47:31 <FranciscoD> so, ros keeps all it's things separately
10:47:40 <FranciscoD> without mixing it up with distribution packages
10:47:48 <FranciscoD> 2. ros has multiple releases at the same time
10:47:56 <FranciscoD> for example, the oldest was "fuerte"
10:48:00 <FranciscoD> then there was "groovy"
10:48:06 <FranciscoD> then there is "hydro" I think
10:48:23 <FranciscoD> the changes are quite huge, so you can't just update from groovy to hydro and expect your stuff to work
10:48:34 <FranciscoD> they're parallel releases, and all of them are supported
10:48:51 <FranciscoD> also, in research environments, people generally arent too excited about updates etc
10:49:01 <FranciscoD> they use whatever the initial set up is, however old it may be
10:49:21 <FranciscoD> so, since there are multiple parallel releases, ros needs to keep them separately too
10:49:35 <FranciscoD> therefore, we have /opt/ros/fuerte/ and /opt/ros/groovy
10:49:35 <FranciscoD> etc
10:49:43 * FranciscoD checks his watch
10:49:46 <FranciscoD> 10 more minutes
10:50:01 <FranciscoD> let me quickly outline the challenges of packaging up ROS
10:50:09 <FranciscoD> #topic ROS packaging challenges
10:50:15 <FranciscoD> 1. Huge package set
10:50:19 <FranciscoD> 2. Local patches
10:50:31 <FranciscoD> 3. Non standard build system
10:50:37 <FranciscoD> For example, ros doesnt use autotools
10:50:38 <FranciscoD> or cmake
10:50:42 <FranciscoD> they wrote their own!
10:50:59 <FranciscoD> initially it was "rosdep" based (fuerte still is)
10:51:18 <FranciscoD> with groovy they wrote a new one called "catkin", which is cmake with add ons
10:51:21 <FranciscoD> well, sort of
10:51:31 <FranciscoD> groovy has a mix of rosdep and catkin packages
10:51:42 <FranciscoD> I think with hydro they've moved completely to catkin
10:51:46 <FranciscoD> 4. Multiple releases
10:51:51 <FranciscoD> if one release is tough, 3 is tougher
10:51:59 <FranciscoD> and they're all following different build systems
10:52:06 <FranciscoD> so they may not be similar to package at all
10:52:24 <FranciscoD> 5. Lack of interest
10:52:37 <FranciscoD> well, researchers dont' like spending time on infra
10:52:48 <FranciscoD> maybe once I begin my Phd, I won't do this stuff either
10:52:58 <FranciscoD> so, they just install ubuntu, and ros on it, and use it
10:53:13 <FranciscoD> ubuntu also has an LTS, which makes it a good platform
10:53:24 <FranciscoD> but, if we can package ros for Fedora, we can package it for RHEL
10:53:29 <FranciscoD> and centos and scientific
10:53:45 <FranciscoD> #topic Some good news
10:54:08 <FranciscoD> With hydro, one of the robotics sig members managed to extend the ros build system to also generate rpms
10:54:30 <FranciscoD> http://copr.fedoraproject.org/coprs/cottsay/ros-underlay/
10:54:39 <FranciscoD> so, we have a copr with some ros packages
10:55:00 <FranciscoD> what he did was: parse the metadata files of the ros packages, and then fill up required info in the spec
10:56:31 <FranciscoD> it makes things a little easier for us
10:56:36 <FranciscoD> but there's a long way to go
10:56:44 <FranciscoD> Ok, last 4 minutes for any questions
10:56:49 <FranciscoD> #topic *quick* Q&A
10:57:04 <FranciscoD> Ask away
10:57:10 <FranciscoD> and then we'll end the meeting
10:57:27 <banas> :D
10:57:43 <mpduty> say something that you plan to do in fudcon
10:57:52 <FranciscoD> well, the idea is
10:57:58 <FranciscoD> now that you know how ros packaging is to be done
10:58:13 <FranciscoD> and in the next few sessions, we'll see how rpm packages can be made for SCLs
10:58:27 <FranciscoD> at the fudcon, we'll sit around, each pick a ros package, and make rpms
10:58:36 <FranciscoD> as many as we can make
10:58:55 <FranciscoD> that's all really
10:59:14 <FranciscoD> the thing is that its mixed with robotics, so it has an appeal to students that are interested in the area
10:59:33 <banas> ah sounds fun! i wish i had a robot i could play with now :P
10:59:42 <banas> FranciscoD: yes :D
11:00:10 <mpduty> there are simulators?
11:00:12 <FranciscoD> banas: unfortunately, robots are expensive :/
11:00:18 <FranciscoD> mpduty: yeah, there are a lot of simulators
11:00:35 <banas> FranciscoD: I know, I did look around with the links you provided :/
11:00:47 <FranciscoD> http://wiki.ros.org/turtlebot_simulator/Tutorials
11:00:55 <FranciscoD> the turtle bot is 1500$ last I checked
11:00:57 <FranciscoD> with everything
11:01:02 <FranciscoD> the PR2 is half a million ;)
11:01:35 <mpduty> that is ok for say a university
11:01:42 <banas> yep
11:01:44 <FranciscoD> yeah
11:01:54 <FranciscoD> I don't know about India, though
11:02:00 <FranciscoD> Not sure what they use
11:02:08 <FranciscoD> Not a lot of robotics research back home, I'm afraid
11:02:31 <mpduty> we may request faculties to take up UGC projects
11:02:32 <banas> FranciscoD: agreed
11:02:49 <FranciscoD> mpduty: it's possible, but I don't have the time to do it ;)
11:02:59 <FranciscoD> that's a different discussion
11:03:07 <mpduty> yes
11:03:15 <FranciscoD> one that will need to be done with people involved in the education system
11:03:20 <FranciscoD> ok
11:03:28 <FranciscoD> if we don't have any more queries, I'll call it a day
11:03:34 <FranciscoD> I hope you learnt *something*
11:03:39 <FranciscoD> Not a lot, but something ;)
11:03:52 <mpduty> yes of course, it was very helpful and inspiring
11:04:11 <mpduty> looking forward for the other sessions
11:04:12 <banas> +1 from me, I did pick up quite a lot of keywords, and a bit of insight about how robots work
11:04:18 <mpduty> the time remains the same?
11:04:22 <FranciscoD> Yeah
11:04:27 <FranciscoD> I don't think we need to change it
11:04:39 <FranciscoD> feel free to pass on the logs etc to any student friends you ahve
11:04:45 <FranciscoD> anyone at all interested in robotics, really
11:05:14 <FranciscoD> Let's finish the meeting
11:05:17 <FranciscoD> #endmeeting