Multiwii 2.2 Stick configuration - Mode 1

I was playing with my custom built quadrocopter based on Multiwii platform, but had trouble finding a comprehensive guide to stick configuration functions online. I stumbled upon Mr. Hamburger's awesome cheatsheet, but found out that for my Mode 1 stick configuration it was wrong. I have throttle and yaw on the right stick and pitch & roll on the left. I haven't tested all functions, but they should work.

Here's a modified version for anyone interested: Download multiwii 2.2 stick configuration cheat sheet for Mode 1 PDF.

If you want to make your own changes, I recommend downloading Hamburger's latest open office file, but here's my M$ office edited version also.

How to use command line arguments from a basic Netbeans gui project

For some reason, it was really hard to figure out how to achieve this. The problem I was getting was " non-static variable this cannot be referenced from a static context ". Now that I know what I was doing wrong, it all makes perfect sense, but at the time it didn't. So here's a tutorial for all of you other java noobs like me that want to take the shortcut to a working application fast without completely undestanding java :)


/*
* DesktopApplication1.java
*/

package desktopapplication1;

import org.jdesktop.application.Application;
import org.jdesktop.application.SingleFrameApplication;

/**
* The main class of the application.
*/
public class DesktopApplication1 extends SingleFrameApplication {

//Something to hold the new argument
private static String myargument;

//method to get the argument
public String getArgument() {
return DesktopApplication1.myargument
}

/**
* At startup create and show the main frame of the application.
*/
@Override protected void startup() {
show(new DesktopApplication1View(this));
}

/**
* This method is to initialize the specified window by injecting resources.
* Windows shown in our application come fully initialized from the GUI
* builder, so this additional configuration is not needed.
*/
@Override protected void configureWindow(java.awt.Window root) {
}

/**
* A convenient static getter for the application instance.
* @return the instance of DesktopApplication1
*/
public static DesktopApplication1 getApplication() {
return Application.getInstance(DesktopApplication1.class);
}

/**
* Main method launching the application.
*/
public static void main(String[] args) {

DesktopApplication1.myargument = args[0];

launch(DesktopApplication1.class, args);

}
}


So you save the argument to a static variable using class reference and create a method to retrieve the value (private static String myargument; and public String getArgument() ) Then from the applications main frame you can now call that method once you have changed the constructor a bit (public DesktopApplication1View(DesktopApplication1 app) ).


