LWN.net Weekly Edition for November 1, 2012

RTLWS: Realtime Linux for aircraft

While there was much discussion about realtime Linux at this year's Real Time Linux Workshop (RTLWS)—unsurprisingly—there were few presentations on actually using it. Karl Kufieta's talk on how the realtime kernel was used for aircraft control was one of the exceptions. Kufieta described both the hardware and software components used by him and his colleagues at the University of Braunschweig to develop a Linux-based unmanned aerial vehicle (UAV).

Several different aircraft designs have been used by the University over the years, Kufieta said, for applications ranging from agricultural surveying to boundary layer measurements in Antarctica. Their designs go beyond traditional aircraft to, for example, a helium balloon that won an international challenge to navigate into a building and out through its chimney.

As might be guessed, weight is an important factor. They chose a Gumstix board with an OMAP 3 for the main processor, with a separate data acquisition processor for sensor data. That setup weighs 60g including the GPS antenna. It currently draws less than 2.5 watts, but that should come down once they figure out how to use some of the OMAP power-saving features, he said.

The main processor handles the control algorithms, image processing, and navigation. The data acquisition processor talks to various sensors, actuators, gyroscopes, the GPS, and so on. The two processors communicate over an SPI bus. Depending on the application, there can be more than one data acquisition processor, all of which communicate via CAN bus. In that scenario, one of the data acquisition processors communicates all of the sensor data to the OMAP via SPI messages. This design allows switching to different main processors without changing the design of the rest of the system.

The system is programmed using Simulink, which is an object-oriented simulation and modeling language with a drag-and-drop GUI interface, Kufieta said. It is integrated with MATLAB, which was used to develop some of the navigation and control code. Simulink can generate C code, which can be targeted to run atop an operating system (i.e. on Linux on the main processor) or to run without an operating system for the data acquisition processors. GCC is then used to build the generated code for the ARM processors.

Their goal was to run the Simulink code, particularly the Kalman filter used for navigation, on realtime Linux. To do so, they used the Simulink Real-time Workshop combined with the 2.6.33.9 realtime kernel. Linux has lots of advantages for the project over various commercial alternatives, including drivers for many of the devices (e.g. webcam, WiFi, UMTS), libraries for image processing and other needed tasks, along with support for SSH and other network protocols. The disadvantage is that it "may be a bit complex", and that the delays in thread execution might be too large for their needs.

As it turned out, their testing showed an upper bound of 62µs for the thread execution delay. That was using a "super simple model", but even when running thousands of these simple realtime tasks, the WiFi was still working well, 500-byte SPI messages could be sent in less than a millisecond, and the non-realtime data logging component, which writes debugging data to an SD card, was able to keep up.

To control an airplane, there is a wide variety of complex code that needs to be run. There are equations to turn the various forces measured by the sensors into vectors. The navigation information then needs to be used to determine what kinds of changes to make based on the current position and attitude of the plane. Position and attitude information is derived from a number of different sources, including GPS, an inertial measurement unit (IMU), accelerometers, gyroscopes, and pressure sensors. Those measurements feed into a model that is used to control the actuators to fly the plane.

The Kalman filter is used to rectify the high-frequency, lower accuracy data from the IMU, accelerometers, gyroscopes, and so on, with the low-frequency, but much more accurate GPS data. The IMU and other data can be sampled at 1kHz, though they are currently sampling at 100Hz, while the GPS data is available at roughly 1Hz rates. The Kalman filter then combines that data (along with an estimate of its accuracy) to determine position.

The processing is broken up into several realtime threads, each running at its own realtime priority, based on 10ms slots. The highest priority task reads the UART (IMU and GPU) and SPI bus (other sensors), while the others implement processing with a granularity of 100Hz, 10Hz, and 1Hz. In addition, when the GPS reading is available, that wakes up another thread that may take more than 10ms, which means that it will span multiple slots. The time budget was tight, Kufieta said, until they turned on optimization; now the whole model can run with only 60% CPU utilization on the OMAP 3.

So far, all of the testing has been ground-based, using Simulink's "external mode" to simulate the inputs, and observe the outputs. That allowed the team to "see it fly" in a simulated environment. The first flight tests are planned for later this year. But the question they set out with—"can we run this on realtime Linux?"—has clearly been answered in the affirmative.

[ I would like to thank OSADL and the RTLWS for supporting my travel to Chapel Hill for the conference. ]

