Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Juggling Molecules with Linux 111

Posted by CmdrTaco from the look-ma-no-hands dept.
An anonymous reader writes "This article at LinuxDevices.com describes an interesting project at the University of Vermont in which researchers use real-time Linux to build a laser trap that manipulates individual molecules by means of a computer-controlled laser beam. The project makes use of RTLinux, a real-time enhanced version of Linux that allows the system to process interrupts every 50 microsecond, sample new data, and timeshare the laser beam position. 'If the computer failed to respond, for even a millisecond, then we would drop the balls,' explained one of the researchers. Gives a whole new meaning to BSOD, eh?"
This discussion has been archived. No new comments can be posted.

Juggling Molecules with Linux More

Juggling Molecules with Linux

Comments Filter:
  • [...] Gives a whole new meaning to BSOD, eh?

    I do not see why.

  • ...is doing something useful. Just kidding! Don't kill me. Mod Flaimbait, please
    • Why not just use DOS or mac OS 8. Seriously. For instrument control you want your program running and screw everything else. Modern OS are the bane of instrument control, even so-called RT systems. They just seem to go out to lunch every now and then.
      • If you had read the summary you would have answered your own question. RT linux handles interrupts much faster than any other OS. If they lose control of the laser, they have to start over.
      • I know that many people who program computers to run their laboratory hardware do it with DOS. It's easy and efficient. I imagine these guys had a reason to switch to Linux, maybe the efficiency was too low or they needed modern development tools.

  • Meh (Score:5, Funny)

    by Shadow Wrought ( 586631 ) <.shadow.wrought. .at. .gmail.com.> on Wednesday June 08, 2005 @11:58AM (#12759275) Homepage Journal
    When it's juggling a molecule, a bowling ball, and a chainsaw, then I'll be impressed;-)

  • RTLinuxPro [fsmlabs.com] is used to control the laser beam positions, as well as to sample the output of measuring devices. At the core of the software is a kernel-side module that interrupts every 50 microsecond, samples new data, and timeshares the laser beam position. "If the computer failed to respond, for even a millisecond, then we would 'drop' the balls," explained Warshaw [uvm.edu], "but RTLinuxPro is rock solid."

  • Not really... (Score:1, Funny)

    by avalys ( 221114 )
    I think it gives a whole new meaning to the phrase: "don't drop the ball!"

  • Dr. Torvalds... (Score:3, Funny)

    by Tackhead ( 54550 ) on Wednesday June 08, 2005 @12:02PM (#12759315)
    > This article at LinuxDevices.com describes an interesting project at the University of Vermont in which researchers use real-time Linux to build a laser trap

    Dr. Torvalds: You know, I have one simple request... and that is to have penguins with frickin' laser beams attached to their heads. Now evidently, my megaloptic Naval colleage informs me that IT'S A TRAP!

    /one ticket to hell please.

  • Realtime Linux on the desktop. (Score:5, Interesting)

    by CyricZ ( 887944 ) on Wednesday June 08, 2005 @12:03PM (#12759331)
    I know several researchers who have been using realtime Linux on the desktop while performing studies regarding the user experience of systems with minimal latency. Their preliminary findings are that users much prefer the instantaneous response that a realtime system offers, even if the system does not perform as well when it comes to raw data crunching. For future desktop systems, heavily multithreaded, realtime apps are the way to go.
    • That's also the main selling point for desktop dual-core chips - without a realtime OS the second processor keeps the GUI running smoothly even under load. I sometimes use my friend's old dual Pentium 300, and under load it actually feels marginally faster than my (way faster) single chip Athlon. If the price, noise and energy consumption weren't so high I'd buy one for home use - and dual core may be the solution to those problems (plus, dual-core notebooks are a possibility, dual-chip - hardly). I also wo

    • Not sure about this.. (Score:5, Interesting)

      by Da VinMan ( 7669 ) on Wednesday June 08, 2005 @12:50PM (#12759805)
      I don't dispute your friends' findings, but I'm wondering why a RT based OS would really improve the user experience?

      Here's why I ask: A RT system is typically real time for some dedicated purpose. Not all pieces of the system have to be RT; just the important bits. Now, an average user PC is NOT a specialized device at all. It can be running a number of applications and, except for cases where a given process has a higher priority, all the processes typically get an opportunity for equal time from the CPU. A desktop system with a RT OS would also fit this description too, right?

      Now, given that: where's the RT aspect in all of this? What's actually RT in this situation? The pre-emptive multitasking loop? The UI event/response loop? The IO loop (assuming you could describe it that way)? The video update loop? What about this would give the user a better experience?
      • I think people are confusing real-time with "as fast as a bunny".

        A truly real-time system can actually be slower because even if it's ready to respond, it still has to wait until the appropriate time to do so. It like batting in baseball: swinging too early is just as bad as swinging too late.

      • Re:Not sure about this.. (Score:2, Insightful)

        by BGA ( 28170 )
        Being RT means it has predictable response times. If some specific operation is said to take 10 ms to complete you can count that as being always true and this is what makes RT systems special. That's why it would be *VERY* difficult to have a "partial" RT system like what you decribe. Either it is RT or it is not.

        That said, recently we had some flexibility on the Rt definition and we ended up with definitions for systems that are "hard RT" and "soft RT". The first case is what I described (QNX is hard RT,
        • I agree completely with your definition of a a real-time system. What I was trying to say is that a general purpose system can not, by definition, be real time about everything it does. Therefore, it would have to be real-time about some specific characteristic(s), and the rest of the system's performance would have to vary as needed in order to meet the actual RT requirements.
      • the UI event loop. On the process in focus (or wherever the mouse goes so that when you click there is zero perceived time between when you clicked and when the action takes effect.)

        For everything else, standard latencies are more than enough (like if you're watching a video in a window in the upper right corner, that's probably not going to skip just because the UI event loop is kicking in, and if it did the user still prefers to get the fast action response because that's where his/her attention is.)

      • If it is possible I would love to be able to somehow choose which parts of the OS have RT priority. So I could for example choose to only give the parallel port or specific applications RT priority and control servo motors on my desktop, make a crude oscilloscope or Real Time Halflife :) does anyone know if this is possible?
  • Linux based sharks with frickin' laser beams on their heads....

  • Victor Yodaiken if a Patenting Pest (Score:2, Informative)

    by Anonymous Coward
    Victor Yodaiken (who wrote TFA) is the clown who patented his technique for implementing RTLinux. I much prefer RTAI for real-time linux, both because it is IMO a superior implementation, a better license, and it doesn't give support or credibility to Yodaiken.

  • rtlinux (Score:1)

    by w98 ( 831730 )
    huh, another contender ... I'll have to check it out. I used to work at QNX [qnx.com] who also make a real-time posix-compliant OS, but it's geared more for embedded systems than desktop use (although it *can* be used on a desktop)

  • Laser Traps (Score:4, Interesting)

    by richardmilhousnixon ( 515595 ) on Wednesday June 08, 2005 @12:09PM (#12759398)
    I was under the impression that the whole idea of a laser trap is that you CAN'T drop the ball. Small particles get trapped in the beam due to photon pressure, if the particle shifts away from the center of the beam, it automatically is recentered. Then you can move the beam to manipulate the particle which is attached to a molecule. They use these to fold and unfold proteins, lipid layers, DNA, etc.

    I mean, it's great that they're using a realtime kernel, but they really shouldn't NEED it.
    • Its not that easy.
      Just for your information: the classical picture of a laser trap always presented actually is only a so called optical molasse, it will slow down molecules, but cannot trap them. (its actually quite obvious, think about the balance of force on the particle as its speed aproaches 0... it can be descriped by a modification of the stokes formula for objects in fluids)
      For real confinement, you need futher stuff, for example quadrupol coils for a penning type trap, ect.
      I dont know what exactly
    • ObRTFA: RTFA.

      They're timeslicing, using one laser to build multiple traps. So they trap one sphere, then switch to another, then back to the first before it drops.

    • Re:Laser Traps (Score:2, Informative)

      by ZagNuts ( 789429 )
      I was under the impression that the whole idea of a laser trap is that you CAN'T drop the ball. Small particles get trapped in the beam due to photon pressure, if the particle shifts away from the center of the beam, it automatically is recentered. Then you can move the beam to manipulate the particle which is attached to a molecule. They use these to fold and unfold proteins, lipid layers, DNA, etc. I mean, it's great that they're using a realtime kernel, but they really shouldn't NEED it

      From the art
  • I've made some use of RTLinux myself - one aspect that we got to wonder about is to which extent you can move the controller outside of the computer and into its own embedded device. In this case, it seems that it's the diversity of experiments that is the deciding factor for using the computer.

    It is a little odd that they talk about 1 millisecond, when the time between interrupts is 50 microseconds. To miss for "even" 1 millisecond would mean missing 20 interrupts! That's just some hype, IMHO. What I find

    • Re:delay tolerance? (Score:4, Informative)

      by ClosedSource ( 238333 ) on Wednesday June 08, 2005 @01:03PM (#12759964)
      Yes 1 millisecond is pretty slow. On the Atari 2600 we used to meet a .84 microsecond timing requirement with a 1.19 MHz processor.

      In any case I don't think many people on Slashdot understand that tough, classical real-time software can't really run on a PC (or Pentium processors for that matter) no matter what OS is used.

      The key to real-time software isn't speed, it's deterministic timing. Once you have a cache involved, it's pretty much game over. Unless, of course, your timing requirements are several orders of magnitude slower than the time it takes the processor to execute an instruction. In that case the non-deterministic behavior may be swallowed up by the large gaps between real-time events.

      Nevertheless there may still be the possiblity of memory management accessing the disk and blowing your timing away.
      • How about turning the cache off?
        • If the processor cache can be turned off, then that is at least one less hurdle. What about processor pipelines, bus locking, etc.? Can they all be disabled?

          Any non-deterministic behavior (or deterministic behavior too complex to be considered in a real-time software design) will still trip you up.
  • Sooo... basically they're using an operating system to do what they should have an FPGA perform?

    I mean, rah-rah-go-linux... but sounds like a dramatic over-use of power. Why one would use a modern OS to perform tasks that should be handled by dedicated hardware ... is beyond me.

  • Wrong title (Score:5, Funny)

    by Spy der Mann ( 805235 ) <spydermann@slashdot.gmail@com> on Wednesday June 08, 2005 @12:18PM (#12759485) Homepage Journal
    [note to mods: If you don't get the joke you should read the other headlines on today's index]

    Should read:

    "World's fastest Linux-based laser trap" ;-)

  • RT Linux fast enough for a juggler... (Score:2, Funny)

    by Anonymous Coward
    ...but does it have enough horsepower to generate a mime trapped in a box? I doubt it.
    • Next dupe/"follow-up" article on Slashdot: "RTLinux used to laser-trap mimes in boxes"
      "Finally, a valid use for Linux" a certain well-known OS development rival group was heard to say - apparently beleaguered by mimes performing outside their Redmond HQ for spare change, the possibilities of trapping mimes in boxes using lasers controlled by RTLinux has intrigued ...(read more)

  • molecule juggling available with FC3 (Score:4, Funny)

    by pomakis ( 323200 ) <pomakis@pobox.com> on Wednesday June 08, 2005 @12:22PM (#12759525) Homepage
    Fedore Core 3 comes with an application for juggling molecules. It's called "katomic". It actually allows one to assemble molecules from its constituent atoms. The miracles of modern science never cease to amaze me.
  • Gives a whole new meaning to BSOD, eh?

    You want a BSOD, eh? How about this: You build a gun that has an actuator attached to the serial port of a computer running Windows NT. The computer sends, via the serial port, a watchdog-style "keep alive" signal, say, every 100 microseconds. The actuator is designed such that once powered on, if the watchdog timer skips a single beat or delivers it too late, the gun is fired.

    At this time, a volunteer (say, Gill Bates) would be tied to a chair and placed in front of

    • Some rhetorical questions: Will you use Windows to manage a heart-lung machine? No? So why do you use it to run an Aircraft Carrier? Actually, since I'm not American, I think the US military and the whole government, should use MS Windows exclusively, for everything...

  • QNX - for really low latency (Score:5, Informative)

    by Animats ( 122034 ) on Wednesday June 08, 2005 @12:33PM (#12759628) Homepage
    Here's what comparable numbers look like for QNX: QNX [ddjembedded.com].

    For a 200MHz Pentium (this is an old review), the testers tried sending one billion interrupts with a latency check. When they required 8 microsecond latency, they missed one interrupt in a billion. When they only needed 10ms latency, they didn't lose any.

    Comparable figures are available for various real-time Linux systems. [linuxdevices.com] Note that these figures are for a 650MHz CPU. The times are slightly better than for QNX, but the CPU is 3x faster.

    Bear in mind that "RTLinux" programs aren't running under Linux. They're running below Linux. They can't make most system calls, for example. QNX programs are ordinary programs, and can make system calls.

    The Linux 2.6 kernel isn't bad, though. Running real-time with millisecond response as high-priority Linux threads can actually work in 2.6. In 2.4, no way. You have to be very careful not to load any high-latency drivers, though.

  • I juggle molecules all the time! (Score:1, Funny)

    by Anonymous Coward
    I juggle molecules all the time - In fact, I never juggle anything EXCEPT molecules.

    Of course, I usually juggle lots of them at once.
  • ...and the article is written by Victor YODAiken. Coincidence? I think not...

  • The Amiga had CPU clock-cycle-precise interrupts. IE, the very slowest 1985 Amigas (A1000) could throw interrupts every 1/7.16MHz seconds, or about 140 nanoseconds. 2005 Linux has an interrupt precision of 50 microseconds.

    Way to go, RTLinux! You are now only 2800 times slower than a 20 year old box. Not that any other system is better...

  • Bah! Come back to me when you can do it with sharks with frickin' lasers on their heads!

  • Tetris with micro beads. (Score:3, Interesting)

    by ezzzD55J ( 697465 ) <slashdot5@scum.org> on Wednesday June 08, 2005 @01:52PM (#12760489) Homepage
    A friend of mine implemented tetris using a laser to trap 1 mirometre glass beads. Short story + picture + video here [nat.vu.nl]. More explanation here [nat.vu.nl].

  • Foreget Linux, Lets Hear it for Physics! (Score:4, Interesting)

    by frenchs ( 42465 ) on Wednesday June 08, 2005 @03:08PM (#12761259) Homepage

    How interesting. I just saw a lecture by one of the men that won a nobel prize [nobelprize.org] for this very thing, Steven Chu [stanford.edu]. What is being done here is essentially what is called Optical Tweezers [stanford.edu].

    The way this works is that the laser is fired, in timed pulses at a molecule. When the laser hits it from an opposing direction, it starts to cancel out the kinetic energy that the molecule has, and therefore cooling it. (I think it was something to the order of 2.0 × 10^-06 degrees above absolute zero).

    In a nutshell, this is what is going on:
    Almost Absolute Zero == Essentially No Movement == Essentially "Frozen" Object

    -Steve
  • If the computer failed to respond, for even a millisecond, then we would drop the balls...

    Not a very patient porn-surfer, are we? :)

Slashdot Top Deals

You can not win the game, and you are not allowed to stop playing. -- The Third Law Of Thermodynamics

Close