[imu] Microstrain 3DM-GX1

Recently I've been playing around with a MicroStrain 3DM-GX1, which is a pretty decent IMU. I found myself in need of an IMU for a project I'm working on, and the lab just happened to have a GX1 lying around.

While the GX1 itself is a solid piece of hardware, the software is a little bit lacking. This is especially true for linux; MicroStrain provides only a small example to get euler angles. It would have been nice if they had provided a library and API, but it was easy enough to write one from scratch using the 3DM-GX1 Data Communications Protocol document.

I feel obligated to say here that MicroStrains documentation is excellent, and really simplified the whole process. I also had to email customer support once or twice, and they were very helpful.

So I wrote a C++ library to talk to the GX1. It was relatively painless because the GX1 uses a serial interface and I could simply use the unix termios API. While the GX1 supports polling and continuous modes, I focused on polling because it's more flexible. To get data from the IMU the following must occur:

• Set a command to the GX1
  
• Wait for result buffer
  
• Read the result buffer
  
• Parse the result to get meaningful data

My API combines these steps into a single function call for easy, readable, OO programming. For example calling "imu.get_euler()" would return the Euler angles, so it's very simple.

[o3d2xx] 3D LIDARs Are Cool

This summer I wrote a C API and Matlab driver for an IFM O3D200. This is a really cool LIDAR. It basically captures distance images, meaning the pixels of the image represent distance rather then color, like with a normal camera. It can also send out the Cartesian coordinates of each pixel, so you don't have to do it in preprocessing.

The O3D2XXs use XML-RPC for configuration, and a simple TCP socket for data flow. The XML-RPCs are useful and provide a good deal of customization. They allow the user to change the exposure time, frame rate, frequency mode, etc. The network settings are also configurable, and the LIDAR can use DHCP or a static IP address. Using the socket is easy, the user simply requests and image and then reads in the buffer(s).

Right now my code has to stay top secret, you know, to give Vader Lab a competitive edge. Hopefully someday later I can publish it. Even though most people don't have O3D2XXs right now, I expect this sensor to gain in popularity. After all it's very cool.

[pymex] Source Code Released

I've added a few things since my last post, and everything seems to be working properly, so I'm going to call this version 0.1. To learn more and/or get the source code, visit the pymex website.

http://vader.cse.lehigh.edu/~perkins/pymex.html

In case you didn't know, pymex mixes Python and Matlab by embedding a Python interpreter in Matlab. pymex also allows programmers to transfer data between Python and Matlab, this is accomplished by extending Python with a special "matlab" module.

You can find pymex at Mathwork's File Exchange.

[matlabjoystick] Use a Joystick in Matlab

Have you ever wanted to use a joystick in Matlab? Yeah, I didn't think so. But just in case you did I wrote a Mex file to interface with SDL's joystick subsystem. By the way, SDL is a great easy to use library, I recommend it.

I wrote this for the "remote control wheelchair" my lab is working on. At first I tried using keyboard control, but the binary nature of a keypress made it difficult to set a constant speed. I can't image many people using this, but it could be useful in some situations.

Basically a joystick object gets initialized, and sends back an array of doubles, one for each axis, hat, and button. Optionally a mask can be set to filter buttons. For example my joystick has 14 axes/buttons, but I only care about the first two axes and the trigger button.

The following Matlab session demonstrates the use of a joystick object.

>> j = Joystick(0)
j = 
  Joystick handle

  Properties:
    joystick_number: 0
         state_mask: [1 1 1 1 1 1 1 1 1 1 1 1 1 1]
  Methods, Events, Superclasses
>> j.state()
ans =
  Columns 1 through 11
     0     0     0     0     0     0     0     0     0     0     0
  Columns 12 through 14
     0     0     0
>> m = j.state_mask
m =
  Columns 1 through 11
     1     1     1     1     1     1     1     1     1     1     1
  Columns 12 through 14
     1     1     1
>> m(5:end) = zeros; m(3) = 0;
>> m
m =
  Columns 1 through 11
     1     1     0     1     0     0     0     0     0     0     0
  Columns 12 through 14
     0     0     0
>> j.mask(m)
>> j.state()
ans =
     0     0     0
>> 

[pymex] Python in Matlab

So I've been pretty busy on a few different things. One of those things happens to be pymex. I often need to extend Matlab to do something

To extend Matlab's capabilities it's necessary to write mex files in C/C++. Python is quick to code and it already has a bunch of available modules. With pymex a programmer can embed Python code inside of Matlab and avoid the whole mex file thing.

As an added benifit I also wrote a python module called 'matlab'. This module does two things. First, it provides a simple print function which prints to Matlab's command window (like mexPrintf). Second, it allows Python variables to be 'pushed' to Matlab.

matlab.mex_print(str, ...)
'''Like Pythons built-in print function, takes a variable
length of objects, converts them to strings using str(),
and prints the result to the Matlab command window.'''

matlab.push(varname, var, ...)
'''Using the Matlab function 'assignin', creates a Matlab
variable in the caller's scope from 'var' named 'varname'.
The 'varname' must be a valid Matlab variable name.
The 'var' must be a scalar; lists, tuples, and objects are
not supported yet.'''

Here's a sample script to show what pymex can do.

pyscript = sprintf([...
'import matlab\n', ...
'x = 7\n', ...
'for i in range(x):\n', ...
'    matlab.mex_print(i)\n', ...
'    matlab.push("i_%%d" %% i, i)\n', ...
'matlab.mex_print("demo complete!")\n', ...
]);

pymex(pyscript);

[sidhack] Commodore 64s and MSSIAH

So I bought a few Commodore 64s. I should have a few SIDs I can work with. They are mostly 6851 R4s, which is good, but unfortunately I didn't get a single 8580.

[I'll add a picture in here later...]

I've decided to try and learn more about the chip by actually using one, so I've ordered a MSSIAH. MSSIAH is a C64 cartridge which basically turns a C64 into a synth. It can also process MIDI input, which is pretty cool. I think looking at MSSIAH should give me a good idea of what my eventual target will be. It also gives me an excuse to have some fun with the C64s I just got!