Comments (11 posted)

Collaborative coding with Collide and friends

Google became the latest entrant into the online code editor races in July, when it released Collide as an open source project. Collide is a lightweight integrated development environment (IDE) that is notable for its support of concurrent editing by multiple users. Although its feature set is slim in comparison to some of the more established offerings, it might still find a niche role to fill — if only because the competition is equally limited when it comes to key features like collaboration.

Originally, Collide was a project that Google was reported to be developing as yet another public service among its existing throngs of web applications. Thomas Claburn at InformationWeek speculated that it was the "Brightly" IDE for Google's Dart language, although Brightly was not announced officially; reports of its existence stem from mentions in a forwarded internal email. Whatever Collide was originally intended to be, however, it will never become. Google closed down the branch office that was developing it in July 2012, and the code was released under the Apache 2.0 license by developer Scott Blum.

Blum has continued to post and respond to questions on the project's Google Groups mailing list, but development has slowed to a trickle. Nevertheless, the application is trivial to install. It requires Java 7 on the machine that will act as the server (i.e., hosting the files to be edited); clients access the editing session from their browser. Exactly which browsers are compatible remains a tad murky; some users have reported success with Firefox while others have not. Chrome and Chromium are the safe choices.

Edit-o-rama

The code is provided as a tar archive that can be unpacked and launched without system-wide installation. The launcher is a shell script named collide; although there is no documentation, reading the script reveals that you can specify a session password by appending -password=foo . This is an important distinction because one must specify a password in order for users on other machines to join in. The script starts up a web server session running locally on port 8080; without password protection, only connections from localhost are accepted.

Collide presents a sign-in screen to every browser, either asking for a name or for a name followed by the password, depending on whether a password was assigned at start-up (users can enter any identifier they want for the name, since it is only used to identify them to other participants in the session). From there, all users have a tree view into the directory from which the server was launched. A collapsible user list sits in the lower right hand corner, in which you can see the self-selected user names and (more importantly) Collide-assigned colors of everyone in the session. The actual editing features provided are respectable: line numbering, syntax highlighting, auto-completion, and real-time file tree manipulation (meaning that added, deleted, and moved files are relayed to all of the clients immediately, without requiring a reload).

From a collaboration standpoint, the editor relays changes faster than one can type, which is about the only real requirement. Granted, Collide does not offer TLS/SSL encryption or strong authentication, so it is most likely to be used in LAN environments where latency is not an issue. The UI only distinguishes between concurrent editors by altering the cursor color, however. This makes it harder to keep track of where other users are in the document than it is in other collaborative editors (some of which, for example, use different text background colors for each user).

There is also a Collide extension available for Chrome that adds JavaScript debugging and real-time editing of "live" CSS. Currently JavaScript, Python, CSS, and HTML are the only languages supported by the syntax highlighter, although there are hooks for enterprising developers to add others — incomplete highlighting code for Dart and XML is buried in the source tree.

Reportedly, there were other features that had been working while Collide was still an active internal project, but just did not make it through the cleanup process before the code was released to the public — including showing other users' text selections. The team decided to forgo implementing persistent user identity and authentication in light of the fact that there are already hosted web services that offer that functionality.

Everybody, edit now

As it is, Collide provides a fast-and-dirty editing option for locally-connected teams or for pair-programming exercises. Developers using Collide will already have to have another means of discussing what they do — either out loud or through other chat applications. But if that list of restrictions sounds like it makes Collide a weak offering, consider that the other major collaborative code editors are equally limited in one way or anther.

The most widely discussed in recent years was Mozilla's Bespin. As invariably happens to the browser-maker's projects these days, Bespin underwent Mozilla's spontaneous-renaming process, becoming Skywriter, then it was shut down. But the code was handed over to the ACE editor, which sits at the heart of the popular Cloud9 collaborative editing service.

ACE offers a similar in-browser editing experience to Collide's, plus additional features like breakpoints and code folding (i.e., collapsing blocks of code for the sake of readability), but its collaboration features are an add-on implemented by Cloud9. Although real-time collaboration was a feature during the project's tenure at Mozilla, it is not supported in the downloadable version. ACE is also designed to be an embeddable component served by an existing web server; it is not built for rapid deployment or ad-hoc usage. Mozilla's Kevin Dangoor told one ACE user that interested parties would be welcome to contribute real-time collaboration code, but that was in early 2011, and there does not appear to have been any progress on that front since.

