Getting into RC Helicopters

Everything started when I got myself a coaxial RC helicopter for Christmas. I was playing with the idea for quite some time, and the moment seemed perfect to waste some money. Since then I have learned quite a lot about how helicopters work an by now I have moved on to a more capable helicopter. Unfortunately it is also more expensive to fly.. This post shall explain some general topics about RC helicopters which are useful if you are also considering getting a RC helicopter yourself. One can already get a small indoor RC helicopter for about 30€, but most likely you will get bored flying it after a few days. If you want to have something that lasts longer, there are some things you should consider, which we will discuss next.

 The remote Control

The idea to buy an helicopter first came up, when I saw an Infra Red (IR) controlled coaxial helicopter RC in a local coffee shop. It came with an traditional Remote Control (TX) as well as an IR module attachable to the headphone jack of my smart-phone. While the idea to control the helicopter with your phone sounds cool in the first place, it actually is not. If you ever tried to play a game with a digital-controller on the touch-screen, you will know what I mean. As there is no haptic feedback it is very difficult to give precise input without looking at the touchscreen all the time. So the smart-phone module is actually quite a useless gadget.

The other problem with that package is the Infra Red transmission technology – basically the same you have in your TV remote. Therefore it also suffers from the same shortcomings; if there is an object between you and the helicopter it is pure chance if it will receive a signal or not. Next the transmission is quite sensitive as there are many natural IR source around like the sunlight, heat or even light-bulbs. As one wants the transmission as reliable as possible, you should avoid IR remote controls.

An infra red controlled helicopter - dont get one of these.
An infra red controlled helicopter – dont get one of these.

An alternative transmission technology is radio in the 2.4Ghz spectrum, which is not only more reliable but also has a larger operation range. Fortunately 2.4Ghz radio controllers are not more expensive than the older IR controllers, so pay attention to get one of these. If you want to learn more on the used radio technology I recommend the Wikipedia article on Radio Gear.

How many channels do I need

Looking at the offered helicopters some are advertised as 3 channel or 4 channel. But how many channels do you need? First lets take a step back and explain what channel actually means in this context. Lets look at a simple remote controlled car for this. It can either go forward or backward and left or right. The important word here is “and”. As the car can go for instance forward and left, we need two independent communication channels: one for steering and one for acceleration.

Obviously a helicopter needs more channels; besides steering and accelerating forward and backward it can also lift or fall (throttle). So we need at least 3 channels to be able to do something with it. Now steering left and right can mean two things in the case of helicopters. Either you can rotate around the main rotor axis (yaw) or go straight left or right along the horizontal axis (cyclic bank). Therefore you need 4 channels to be control all possible movements of the helicopter.

Directions you can steer in a 4 channel helicopter
Directions you can steer in a 4 channel helicopter

But even though 4 channels are enough to control the movements, you actually need 5 channels to fly advanced manoeuvres like flying upside down or flying loops. You can think of the 5th channel as the gear stick in the car which changes the transmission. For helicopters the transmission roughly corresponds in the pitch of the rotor blades – and this is exactly what the 5th channel is for. But to fully understand why you need it, you have to understand how the physics of a helicopter work.

How real helicopters work

Instead of explaining all the theory by myself, I rather point you to Destins “Smarter Every Day” Series. They are really entertaining to watch and you get to know everything you need about RC helicopters physics – they are actually using a RC helicopter to explain the physics behind real ones.

You probably noticed that real helicopters are also quite fragile if not handled properly. That aside you should now also know that the 5 channel helicopters are called collective pitch and which manoeuvres you can do with them.

So what should you buy

After watching the 3D flight demos above, you probably want to go with a collective pitch helicopter straight ahead. But remember that it probably took the pilot years of practice and hundreds of € in spare parts to learn how to fly like that. There will be no “inverted flight” button on the remote control. Therefore you probably should start with a cheap 4 channel helicopter to see whether you enjoy flying enough to spend more time and money on it. The only thing you should observe with your first helicopter is that there should be spare parts available. Otherwise your first crash might cost you the whole 30€ of the helicopter instead of just 5€ for a spare rotor blade. This does not mean you neccesarily have to buy from a brand, which is more expensive. I ended up with a coaxial helicopter called “super uncommon 9998″, which could use the spare parts of the e-flite blade MCX system.

You should practice the basic manouvers with that cheap helicopter, as it will survive more crashes due to its slower flight speed. I recommend the rchelicopterfun youtube tutorial for an overfiew of exercices. You will need a collective pitch flybarless helicopter for the later ones, but you can do the first ones with a coaxial helicopter just as fine.

