Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Robotics Technology Hardware

Needed: A LAMP Stack For Robotics 65

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.'"
This discussion has been archived. No new comments can be posted.

Needed: A LAMP Stack For Robotics

Comments Filter:
  • by gestalt_n_pepper ( 991155 ) on Thursday March 29, 2012 @08:47AM (#39508613)

    DON'T skimp on the LAMP stack testing.

    • Re: (Score:3, Insightful)

      by iamgnat ( 1015755 )

      All I can think of is, do we really want the typical PHP "programmer" types writing code for robots? Really? It's bad enough what a SQL injection attack can do now, imagine what can happen when it effects something with arms to beat people over the head with (though if it could be directed at the programmer...).

      • All I can think of is, do we really want the typical PHP "programmer" types writing code for robots?

        You seem to think because you see "PHP" that people barely capable of writing anything in the language will be writing code for something that requires rigorous quality control. Truth is, these "programmer" types as you put it are more likely to stick to what they know best and leave the technical stuff to people who know that best. Also, who's to say that these "programmer" types won't try to pretend like they know C, or Java, or SQL? A language is just a language, and anyone can learn any language, but

        • You seem to think because you see "PHP" that people barely capable of writing anything in the language will be writing code for something that requires rigorous quality control. Truth is, these "programmer" types as you put it are more likely to stick to what they know best and leave the technical stuff to people who know that best. Also, who's to say that these "programmer" types won't try to pretend like they know C, or Java, or SQL? A language is just a language, and anyone can learn any language, but it's how the language is used and the person using it that determines its usefulness to whatever it is applied to.

          The evidence is overwhelming that the average PHP programmer has no business writing code that sees the light of day. At one point something that would process credit cards would require "rigorous quality control", but now many such applications see a minimum of testing (because many companies view QA as more of a cost sink than Dev). It's not a fault of PHP itself, I think it is more a side effect of things like LAMP have drastically reduced the barriers of entry. My issue with these types of programmers i

        • I respect your spin, truth is, though, that companies and especially HR can get it badly wrong (as in "holy crap the toaster is shooting at me").

          IMHO robotics does need a good standardized stack, a good friend works in robotics research and what I can gather is that not having agreed upon base layers of software is killing their productivity. Still since robotics does (and always should) employ good minds I'd vote for a language that can model high complexities. Maybe something in the realms of C or, even b

      • It's bad enough what a SQL injection attack can do now, imagine what can happen when it effects something with arms to beat people over the head with

        Like my grandpa used to say, "Son, you can't take out a SQL injection attack with buckshot, but them robots go down hard."

    • I've been wanting to build testing code on /etc/cough all day.
  • by Shoten ( 260439 ) on Thursday March 29, 2012 @08:53AM (#39508695)

    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.)

    • How standardised is computer hardware? Linux runs on Intel, Aarm, alpha, PPC, RISC, Spark, IBM (as in AIX mainframe) processors, and more. The point is that a standard would develop a framework lowering the barrier to entry. As more people some in, both the hardware and the software will improve, lowering the barrier further. This is a good thing.
    • There are industry standards for CNC machines, which are a form of robot that's been in use for decades. Probably not particularly applicable though.
    • You can use various methods to TX/RX raw serial data between linux programs and the uController hardware. Whether that's an entire Arduino board or a MAX232 serial converter soldered to a USB cable, it sends the same data. Hell, drive your robotics servos with the parallel port. There are a hundred different ways to rig it up.

      Plus with the introduction of things like the RaspberryPI and other micro system-on-a-chip computers it's increasingly easy to create a LAMP stack for circuit-sized applications.

    • Yeah, how about a robust, resilient, and cheap USB i/o box, please.

      • They have those. One brand is called LabJack. The downside is that you're paying extra for what amounts to an arduino that you can't (as?) easily re-program and/or embed into a gadget.

    • Joint Architecture for Unmanned Systems (JAUS) It originates in the DARPA research ecosystem, so it's got a lot of alphabet soup going on. I'm not sure if this is what the commercial sector will eventually converge upon as a standard, but what they do converge on will resemble that to some degree atleast.
    • How standardized is robotic hardware?

      It depends on what you mean by "standardized". Sure, there's nothing directly analogous to a PC with "Intel Inside", but there certainly are a limited number of choices for any robot designer when it comes to any aspect of the design.

      Start with communications... you will quickly settle on a few choices - if millisecond latency is not an issue, you'll probably talk via ethernet or some serial bus, of which the choices are limited. If you need less latency, you'll chose a more traditional bus, of which the op

    • 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?

      Standardized representations of coordinate frames and tools for manipulating them is indeed one of the features provided in most robotics frameworks.

  • LAMP stack? (Score:2, Funny)

    by c0lo ( 1497653 )
    For robotics? Here's your lamp stack [wikipedia.org]
  • by SomeKDEUser ( 1243392 ) on Thursday March 29, 2012 @08:58AM (#39508763)

    https://aseba.wikidot.com/ [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.

  • Linuxcnc + RTAI (Score:5, Interesting)

    by LuxuryYacht ( 229372 ) on Thursday March 29, 2012 @09:07AM (#39508851) Homepage

    Much of this is already in LinuxCNC
    http://www.linuxcnc.org/ [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 [linuxcnc.org]
    http://linuxcnc.org/docs/html/motion_kinematics.html [linuxcnc.org]

    We've use it to control some pretty complex robotic systems.

  • 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

    • by bstag ( 933525 )
      Some of us are exploring and documenting on the way while cussing loudly. As for being specific it generally relates to the platform they implemented ROS on. If we did the stacks in the manner of processing stacks and platform stacks as separate. It could be a boon to the usability of the community stacks. Some of the community has done this in their stacks already. WG does not push this maybe moving to its own foundation with its own future will drive this style of change. As someone who feels your same fr
  • why LAMP? (Score:3, Funny)

    by DragonTHC ( 208439 ) <DragonNO@SPAMgamerslastwill.com> on Thursday March 29, 2012 @09:49AM (#39509601) Homepage Journal

    why do you need a LAMP stack, is the robot going to run around updating its blog and posting crappy instamatic photos?

    • I agree. I mean, you could create a standard RESTful API for controlling robots, but why would one need to specify OS/web server/scripting language/database products to implement that API? Why couldn't I use PostGres, or SQLLite or some other database on the robot? Using SQLLite would certain make more sense than having a full MySQL server running Why couldn't I Implement the scripting in Java, or C if I wanted to?
  • by LifesABeach ( 234436 ) on Thursday March 29, 2012 @09:49AM (#39509619) Homepage
    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 - JAUS (Score:5, Interesting)

    by Animats ( 122034 ) on Thursday March 29, 2012 @09:56AM (#39509727) Homepage

    There is such a stack: Open JAUS. [openjaus.com] 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 [microsoft.com] 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 [tamu.edu]: 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.

    • by elabs ( 2539572 )
      It was a flop? My company just started using the latest version (4) of Microsoft's Robotics Studio and we love it. The ability to simulate robotics scenarios before implementing them is very helpful. We haven't run into the threading issues you're mentioning. We just spawn more threads if we need to do other computation in parallel. Works great.
  • 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 [popsci.com]
    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 eng
  • 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?

  • 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 upd
  • It should be a LAPP or LAPPPP server... (Linux, Apache, PostgreSQL, PHP/Perl/Python)!
  • 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

  • The coolness factor has to meet the "super villain" level before I'll be interested.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Working...