Of course, there are numerous other open source online IDE projects. Adobe has Brackets, which is focused on supporting HTML and JavaScript. The Eclipse project has Orion, which is arguably the closest in design to Collide, in that it can run as a local Java server without the prerequisite to start another web server. Orion incorporates code validation, cross-file searching, and a number of other helpful features, but collaborative editing is not among them.

With the other projects outstripping Collide in terms of traditional IDE features; Collide's primary strength is its multi-user editing. But it does not look like the project has any forward momentum of its own, and in spite of Blum's early comments, there has not been substantial further development. On the contrary, Collide developer Jaime Yap said on Google Plus that

But at this point, it simply does not look like the other web-based IDE projects are interested.

The reason why may be obvious to anyone active in an existing open source project — real-time collaborative editing's main competition is the simplicity offered by distributed version control. There may be a handful of situations where having multiple developers working on a single chunk of code all at once is advantageous, but it is far from the norm. Real-time collaboration requires that the participants work simultaneously and at the same pace, and it makes separating out individual contributions difficult or impossible. Apart from dedicated hack-a-thon events or tutorial sessions, this simply is not the most efficient way for individual developers to work.

Nevertheless, for hack-a-thons and tutorials, Collide could prove to be a valuable asset. There is little administrative overhead and a connection to the outside Internet is not required. It would be gratifying to see Collide take on a new life as an open source effort; some have noted that it builds on the real-time features of the "love it or hate it" Google Wave, which itself is now an Apache Incubator project in search of a killer application. But more likely is a future where Collide joins Wave among the ranks of "slick ideas that never took off" — an unfortunate fate, and one made worse by the fact that the other online IDE projects have yet to deliver an equivalent to Collide's key feature.

Comments (13 posted)

Roll your own fundraising drive with Selfstarter

Free software projects in search of a fundraising model now have yet another alternative to consider: Selfstarter, a Ruby-on-Rails application built to emulate Kickstarter-style donation drives in a self-hosted environment. It provides a simple crowd-funding framework, but one that can be adapted to a number of fundraising scenarios. Although it is not the only free software option, it does have its advantages.

Fundraising for free software development has been a popular topic of late. In August, we covered Adam Dingle and Jim Nelson's survey of the available approaches at GUADEC, which centered on a comparison between the popular pre-funding donation model used at Kickstarter and the pay-what-you-like post-funding model used by the Humble Bundle. In September, we looked at Bradley Kuhn's report at LinuxCon North America about the Software Freedom Conservancy's (SFC) successful drives to raise funds tied to specific developer contracts.

MediaGoblin and constituent-relations-management

Since then, at least one well-known project has launched a large-scale campaign of its own: Chris Webber, lead developer of the MediaGoblin web publishing platform, is trying to raise funds to support himself for one year's worth of full-time development. As Webber explained on his blog, the campaign is run through the Free Software Foundation (FSF), but it required some engineering effort to support several features missing from the FSF's base fundraising platform. Specifically, Webber wanted a donor rewards system, the ability to send email updates to donors, and an automatically-updating "progress bar" that tracked the total as pledges came in. All three features are found on the Kickstarter platform. In addition, Webber wanted a custom theme to match the MediaGoblin site, which of course is not supported on Kickstarter.

The software powering the donation drive is CiviCRM, which the FSF adopted in 2010, after having promoted its development as a "high priority project" for several years. CiviCRM is used by several other organizations in the free software community, including the GNOME Foundation, Wikimedia Foundation, and Mozilla. In an email, Webber noted that some of the CiviCRM modifications used to deploy the MediaGoblin drive were trivial — such as the progress bar, which uses a simple AJAX query to the CiviCRM back-end.

Whether the remaining changes constitute an interesting enough module to make into a formal extension or patch set remains an open question. "I think we did a good job of making something that was feature-compatible with Kickstarter, but part of that was also working on things as in terms of looks," he said. "I'd be interested in someone building on that work to make something that people could much more easily click-and-go make a fundraising campaign. Would CiviCRM be a good fit for that? It seems like it's working well for us, but then again, I'm not the one running it."

CiviCRM is a not a lightweight package; it is intended to serve as a "relationship management" system over the long term — which in human terms means multiple years. It also needs to be integrated with another content management system like Joomla! or Drupal; installing and maintaining it introduces considerable overhead if all one is interested in is a one-shot fundraising drive.

Self-starting start-ups