Once you are hooked up and decide to buy a more expensive collective pitch helicopter, you might be interested in my experiences with the Nine Eagles Solo Pro 125.This was just a small outline of the broad RC helicopter topic. If you want to know more I recommend you the excellent rchelicopterfun website.

Debugging native code with ndk-gdb using standalone CMake toolchain

I recently ran into this problem and could not find any good solution on the Internet. So next comes a small summary of the problem with hopefully enough buzzwords, so Google can lead you here.

If you want to do C++ development on Android, you need the NDK for cross compilation. It comes by default with its own build system called ndk-build, which basically is a bunch of custom makefiles. But if you are sharing code between the Android Platform and lets say plain Linux, you have likely already a build system installed. For C/C++ CMake is quite popular as it supports different platforms and compilers. Fortunately there is already a project which adds Android support to CMake. I will not cover that – instead I assume you are using it already.

Unfortunately you cant use the ndk-gdb script supplied with the NDK to debug your application as it relies on the behaviour of ndk-build. But as said earlier, ndk-build is no wizardy, but just a bunch of scripts. So it is possible to emulate the behaviour using CMake, as following:

Add the following macro to your CMakeLists.txt file

macro(ndk_gdb_debuggable TARGET_NAME)
    get_property(TARGET_LOCATION TARGET ${TARGET_NAME} PROPERTY LOCATION)
    
    # create custom target that depends on the real target so it gets executed afterwards
    add_custom_target(NDK_GDB ALL) 
    add_dependencies(NDK_GDB ${TARGET_NAME})
    
    set(GDB_SOLIB_PATH ${PROJECT_SOURCE_DIR}/obj/local/${ANDROID_NDK_ABI_NAME}/)
    
    # 1. generate essential Android Makefiles
    file(WRITE ${PROJECT_SOURCE_DIR}/jni/Android.mk "APP_ABI := ${ANDROID_NDK_ABI_NAME}\n")
    file(WRITE ${PROJECT_SOURCE_DIR}/jni/Application.mk "APP_ABI := ${ANDROID_NDK_ABI_NAME}\n")

    # 2. generate gdb.setup
    get_directory_property(PROJECT_INCLUDES DIRECTORY ${PROJECT_SOURCE_DIR} INCLUDE_DIRECTORIES)
    string(REGEX REPLACE ";" " " PROJECT_INCLUDES "${PROJECT_INCLUDES}")
    file(WRITE ${PROJECT_SOURCE_DIR}/libs/${ANDROID_NDK_ABI_NAME}/gdb.setup "set solib-search-path ${GDB_SOLIB_PATH}\n")
    file(APPEND ${PROJECT_SOURCE_DIR}/libs/${ANDROID_NDK_ABI_NAME}/gdb.setup "directory ${PROJECT_INCLUDES}\n")

    # 3. copy gdbserver executable
    file(COPY ${ANDROID_NDK}/prebuilt/android-arm/gdbserver/gdbserver DESTINATION ${PROJECT_SOURCE_DIR}/libs/${ANDROID_NDK_ABI_NAME}/)

    # 4. copy lib to obj
    add_custom_command(TARGET NDK_GDB POST_BUILD COMMAND mkdir -p ${GDB_SOLIB_PATH})
    add_custom_command(TARGET NDK_GDB POST_BUILD COMMAND cp ${TARGET_LOCATION} ${GDB_SOLIB_PATH})

    # 5. strip symbols
    add_custom_command(TARGET NDK_GDB POST_BUILD COMMAND ${CMAKE_STRIP} ${TARGET_LOCATION})
endmacro()

Then use it like

add_library(YourTarget ...)
ndk_gdb_debuggable(YourTarget)

You should now be able to use ndk-gdb with CMake, just as if you would have used ndk-build.

Note that steps 4 and 5 are optional for debugging. They just reduce the size of the library that has to be transferred to the device. If you dont care, you can just leave them out. But then the solib search path from step 2 must be set to:

file(WRITE ./libs/${ANDROID_NDK_ABI_NAME}/gdb.setup "set solib-search-path ./libs/${ANDROID_NDK_ABI_NAME}\n")

Ideally someone should integrate that in the Android toolchain linked above.

Update Merged Upstream

GNOME Project suffering the NIH disease

When I first read about GNOME dropping support for BSD and Solaris, my impression was that this is a good idea to aiming to unify limit resources and get the work done. I was also excited about the idea of the GNOME OS. I think it is necessary to keep the big picture in mind when developing the different components. Previously Ubuntu was the only project that did this and it was also the reason why I started using Ubuntu. Because it made the different parts of Linux work together to achieve the big goal of a great overall system.

