Adding a radio panel to X-plane

X-plane is a decent flight simulator available for PC’s running Windows, Macs and PC’s running Linux. Check out X-plane for the program itself, and x-plane.org for the very active on-line community. The .org site has lots of aircraft and scenery for download free, and links to lots of really good quality payware.

While X-plane runs nicely on my modest Mac hardware there are a few things about flying it that annoy me. In particular, every aircraft seems to hide the radios somewhere different, often on a part of the panel that can’t be seen without looking down, ie without losing some of the view out of the forward window. The other thing that looks different on just about every aircraft is the autopilot.

I’d like to slowly develop a cockpit with some external hardware, perhaps one day reach the heights of the simpit. But in the meantime, I thought I’d create some hardware to implement the radio and autopilot. You can buy this kind of gear from lots of places. Saitek have a really nice radio panel, but it is $149, and I thought I could do a nicer looking job. We’ll have to see.

I’ve started with the radio panel. The auto pilot will follow when I’ve figured out how to make nice looking illuminated switches cheaply. The radio panel uses a 16×2 LCD panel for its display, and 11 ‘tactile’ switches (12c each) to make up its control panel. The LCD panel is large size, about 100mm wide active area, and that size is only available to me in 16×2, so it is two line, although I’m only using one. The brains of the system is an Arduino Uno. If you don’t know about it, Arduino is an open hardware architecture development board that contains an Atmel ATmega processor, supported by an IDE and a large number of libraries. The good integration of IDE, hardware and libraries make it literally a five minute operation to add, for example, a keypad to a design. It is this ease of use that converted me, after years of custom code written for a variety of microcontrollers.

I’ll post pictures once it is nicely boxed.

The code is at github. There are separate directories for the sketch that runs on the Arduino, and the code that runs the plugin on X-plane. The plugin is written in Python, and must run under a PythonInterface plugin written by Sandy Barbour. The great advantage of writing in Python is that the plugin will run on all the supported operating systems.

I am really taken by the idea of standard hardware for building cockpits, so I’m looking at SCS, the Simulator Communication System. I’ve registered to download their plug-in and hope to take a look at it soon. It would be cool to develop hardware that drops into existing systems with little or no software required beyond what is already installed. SCS communicates to separate modules using a modified CAN-bus protocol.

Milling with a Mac

I’m a mac user, with a mac mini, and not much desire to switch to something else. The situation that follows is surely not unique to me, but perhaps some of my approaches may be of interest.

As well as the mac, I also have a small milling machine, a Sherline. I have converted it to CNC with the Sherline stepper kit. When I got it going, I sourced an old Dell laptop that still had a parallel port, and installed TurboCNC running under DOS. It worked okay, but time ran out, and my urge to battle with DOS and old flaky hardware ran out with it.

Two years later, I had a spare mac mini and some time, and decided I’d try to get it to work as the CNC controller. It’s an ideal workshop machine: small and quiet. Just to add a further step away from the mainstream of Intel-Windows, this is a G4 PPC mini. The biggest shortcomings are the lack of easy parallel interfacing and the lack of a CAM program that is affordable to runs on the mac.

I found grbl by Simen Svale Skogsrud and thought this might be a solution. Grbl was written to provide a simple USB interface g-code driver that sits between a computer and CNC drive electronics. It was driven by a Ruby script that sent lines of g-code file to the Arduino board that runs the grbl code.

Without a decent CAM program, I wanted a more user friendly GUI to send g-code to grbl, so I developed pygrbl. It is hoped to one day offer much of the user interface of tools like EMC2, but driving grbl to achieve the real-time needs of pulse generation for CNC. It is written in Python, using the Qt framework via PyQt, so should be fairly easy to port to Windows or Linux.

Pygrbl originally used PyQGLViewer, which led to my earlier blog post. I simply couldn’t get it running on the PPC mac mini, so decided to rewrite the open-gl viewer portion of the code using QOpenGl. There have been a number of interesting learning experiences in the project so far, and that was one of them! Removing PyQGLViewer has made the system a lot easier to install, and fewer dependencies has to be good.

In order to get pygrbl to talk nicely to grbl, I had to add some facilities, in my fork of grbl. The major changes are:

• All grbl’s responses are now non-blocking. Grbl maintains a queue of g-code commands. If that is full, it won’t accept another command.
• There is a command interface to query the state of grbl while it is interpreting g-code. This allows for the position of the mill to be determined at any time, as well as whether the mill is cutting or standing.

I’ve also added a rudimentary user interface to grbl on a second Arduino, also available from github.

After the usual trials and tribulations, pygrbl is now mature enough to cut its first plastic.

Installing PyQGLViewer on Mac OS 10.6 Snow Leopard

I’ve been struggling to get PyQGLViewer running under OS 10.6. There was a lot of finger trouble and not following instructions, but a couple of little things helped. This is a list of my experience, hopefully to save others some trouble:

• Download the patched version of libQGLViewer 2.3.4 from the Inria site. This is available with PyQGLViewer V0.8, and already includes the patches to libQGLViewer necessary to get it to work with sip.
• From the root of the libQGLViewer-2.3.4 run: qmake libQGLViewer-2.3.4.pro -spec macx-g++-
• The -spec tells qmake to generate a gcc Makefile. That compiled straight-forwardly with make; make install
• Following the make, the examples didn’t build. The problem is to do with the apple build not creating a .dylib, but rather a framework. It can be fixed by changing the qmake .pro file. For the animation example, replace animation.pro with a file that contains:

TEMPLATE = app

TARGET   = animation

QT *= xml opengl

HEADERS  = animation.h

SOURCES  = animation.cpp main.cpp

INCLUDEPATH *=

LIBS *= -framework QGLViewer

• If the new .pro file is called mypro.pro, then call it with
• qmake mypro.pro -spec macx-g++

• as before to produce a gcc make file. Then run make, which creates a working Mac OS animation app.

On to PyQGLViewer. Following the documentation, run python configure.py. Two additions help:

python configure.py -Q /Users/my_user_id/Desktop/libQGLViewer-2.3.4 -I
/usr/X11/include

The first tells PyQGLViewer where the sources are. The second was necessary to resolve a definition.

After that it all went easily: make; make install and it worked. The
python apps in the examples folder all worked perfectly.