/**
* The application's main frame.
*/
public class DesktopApplication1View extends FrameView {

public DesktopApplication1View(DesktopApplication1 app) {
super(app);
//Use the argument
System.out.println(app.getArgument);
initComponents();


I know this might not be the optimal solution, but it works. Sometime you just need to create a quick java app without learning the whole language. An app with a basic netbeans guin and some command-line arguments :)

Upgrade Ubiquiti RouterStation OpenWRT firmware

This post is a shorter version of the one found in the openwrt mailing lists.

First steps:
1. Unplug your RouterStation (POE cable) and remove wlan cards
2. Set your computers IP to be in the same network as routerstation 192.168.1.* (Don't use the routerstation 192.168.1.20 IP)
3. Set your computer to ping the ip 192.168.1.20 continously (M$ Win cmd "ping -t 192.168.1.20") to see that the RS is there.
4. Press and hold the RS reset button. (RS powered off at this point)
5. Connect the POE cable.
6. Wait for the rf light to show up. Your RS is now in failsafe mode, waiting for tftp-connection.
7. Use tftpd32 or some other tftp software to upload the new firmware to your RS's IP (192.168.1.20). In this software, it's the tftp Client tab. Enter IP (192.168.1.20) and select the new firmware, and press put.
8. Wait, wait, wait.
9. Eventually it should reboot.

New firmwares can be found from Ubiquiti Forum for RouterStation. Beware, the UPGRADE version will overwrite Redboot bootloader also.


Ps. Having a serial adapter and a cable to monitor the RouterStation is a very good idea during this process.

My output from the RS serial console during the flashing process:

TFTPD: waiting for connection...
TFTPD: waiting for connection...
TFTPD: waiting for connection...
TFTPD: Incoming connection from 192.168.1.66:50758
Received: 6215536 bytes
Firmware Version: RSx.ar7100.OpenWrt.r15349
Initializing default partitions for 16M flash size.
Created 'kernel' - base: 0xBF030000, mem base; 0x80060000, entry: 0x80060000, size: 0x000E0000
Created 'rootfs' - base: 0xBF110000, mem base; 0xBF170000, entry: 0x00000000, size: 0x00560000
Created 'cfg' - base: 0xBFFD0000, mem base; 0xBFFD0000, entry: 0x00000000, size: 0x00020000
Created 'data' - base: 0xBFBD0000, mem base; 0xBFBD0000, entry: 0x00000000, size: 0x00400000

Updating FIS directory!
... Erase from 0xbfff0000-0xc0000000: .
... Program from 0x83ff0000-0x84000000 at 0xbfff0000: .

Flashing partition 'RedBoot' (size: 0x00030000, actual data: 0x00030000)
... Erase from 0xbf000000-0xbf030000: ...
... Program from 0x8006cd44-0x8009cd44 at 0xbf000000: ...

Flashing partition 'kernel' (size: 0x000E0000, actual data: 0x000E0000)
... Erase from 0xbf030000-0xbf110000: ..............
... Program from 0x8009a31c-0x8017a31c at 0xbf030000: ..............

Flashing partition 'rootfs' (size: 0x00560000, actual data: 0x004E0000)
... Erase from 0xbf110000-0xbf670000: ......................................................................................
... Program from 0x8017a35c-0x8065a35c at 0xbf110000: ..............................................................................
... Resetting.+

Generic $2.5 USB to Serial adapter for Vista and Linux

I decided to check out those cheap USB to Serial adapters sold on eBay. And even though the description says they are only Windows 98/2000/XP compatible, it worked in my Ubuntu 8.10 out of the box and after a driver install also in Vista 32-bit.

The Chipset in the cable is: Profilic PL2303

Drivers for 64-bit Vista / Windows 7 here.

Lets hope it also works in OpenWRT without compiling kernel modules... I think I'll buy a bunch of these to strip out the serial connector and integrate them in various projects. Needless to say - I like the price point :)

The item was this. And the seller store can be found here.

Why should Model Aircraft be unstable? Meet the moment of inertia

Physics is not my strongest subject, but while playing around with a pencil in my hand, I started wondering what's wrong with the following picture of a traditional setup of an RC plane:


While this might be a good setup for a fast manually controlled "trick planes", the end result of concentrating all the weight on the center of the plane makes it more "unstable". Simply put if most of the mass of an object is located in it's center of gravity, it's easier to rotate than an object with weight concentrated on the outside edges. So especially for UAV and training models, I'd recommend a setup, where for example the batteries would be located at the wingtips rather than at the center:


This setup should allow for a more stable flight and make it easier to do automatic stabilisation. It also has the added bonus of not having to make wings as strong, as the lighter central body of an aircraft won't bend wings so much - there's a reason why big real aircraft have fuel tanks on the wings. This setup might be hard to modify on an existing model, but when designing a flying wing UAV - this is a must.

The article on Moment of Inertia in Wikipedia explains the physics behind rotating similar objects with different weight distributions. To get an easier example I recommend this site.

The plane images are originally from an article on Wikipedia, so use them if you want. And as always, if I'm wrong on this one - please correct me :)

Timing of Arduino communication with GPS on the same serial line

The problem with using one serial port for two devices (see previsous post), is timing.

My Holux GPSlim 240 sends data every second, and satellite info every 5 seconds. I estimate that maximum number of charaters received is about 500, so it takes only 500ch/(38400bps /8bit/ch) ~ 0.1 sec to receive the whole GPS "datapack". That leaves 0.9 secods for arduino communication. Just to be on the safe side, I think 0.2 secods for gps-data should be reserved. The good thing is that sending data to arduino can happen at any time.

Here's my plan for the flow control from arduino:

1. OpenWrt: Wait for GPS data receive to end
2. OpwnWrt: Send "Ready to receive" notification to Arduino
3. Arduino can reply for 0.7 seconds. (Sensor telemetry data etc.)
4. Arduino goes to "no send mode", and only receives serial data.
5. There's a 0.1-0.2s gap between the last Arduino data and the next GPS data.

Naturally I'll implement a checksum for data coming from arduino just to be safe.

Arduino serial + GPS data on single OpenWrt serial port

I want to process the GPS data on OpenWrt, and still communicate with the arduino port even though I have only one serial port on my test platform (Fonera).

I've connected both Adruino rx/tx and GPS tx pins to the serial pins of the Fonera box, but I'm using two diodes in both tx lines to isolate problems. Now I can receive NMEA data from GPS, but also sensor data from Arduino. I can also send commands to the arduino.

Illustration:

GPS  tx   ->diode->   rx  FON  rx  <-diode<-  tx  Arduino 
GPS gnd   -------->   gnd FON gnd  <--------  gnd Arduino
                          FON  tx  -------->  rx  Arduino

stty settings on Fonera:

# ttyS0 38400 bps, 8 data bits, no parity, no hardware HS, no echo
./stty -F /dev/ttyS0 raw cs8 -parenb -crtscts -echo speed 38400

I also commented the /dev/ttyS0 line from /etc/inittab to disable the automatic Serial console of OpenWrt

Change serial port speed on OpenWrt Kamikaze 8.09 with stty

The forums were full of descriptions how to change the console speed, but the basic busybox-package on kamikaze doesn't have the stty program. It can be found on the coreutils-package, but some platforms don't have enought space to install the whole package.

So here's the download link to the stty-program for Kamikaze 8.09 on mips/atheros/fonera platform. Hopefully it helps someone.

Ps. The reason why the default 9600bps didn't work for me, is that I wanted to test my Holux GPSlim 240 bluetooth GPS dongle through the serial port. Even though this GPS has only a usb-port for charging, it's actually not usb at all. It's aserial line working in 38400bps. Works with arduino also. Pinout can be found from the manual.

Ubiquiti Networks Routerstation based OpenWrt UAV

I've had an arduino board and cheap ebay three axis accelerometers + GPS + compass sensors for a while, but I think that using just arduino is a bit limiting and good serial modems for telemetryare quite expensive.

I want something more scalable, and therefore have been thinking about the Routerstation platform. It's only about 50-60€ + postage, and it features 680Mhz MIPS 24K CPU, 64MB RAM, and 16MB Flash and most importantly Srrial and USB 2.0. Atheros mini-pci wlan-boards can be used for connectivity and are dirt cheap on ebay.

So if you have USB, you have basically everything to play around with. UMTS modems, webcams, USB-serial ports, gphoto2 usb interface to your digital camera etc.

Please share your thoughts and give other suggestions on embedded linux platforms.