But then things started to go wrong. Instead of picking existing components and giving them the final polish like Ubuntu did before, the GNOME project started developing things from scratch without any apparent reason to do so. And even worse: incompatible to existing solutions. It started with the rejection of the appindicator specification implemented by Ubuntu and KDE. At that point it was not clear to me whether the specification was broken or whether the responsible people at GNOME were just ignorant.

Then came systemd. And it started to be apparent that unfortunately it was the latter. To my knowledge Ubuntu is the biggest deployment of GNOME and it is based around the Linux ecosystem. So dropping support for Ubuntu has nothing to do with unifying limited resources. Ubuntu is your target audience, so if you should try to collaborate with a project you should collaborate with Ubuntu. My opinion on that is that some Fedora developers were pissed that the Unity interface was exclusive for Ubuntu and instead of packaging it for Fedora they started making GNOME Shell exclusive for Fedora.

Next I read about the overlay scrollbars re-developed for GNOME. While the first reaction might be the developers simply do not want to use Ubuntu technology, I think the reason is different. The developer does not seem to have any antipathy towards Ubuntu and if we look at the project he developed the scrollbars for another explanation becomes visible.

But first lets take a step back. Lets take a look at the core of GNOME. By this I mean the programming language it is written in. It is C/GObject; plain C extended with naming conventions and libraries to allow modern paradigms such as object oriented programming and events/ observer pattern. From today’s perspective one might wonder why one should choose this over C++, which integrates most of the features at the language level. But back when the GNOME project started C++ was not mature yet which meant that your program might break with the next compiler update or even the next STL update.

Therefore basing your project on plain C was a good idea. But a few years back it became obvious that programming in C/GObject seriosly lacked behind more modern programming languages like C++, Java and C# for application development.

Unfortunately instead of moving the straightforward route from C to C++, which most of C developers took when C++ matured(that was about 10 years ago), Vala was born.

So instead of using a proven and mature foundation, a new layer of indirection was created to essentially provide the same feature set. Commonly this is referred to as the “not invented here” symptom. A more derogative phrase would be reinventing the wheel..

What is sad here is that being an open source project, GNOME disregards the biggest advantage of open source software, namely standing on the shoulders of giants. With open source software you can use take an existing solution and improve upon it. This way you get the base functionality as well as the bug fixes that went in it for free. If you would develop it from scratch, you most likely would have to fix the same bugs again yourself.

To sum up here is what GNOME is losing right now

  • 30 years of language and library experience by using Vala instead of C++
  • 5 years of deployment and bug fixing by using systemd instead of extending upstart
  • 1 year of development testing and design if they reimplement overlay-scrollbars
  • 8 years of foundation development that went into Eclipse, by developing Gnome Builder from scratch
  • but most importantly: the synergy effects by collaborating with others

Do not get me wrong, I am not saying that the GNOME solutions could be replaced by existing solutions – I am saying that by extending existing solutions the GNOME project and the free software landscape would be better off as a whole.

Teatime Updated for Oneiric

In case you have been holding back the update to oneiric until all programs are ported, you have now one reason less. Teatime has now peen ported to oneiric and is available in my PPA.

Maybe the most obvious change is that it now uses a different icon. The simple reason behind this is that the old one is no longer available in the oneiric icon set ;)

But as this is the first update since my initial post about teatime there are also some visible (audible changes)

For the python developers among you

As python was already written using GObject introspection on Natty it automatically picked up GTK3 with Oneiric, so no porting was required here. Great news if you were afraid of the GTK2 to GTK3 transition.

But unfortunately the GIR python bindings are not as stable as I would like them to be. The code that worked flawlessly with Natty stopped working on Oneiric with some awkward error message. (I am still not sure whether GIR or GTK3 is to blame)

Tea Time: Main Window

Intruducing Teatime

Since Unity does not support panel-applets any more, I also could not use timer-applet, which I used as an egg-timer. After several 30min “brewed” teas, I finally decided that I needed an replacement. So I started writing Tea Time.

Tea Time: Main Window

Instead of just porting timer-applet to the indicators API, I wrote Tea Time as an ordinary program and use the features of Unity instead, so I could take at the new APIs along the way.

Besides I think that porting every possible applet from gnome2 to the indicators API is not the way to go. The top-right of my screen is pretty cramped again already and one really does not need to see the timer information all the time. I hope Unity will get a Dashboard similar to the one in OSX soon, as this is really the place where most of the applets belong. But for the time being I used the Unity launcher.

When a timer is running, a progress bar is displayed

So when you click on Start Timer Tea Time minimises to the launcher instead of the notification area and starts displaying a progress bar. I also added the time elapsed since the timer finished to the notification bubble.

