While there was much discussion about realtime Linux at this year's
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
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
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
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
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
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
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
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 126.96.36.199 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
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
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)
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
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.
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
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
to forgo implementing persistent user identity and authentication in light of
the fact that there are already hosted web services that offer that
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
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,
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
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
We want the Collide opensourcing to serve as reference implementations
for cool technologies, features, and interaction concepts we want to
see exist in actual web-IDE services. These existing web-IDE services
could leverage technology in the Collide stack. Longer term, some
enterprising group could fork the Collide codebase and use it to
bootstrap their own competing service.
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
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
Comments (13 posted)
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
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
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
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.
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
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
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
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:
So, why not create a channel in Catarse, where we could receive
projects from the Selfstarter? In this fashion, Selfstarter could
evolve to be the Catarse's entry point to new projects (as an Engine)
without losing it's original identity of simple-project platform.
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; ...