Slashdot Mirror
Needed: A LAMP Stack For Robotics
waderoush writes "If you visit Menlo Park, CA-based Willow Garage, you'll meet a $400,000 humanoid robot called PR2 that has stereo vision, a pair of dextrous arms, and enough smarts to roam the building indepedently and even plug itself into the wall when it needs to recharge. But in a sense, PR2 is just a demo. The real action at Willow Garage is around ROS, the Robot Operating System, a free meta-operating system that's already being used by hundreds of roboticists around the world and may soon be handed over to an independent foundation analogous to the Apache Software Foundation. Brian Gerkey, Willow Garage's head of open source development, says 'What we need is a LAMP stack for robotics,' and hopes that ROS will jumpstart innovation in robotics in the same way Linux and other free software components provided the foundation for the Internet boom. Today's roboticists 'have to come at the problem with a very deep expertise in all aspects of robotics, from state estimation to planning to perception, which automatically limits the number of people capable of building new things,' Gerkey says. 'But by providing a basic toolset analogous to the LAMP stack, we can get to a point where all you need to know is how to write code and what you want your robot to do.'"
We hereby stack a bunch of frisky pornstar lezbos next to the living room LAMP.
DON'T skimp on the LAMP stack testing.
Please do not read this sig. Thank you.
How standardized is robotic hardware? With the LAMP stack, you're creating an environment with integrated components for OS, database, web services and application services so that you can build what you need from end-to-end. But it seems to me that with robotics, you have one more step to go: the kinetic/physical representation of things. Are there standards for the description of spatial relationships, feedback from sensors and movement directives? I'm not challenging the idea; I think it's great. But I'm curious about this one aspect of it, since I know very little about the robotics world and think that many of the people who will comment on this are in the same boat. (Thus, some clarity on this may improve the quality of comments...somewhat.)
For your security, this post has been encrypted with ROT-13, twice.
For robotics? Here's your lamp stack
Questions raise, answers kill. Raise questions to stay alive.
https://aseba.wikidot.com/
Not from me, but from a good friend. Need to programme distributed behaviour in swarms of robots with an easy-to-use IDE coupled with a simulator? Need to transparently switch between reality and simulation as well as have access to pre-programmed sensors and robots? Free software ?
There you go.
Much of this is already in LinuxCNC
http://www.linuxcnc.org/
It's mostly used by developers to control CNC machines but it also includes support for non-Cartesian motion systems provided via custom kinematics modules. Available architectures include hexapods (Stewart platforms and similar concepts) and systems with rotary joints to provide motion such as PUMA or SCARA robots.
http://linuxcnc.org/docs/html/man/man9/kins.9.html
http://linuxcnc.org/docs/html/motion_kinematics.html
We've use it to control some pretty complex robotic systems.
Quidquid latine dictum sit altum viditur
I use ROS in my research daily, and it's a great framework. However, it suffers from the a lot of the same problems other open source project face. Foremost, aside from stacks produced by Willow Garage, the documentation is incredibly spotty. For the most part, packages rely on doxygen API documentation as a substitute for true documentation, when really it tells you nothing of how to use a particular package. For the majority of stacks, there are no tutorials, examples, or even indications on how to get a particular package running correctly.
Further, like most FOSS projects, direction is very scattered. Again, aside from stacks developed at Willow Garage, a lot of code is very specialized to a specific robot platform, when it should be generalized to work on any platform. I think this is in part due to the disperate nature of the field, but also is a side effect from the lack of documentation; instead of using an undocumented stack, most groups will simply reinvent the wheel because figuring out the mystery package would take longer. I mean, only last month a generalized teleoperation stack was released. Before that, each robot seemed to have its own specialized teleoperation package coded for a particular input type.
Honestly, what I like most about ROS is the TCP/IP node framework, the trasnformation stack, the point cloud library (PCL), and the wide array of message types (plus the ability to define my own). Also the device drivers are very handy, so I can be assured most of my devices are plug and play. I think being able to leverage this framework and common robotics algorithms is incredibly powerful. However I'm not convinced of the utility in most community developed stacks, as they're still too specialized and too undocumented to be generally useful.
why do you need a LAMP stack, is the robot going to run around updating its blog and posting crappy instamatic photos?
They're using their grammar skills there.
My minor experiences with robotics,(JetLine welders used for ISS), has given me more appreciation for the estimation qualities of Probability. If Udacity could offer a 12 week class on the concept of applied probability for a robotic trash can? For some of us, space management, hardware, and software can be figured out. Applied Probability is not trivial.
There is such a stack: Open JAUS. JAUS is the Joint Architecture for Unmanned Systems used by many military robotic and unmanned systems. It's somewhat dated, and has a more open-loop approach more suited to teleoperators than fully autonomous systems.
Dealing with the time constraints in robotics rules out some of the approaches used in other software. Microsoft's Robotics Studio was built on a web-like approach, and it was a flop. Game programs tend to be tied to the display refresh rate, which isn't helpful in robotics. In robotic systems, there may be several subsystems with their own cyclic rate and processing delay, and they need to talk to each other. The inputs which have processing delays, like vision systems, produce outputs which represent the situation at some time in the past. Updates to the world model based on multiple sensors must all be synchronized to the time of the observation, not the time the data became available. This matters when you're moving fast. For slow robots, not so much. Many research robots are slow and pause a lot because they don't do this. That was the norm a few years ago, but it's not any more.
Robotic systems tend to need hard real time control. That control can be quite complex, not just a simple servo loop. Inside the more advanced and agile robots, like BigDog, you tend to find QNX, not Linux. (Typical test for a hard real-time OS: hook up a square wave oscillator to an input, and a scope to an output. Put a high-priority program in the system which turns on the output when the input comes on. Watch the input to output delay on the scope. Load up the system with lower-priority tasks. If the input to output delay is ever substantially longer, (more than a few microseconds) the system is not hard real time. The "real time" variants of Linux have trouble getting down to 1ms, and 10ms of jitter is observed. In hard real time systems, 10us is more like it. Servo control in BigDog executes every 1ms, balance every 10ms.) However, as CPUs get faster, the limitations of Linux have become less of an issue.
$link = mysql_connect();
$type = 'arms';
$query = 'SELECT limbs FROM robot WHERE type = '$type';
while (($row = mysql_fetch_result($query, $link)) !== null) {
move($row['limbs], 'wave');
}
robotic programming for everyone! and an injection attack as a side benefit!
Well here is what I see as their LAMP stack:
L: Well instead of Linux they are going to use their trusty open-source ROS for the basis of this
A: This is kind of taken care of by the next point M
M: Well they need a database with lots of functions which has previously been created: RoboEarth
P: You need a way to query this information so the people at RoboEarth have created a non-device-specific code for ROS, yey!
Now, they may want more than this, or they may also want a local database and query engine, which could be SQLite and SQL, but should probably be something more robot-specific, although if you use SQLite or something compatible, lots of people would know how to work with it out-of-the-box
As I see it, it's almost done, they just need to make RoboEarth have a large database, and get the ROS part of RoboEarth to work and they should be on their way to the Ros RoboEarth ROS Plugin? or RRR because then it could be R^3
Lighttpd would be better...
https://aseba.wikidot.com/
Would this work on the Raspberry Pi? Or some other cheap computer that an amateur could use as the starting point for his or her home robotics project?
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
And ARDUINO is what again?
http://www.arduino.cc/
The sooner the better.
And I say that as a true pessimist of open source. I have tried to use ROS for home robotics. Not that I am a researcher by any means, but I do have a lot of familiarization with stuff that is happening in robotics. It was, to put it simply, too difficult to get a ROS system running. There are always so many mismatches among the large number of pieces you need it is impossible to start from scratch and get anything to work. Once you have a running system you can milk it along with updates. Or if you do start from scratch and you wait long enough, eventually via updates things might start working together.
Putting in an all in one package eliminates that struggle. A hobbyist could actually work on robotic stuff rather than OS stuff. In a similar package (previously mentioned I believe) LinuxCNC had the same problem, and did not truly get useful until you could download a working ISO of everything.
Good luck (to be honest, it couldn't get much worse).
slashdot troll = you make a compelling argument I do not like the implications of.
It should be a LAPP or LAPPPP server... (Linux, Apache, PostgreSQL, PHP/Perl/Python)!
========
77 77 77 2e 6d 65 6c 76 69 6e 73 2e 63 6f 6d
LAMP is a powerful tool, then again there's MS's solution, Oracle's solution, IBM's, Apple's and Google's (which uses some of LAMP). Most folks I know that use LAMP dev on the live server. Most folks I know that use the other frameworks simulate, then ad-hoc test then test on the server.
Problem is that paradigm works clearly when you can have failures on the metal, aka the server--in that world you revert to older code or reboot.
That's not the case with Robots--you test on the metal and usually can't afford crashing the server (which typically crash the metal). Proprietary still rules for the near future because of that. I'm surprise why ROS has not been tested in a rigorous real time manufacturing environment nor WG expressing any interest to evolve ROS to be a tested/solid framework.
The coolness factor has to meet the "super villain" level before I'll be interested.
Can you say BeagleBone?
Inventor, Artist http://www.Rubber-Power.com
Certainly a robot isn't going to need data integrity or reliability in general, since any data acquired can obviously just be acquired again experientially. Why invest the SAME effort in installing PostgreSQL instead? With MySQL, you don't have to disable all the foreign key checks an so on in order to have a system that performs well on just Very Simple Queries. And the robot can cross its fingers (claws?) automatically when doing updates. It'll be fine... what can go wrong in a database running on a robot - power interruptions? Pshaw.
As posters have pointed out, there are many existing "standard" robotics frameworks, each equally loved by small niches - but actually further proves the point of why we need ROS - an attempt to unify the community that is currently fragmented.
I have used a number of robotics frameworks, but ROS is by far the best - whether it be an arduino, xbox kinect, cheap webcam, or movement chasis of my own devising, all I need to focus on in a small amount of glue code (typically in python) and the results of hundreds of research projects are suddenly at my finger tips, without me needing to reinvent the wheel. It makes no preconceptions about whether you're using a university department with a $10,000 laser range finder, or a broke student with a $20 web cam - all the software still works the same. And the tools for debugging and simulation are amazing.
Avoiding reinventing the wheel is what we need most - we need people to be able to focus on reusable robotics software modules so that we can make progress incrementally and collaboratively rather than the status quo of continuously reinventing the wheel.