The notification also tells you how long the tea has already waited for you

So in case you miss the first notification(did not look at the PC for instance), you now instantly see whether you can still drink your tea or whether you can instantly pour it away.

Tea Time is as usual available from my PPA.

The nicest thing is that all of this fits into just about 250 lines of python. :)

YouAmp update

After upgrading to natty and discovering Banshee I basically stopped YouAmp development as Banshee basically fulfilled all my requirements and bringing YouAmp on par to Banshee feature-wise would cost me at one year of work – fulltime.

But recently I got more and more annoyed by Banshees slow startup-times and since I wanted to hack on python again anyway I dug out the youamp sources again. So these are the news in the YouAmp version available in my PPA right now:

  • SoundMenu integration (only tested on Natty)
  • Shares cover-art library with Banshee, to avoid duplication
  • Updated translation from Launchpad

So in case you are looking for something more lightweight than Banshee, you can take a look…

Announcing GLUT CPP

Have you ever written anything using GLUT and C++? If you did you probably wrote proper OOP code and thus at one point or another tried to pass a non-static member function to the GLUT callbacks – and failed. Unfortunately the GLUT API is broken in this respect as it does not allow passing user-data to the callback functions. You either have to make all of your members static or use wrapper functions.

Well the situation bugged me enough, to dig inside GLUT and write a class-based C++ wrapper around its API – it uses the wrapper function approach but hides it behind the class interface, so you dont have to mess around it yourself.

Here is an example what you can do with it:

#include "glut.hpp"
#include <iostream>

class MyWindow: public glut::Window {
public:
 GLfloat color[3];

 MyWindow(const char* title) : glut::Window(title, 300, 200), color( { 1, 0, 0 }) {
 }

 void displayFunc() {

   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   glColor3fv(color);

   glBegin(GL_TRIANGLES);
   glVertex3f(-0.5, -0.5, 0.0);
   glVertex3f(0.5, 0.0, 0.0);
   glVertex3f(0.0, 0.5, 0.0);
   glEnd();

   swapBuffers();
 }

 void keyboardFunc(unsigned char key, int x, int y) {
   cout << key << endl;
 }
};

class MyMenu: public glut::Menu {
public:
 MyMenu(glut::Window& w) : glut::Menu(w) {
   addEntry("Hello", 1);
   addEntry("World", 2);
   attach(GLUT_RIGHT_BUTTON);
 }

 void selected(int value) {
   cout << value << endl;
 }
};

int main(int argc, char* argv[]) {
 glut::Init(argc, argv);
 glut::InitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA);

 MyWindow w("Window 1");
 w.show();

 MyMenu m(w);

 MyWindow w2("Window 2");
 w2.color[1] = 1;
 w2.show();

 glut::MainLoop();

 return 0;
}

the API coverage is far from complete, but it suits my own needs very well. So I hope it can also help others. You can download the header here. And in case you want to help me out with the API coverage or fix some bugs, there is a bazaar branch here.

Doing the right thing

Canonical is doing the right thing. Yes morally as well. By choosing the MIT/X11 license instead of the GPL the Banshee developer explicitly allow using Banshee in a closed-source for-profit project without giving back anything.

To start whining about moral, now that someone actually takes advantage of this right is somehow premature – in the end you had the choice how to license it, right? If you don’t like what happens change the license! Maybe a proprietary one this time, as open source obviously is not restrictive enough for you and you have to resort to “morality”.

As for me I would be perfectly happy if Canonical would simply keep 100% of the Amazon revenue – after all its their product (yes putting together the pieces makes it something new).

As a user I care most whether the product works and I use ubuntu as it works best for me. And since canonical did a great job so far providing what I want, I think the decision should be up to them whether to spend the money on shiny new icons or to give something back to the banshee developers.

For reference: this and this.

YouAmp nightly builds available

If you still remember my small and lightweight media player called YouAmp, you might wonder why there were no recent versions available for an up-to date Ubuntu…

First of all I was quite short on time to spend on the project and pushing an version in a PPA for all supported Ubuntu is quite time consuming. As for me, I still used the karmic version in maverick, which is quite some hack.

Fortunately there is now a package autobuilder available on Launchpad, which automatically builds the current bazaar version and puts it in a PPA. The first benefit of this is that YouAmp is now available for Lucid, Maverick and even Natty through my PPA.

The second benefit is that you get the new features as soon as I implement them, as the package gets updated on every code change :D. And therefore there is already something new in the available packages:

  • support for the Application Indicators (necessary for Natty)
  • clicking on the timescale now jumps to the location instead of just doing a step