In contrast, the Selfstarter application is designed for rapid deployment. The company behind its development is Lockitron, a start-up created to build and sell a smartphone-based keyless door lock system. When the company's project proposal was rejected for inclusion on Kickstarter, the team wrote a work-alike and hosted the fundraising drive independently. The drive was evidently a success; the site reports that well over 1400% of its target amount was raised, and the entire first round of pre-orders is sold out.

Selfstarter is built for Ruby 1.9.2, and is designed to be deployed on production servers using Heroku (although Heroku is optional, but recommended). The code is available from a GitHub repository; after cloning the repository the basic setup can be installed with bundle install --without production and the necessary databases (by default, SQLite) created with rake db:migrate, both of which should be old hat to Rails developers.

Fresh out of the box, Selfstarter does require quite a bit of customization. The config/settings.yml file includes all of the campaign settings, from the project name and fundraising goal to the strings displayed for the various messages (for example, whether donors are called "donors" or "backers," and the note explaining what to expect when the campaign ends).

Selfstarter supports only Amazon payments, though the README file explains that this and several other limitations were choices made for simplicity when Lockitron wrote the application for its own campaign. Similarly, it supports embedding Vimeo videos, using Google Analytics, and has configuration variables for Facebook and Twitter "share buttons."

Adding support for additional payment systems, video embedding, and sharing services are all among the first requests filed on the issue tracker. They will probably not prove difficult, but the fact that the current values are hardcoded in simply illustrates that Selfstarter is a young project that still requires manual configuration. The same is true of the theming and CSS styling; all of the media assets and stylesheets are simple to locate, but radically altering the layout of the pages will require a bit more work.

The area in which Selfstarter really needs further development is in its support for different styles of campaign. The Lockitron campaign is built around a single product, offered at a single price. That may work well for the majority of product-driven drives, but it does not offer donors the choice of levels that many Kickstarter campaigns use to "up-sell" potential backers. Tracking donor movements between levels and statistics on average donations is unimplemented. Selfstarter is also built around the assumption that the campaign is an all-or-nothing funding proposition (that is, if the target amount is not met, no one will be charged). This is the Kickstarter model, but others may prefer to take a different approach.

Selfstarter also does not implement user accounts, strong authentication, or provisions for emailing donors. The value of features like emailing donors is debatable, although it is a popular way to keep buzz alive in Kickstarter drives. The developers do say that they welcome patches for these and other features, however.

Getting your kicks

With its current feature set, Selfstarter has the makings of a decent funding platform for independent projects. But independent projects are hard for potential donors to discover — a drive run by a well-known entity like the FSF is likely to garner discussion, but for new projects, waiting for visitors flush with cash to stumble across the campaign site is a worrisome proposition.

One intriguing possibility on this front was raised in a thread on the Selfstarter issue tracker. User elf-pavlik asked whether Selfstarter could be merged with the similar open source crowdfunding project Catarse. Diogo Biazus from the Catarse team replied that Selfstarter's identity as a self-hosted fundraising platform made it significantly different from Catarse's model, which involves maintaining a curated stable of multiple projects. But the two could still find a way to interoperate, he said:

That concept is interesting because it would help any free-software-focused crowdfunding efforts balance the benefits and risks of going-it-alone. As Dingle observed in his GUADEC talk, a pool of multiple fundraising projects hosted at one site is easier for users to find, but it makes smaller and less well-known projects harder to find on the site itself, because the "cool" projects grab most of the attention. The possibility of a hybrid model, where individual projects could run their own campaigns but still be accessible from a central service, might help.

Of course, regardless of whether the campaign is self-hosted, run by the FSF, or promoted on a specialty Web service, the trickiest part of the fundraising drive is not the software component — it is marketing the campaign to donors and convincing them to open their wallets. Selfstarter and similar efforts cannot do that part, though they can take developers' minds off of the implementation problem, which is at least a start.

Comments (2 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Holes in SSL certificate validation; New vulnerabilities in exim, java, kdelibs, mozilla, ...
• Kernel: NUMA scheduling; Relocating RCU callbacks; Thoughts on the ext4 panic.
• Distributions: Fedora and LVM; Yocto, Linaro, sposkpat, ...
• Development: Processing 2.0; Motif; Opened Captions; ARM64 OpenJDK; ...
• Announcements: Jailbreaking legal for smartphones, not tablets; Privacy in Ubuntu 12,.10; LPC 2013; ...