Domain: fsmlabs.com
Stories and comments across the archive that link to fsmlabs.com.
Stories · 6
-
Build Your Own Soccer-Playing Robot
An anonymous reader writes "This article by a Ph.D student at Shanghai JiaoTong University (SJTU) Research Institute of Robotics describes an RTLinux-powered robot that placed fifth in the most recent RoboCup competition. The robot has two color cameras for visual sensing along with a laser range finder (LRF) for goalkeeper location, and a wireless LAN allows communication among the robots on SJTU's team. The robot's embedded operating system is Red Hat Linux enhanced with the RTLinuxPro real-time extension." -
Software Tweak Makes Linux Boot In Under 200 ms
An anonymous reader writes "A version of Linux has been created that radically speeds up system boot time -- to less than 200 milliseconds (ms) from power-up to application code startup. The techniques, created by Real-time Linux vendor FSMLabs, are processor independent, and boot times of under 100 mS are expected in the future." Update: 09/30 01:04 GMT by T : Yep -- both headline and post should have read "ms" (milliseconds) rather than "mS" (milli Siemens); thanks to all the alert readers. -
Real-Time Linux Experiences?
fidget42 asks: "I was wondering what types of experiences people have had with using some of the 'real-time' variants of Linux. I have looked at some of the choices (RTLinux, RTIA, etc.) but would also like to tap the experiences of the Slashdot readers. I am not looking for an embedded solution (while I will be on a single board computer, it will not be for a 'set-top box'), but one that will live happily on a PowerPC running in a VME chassis or something similar. Have you had good luck controlling VME devices from within a real-time Linux system? What problems did you encounter? While I do not need to run hard real-time, I still need tight tolerances on my timing. Our current platform gives us 5ms of jitter per 50ms cycle (very bad) and we would like to get down to 0.5ms, or less, of jitter per 50ms cycle. I also need guaranteed deadlines. One vendor told me that '97% of the time, you should be able to make the deadline' but 97%, and should, is still not good enough. Any and all help would be appreciated." -
RTLinux Patents: Issue Closed?
Anonymous Coward writes "LinuxDevices.com reports that the Free Software Foundation has reached an agreement with Victor Yodaiken which resolves what FSF considered to be a violation of GPL by the Open RTLinux Patent License. Details are not yet available, but it sounds like the clause in the license which required users of RTLinux to keep records and provide them to FSMLabs on demand was the principal source of the violation, and that the requirement is being dropped from an updated version of the RTLinux license that will be published in the next day or two. All in all, it seems like the FSF has successfuly enforced the GPL even though it was neither an owner nor co-owner of the software (i.e. the linux kernel) whose license terms were being violated. It's interesting to see this practical example of FSF in action, and bodes well for the future of GPL -- at least in a small way."crimoid points to ZDNet coverage of the FSF's criticism of RTLinux's licensing terms, written before such a resolution was clear. Sourceforge on Thursday quoted RTLinux CEO Victor Yodaiken, CEO as saying that his company is happy to change "minor problems" with the RTLinux license, and that discussions are still going on with the FSF about those changes.
-
FSMLabs announces RTL/BSD
-
The Silent Kernel Platform War?
iJosh asks: "Recently I decided to be hip and cool and update to the latest Linux Kernel (v2.4.1). Since this decision I've downloaded and tried to compile the offical source from Linus and crew on my PowerMac 7300 only to run into errors for the PowerMac PCI controller. I took this up with Paul Mackerras maintainer of the PPC kernel and his response was quite interesting to say the least and it got me thinking. He basically says that Linus is ignoring the patches from the people working on the PPC side of the kernel, and that they are keeping their own tree so people are not stranded out in the dust with kernels that will not work. My question really comes down to this: Is the linux kernel forking away from PowerPPC? Is this happening because of issues regarding OS X and the possibility of many users jumping ship, away from LinuxPPC upon release? Or is this some kind of quiet platform war from the major kernel developers?"