fouldsy.com

The internet was off all weekend, made even more annoying by a) their customer service lines were also closed all weekend and b) it came back online first thing this morning meaning when they got into the office and saw the problem, a simple remote equipment reset or similar fixed it in a matter of seconds Still, least it’s working now. It gave me a chance to play with using IR detectors on the Boe-Bot to act as eyes for navigating which was pretty cool:

As opposed to using the wire ‘whiskers’ which have to physically touch an object before then backing up and moving away, and the light-sensitive photoresistors which weren’t really useful for navigating around objects at any great speed, using the IR sensors allowed it to continually send out pulses to detect objects and then react to them before they became an obstacle. This allowed much faster movement through a small maze (another USPS-sponsored event!):

I also set it up using basic code for a sumobot where it would lock onto an object and try to follow. Mia was not impressed! I was though, as it was able to successfully track a very fast moving dog

A little more difficult working with the photoresistors rather than the whiskers as there’s so many windows in this house, it’s very bright at the best of times But, I played around making the Boe-Bot act like a scaredy-cat by backing away from a flashlight:

More useful was programing it to move towards light sources, such as exiting a dark area or room and moving towards the light - of course, Mia decided to come stick her nose in again! Think I need a subroutine called “DogAvoidance” (maybe use the piezospeaker to emit a high frequency tone!), but it seemed to do pretty well on this one anyways:

And one more project to have the Boe-Bot detect changes in the colour surface and avoid black areas.

One common robotics challenge is following a black line, so I’m guessing this is something the textbook will move onto using the same principles of detecting the colour changes and making adjustments as to the direction of travel. Next up though is using the infrared sensors for navigation and object detection.

This afternoon I worked through using ‘whiskers’ on my Boe-Bot so that it can detect when it’s touched an object and so backup and try again in a different direction:

It was a little more interesting than the first few chapters of programming it to move in certain directions, turn at a particular angle, etc. although probably worthwhile in the long run to be able to calculate what speed and durations of turn produce various distances and directions. After setting up a minor obstacle course (sponsored by the US Postal Service…), Mia decided to come and see whether anything good was happening:

Inquisitive little bugger…

Note: I’m switching some videos to YouTube as the media plugin I use for WordPress automatically starts downloading all videos displayed which is getting boring if there’s more than one video to load. For those at work, school, college, etc. where YouTube may be blocked, I’ll be including an alternative video link here on the blog below each YouTube clip, ‘cos I’m nice

Robotics is something I’ve wanted to get into for years, pretty much since Robotwars appeared on TV and the idea of creating big machines with flames coming out the top that were designed to smash other machines sounded like fun I raced various forms of remote controlled cars on + off for a number of years, but that was mainly build the cars, then set them up from race to race. But, programming a microchip and building a robot to figure it’s way through an obstacle course or similar seems like a good challenge, and then there’s stuff like the RoboGames each year (along with smaller regional gatherings) which includes events for small sumo-bots or robosoccer (check the videos!).

Anyway, Parallax caught my attention a while ago with their Boe-Bot robotics kit based off a BASIC Stamp 2 microcontroller and mine arrived today. It seems a pretty good introduction to robotics, and the BS2 chip can be used for a bunch of other things too. Parallax make all their books available on-line in PDF format, so also I’ve worked through some basics with using the BS2 chip outside of controlling the Boe-Bot. With a number of projects included with the kit and components to allow the robot to make it’s own decisions based on position, speed, contact with objects, etc. it should keep me entertained for a while. When I have the rest of the circuitry built up and programmed for something slightly more advanced than moving backwards, forwards, and rotating around itself I’ll post some photos or videos

Using it within OS X was a little harder than inserting the CD and installing the software as Parallex don’t produce their programming suite for OS X or Linux, but others have written apps available for free online which work great. For anyone trying to use the USB version under OS X, download the FTDI VCP drivers here and then install MacBS2 by Murat Konar which is the equivalent of the Parallex programming tool for Windows. For code requiring user input using DEBUGIN, goSerial from Furrysoft works great for displaying the output the same as Debug Terminal does, but also capturing your inputs and sending them to the BS2 chip which MacBS2 can’t do yet. Simply select your USB connection under the ‘Serial Port’ option in goSerial, and then choose ‘9600 bps’ for the connection speed and it should work just fine so long as you close down MacBS2 first otherwise you have both apps trying to connect to the same port concurrently.

Now that I can steal Kat’s camera (she’s asleep, will never know ), I can put together some shots of a ‘little’ project I’ve been working the past month or so…

As I spend quite a bit of time playing flight simulator on the PC, using the mouse to click buttons to change radio frequencies, control the GPS, or even just flick switches to turn on or off navigation lights doesn’t quite cut it compared to sitting in the cockpit of a real airplane. This realisation materialised long before I actually took the intro flight in the Cessna 152 last month There are people who literally spend thousands of dollars and hundreds (if not thousands) of hours rebuilding complete Boeing 737 or Airbus A319 flight decks which look amazing, though a little difficult to accomplish out here. Plus, you’re pretty much pigeon-ed into flying that one particular type of aircraft. The in-between are companies like GoFlight or SimKits which build + sell individual panel components to connect together allowing to utilise them as you see fit and for controlling any aircraft you wish to load up in flight simulator. Again, fantastic units, but still more than a little pricey at $110 plus shipping for a basic 8-button or switch panel.

Since I can’t complain about not having time to build something similar myself and being able to pick + choose the various electrical components myself from various suppliers online, I er, did:

It still needs a couple of sheets of balsa wood for the top parts of each panel which I’ll get in Anchorage next month, but everything is functional and otherwise complete. Some of the labels aren’t perfectly straight and I could do with adjusting some of the push buttons on the autopilot panel so they are all aligned, but it wasn’t built to score any style points! It runs off four USB to 20 button interface modules produced by Desktop Aviator which provide the core controls. These were a great find, even if the articles on flightsim.com which explain how to use toggle switches, push buttons and rocker switches were slightly biased in recommending them given the author of the articles is the founder of the Desktop Aviator But, I liked the way I could buy just one or two and add in functionality over time (which is exactly what I did to make sure I could do what I wanted to do with them in the first place before).

The first completed section was based just off rocker switches and push buttons. The rotary switches for the autopilot panel were added later:

The electronics behind were not all that complicated - the push buttons connect straight to the input pins on the USB interface controller, whereas the toggle or rocker switches require a simple circuit built around an optoisolator to generate a ‘pulse’ as the switch is flicked to allow the computer to recognise the input. The flightsim.com article and instructions on the Desktop Aviator website explain it all in detail and isn’t hard, just time consuming, as this part of the panel required 20 of these small circuits to be soldered. But, figuring on about a $1 for a rocker/toggle switch, $1 for the optoislator, and maybe another $1 total for a capacitor, two resistors and diode, factoring in the USB controller being $29 for 20 inputs, you’re still looking at less than $5 per input. The fantastic plastic panels at 75c each also from Steve at Desktop Aviator were great too as it meant I could drill them however I wanted to group the buttons and switches to my liking.

The radio panel was the main section I wanted to build, as all available solutions are either complicated, expensive, or both. Dual rotary push button switches aren’t easy to find and pricey when you can, and also require either a separate interface controller (usually the more expensive kind used in high-end simulators where you have 80+ inputs per controller) or meant you have to program your own microcontroller to interpret rotating clockwise or anti-clockwise. For the hardcore who won’t accept anything less, they’ll pay quite a price for these kind of inputs, but me, I’ll take a little less!

Taking a basic single-pole 12-position rotary switch (one of the most commonly available at about $2.50) and wiring up pins 1-5-9 and then 3-7-11, it creates the equivalent of a standard toggle switch. To switch between Mhz and Khz when adjusting radio frequencies, after connecting the output of the rotary switch to the standard pulse circuit, the output of this pulse circuit normally going straight to the USB interface controller instead connects to what would be the output of a SPDT toggle switch. The upper terminal can then connect to an input pin on the controller, and the lower terminal to another input pin. Now, when you flip the toggle switch, the rotary controller’s output is sends a different event to the PC. Here’s the circuit to explain a bit better (yes, pretty much just what’s on the Desktop Aviator site):

With the way the rotary switch is wired, you only get a pulse sent on every second ‘click’ as we have a break between our contacts. In practice, this actually works nicely, as with FSUPIC which is used to pass the controls to flight sim, it needs a 1/4 second pause (I believe) between inputs otherwise it won’t recognise it, so if you were rotating very quickly, it wouldn’t register anyways. If you had a rotary switch that had a slightly smoother contact point on the rear (as oppose to mine which has quite a large ball which makes a definitive click and clunk), you probably wouldn’t notice it really. Still, our drawback (for the moment…) is that rotating either clockwise or counter-clockwise, we can’t make a difference in whether we’re increasing or decreasing our radio frequency. This is where the more complicated solutions involving a dedicated microcontroller would read in a binary output from the rotary switch (if we wired up our other contacts in the same manner) to calculate what position the switch is being moved to/from and thus whether it’s going up or down. In contact with Desktop Aviator, they are actually producing a pre-programmed chip to do just this, but no word on pricing. Anyway, my simple solution is to use a modifier key within FSUIPC.

In FSUIPC, I mapped each rotary switch to send a key command rather than an action in flight simulator. For example, rotating the rotary switch for COM 1 will map to Ctrl-C by FSUIPC, and then you can set Ctrl-C to represent COM RADIO WHOLE INC. Fairly straightfoward. Then, add another key mapping for Ctrl-Shift-C to represent COM RADIO WHOLE DEC. Hold down shift whilst rotating the rotary switch and now the frequency will decrease. Technically, you can continue rotating the rotary switch clockwise and it will decrease so long as you’re holding down the Shift key but that’s no fun As I use the CH Yoke, the left rear button on the yoke is set as the Shift key, so I simply hold my finger down on the button whilst rotating the rotary switch counter-clockwise to decrease the frequency; release the button and turn clockwise to increase the frequency. Repeat this key-mapping process where Shift acts as the modifier key to decrease the frequency for the other COM and NAV functions, and with the toggle switch on both Mhz and Khz.

Sounds like a clunky process, but in practice it’s all pretty natural. When leaning over to adjust the radios, you’d keep your left hand on the yoke anyway, so it’s no problem to press you finger on the button at the rear of the yoke. Flicking between the Mhz and Khz positions is no harder than moving your fingers between the inner and outer knobs on a dual-rotary switch. I also put in two push buttons for each control - one to enable the COM or NAV channel and another to switch standby frequency. Really, the only thing missing is an LED screen showing the frequency and your adjustments, but that’s getting back into substantially increasing cost + complexity. With this setup, each rotary switch requires 2 inputs on the USB interface controller, plus one each for selecting the channel and standby frequency. To do both COM 1 + 2 and NAV 1 + 2, it works out to about $50 including the cost of the USB interface controller. A 3rd of the price of the GoFlight unit, though admitedly requiring a little more work to get going and not providing exact functionality of those in a real airplane by having. Still, for those on budget and with the time and patience to build the controls themselves, very worthwhile.

Other cool features I included was a GPS panel which happily recreates the Garmin GNS 430’s found in the EagleSoft Cirrus SR-22 and the default Garmin 500 model within FS2004. The rotary controls work in the same way as the radio controls. I also used another rotary switch to represent the ignition switch of a GA aircraft, and then a selection of buttons and a toggle switch for sending the transponder code and going between standby + on. There’s no direct controls available for FSUIPC to do things like IDENT but you won’t get that unless you fly online with something like VATSIM, with clients providing that functionality anyways.

Whilst building these avionics panels, I also came a lightweight, quick, and free voice recognition utility called Shoot which allows you to speak commands and have the computer respond. This is my way of ‘talking’ to ATC without $50 on VoxATC or similar. Again, it’s not going to perfectly replicate talking to ATC with the correct phrases, but in conjunction with Peter Wilding’s control set and adding in a bunch of other commands, I can say “Ready for taxi for north departure” even though all Shoot sends to flight sim is ‘4′ (or whatever) to select from the text-based prompt in the ATC window. Makes things a lot more realistic, and after a few flights of adding in commands on the fly (no pun intended!) as I came across a new ATC command to set, I very fairly have to just say the numbers to move through menus.

All in all, pretty happy with the setup now, as it certainly gives me a lot more to do when flying, and kept me entertained for a good while figuring out how to do it all and then building up the circuits and wiring the controls. An awful lot cheaper than buying pre-built modules, and let me build it exactly how I wanted, such as for the GPS panel. If you have no interest in flight sim, all this has probably made no sense, but will at least give you something to read to help you sleep! And if anyone is trying to do something similar, let me know in the comments to share your ideas + suggestions or if you have any problems.

Picked up a Wacom Graphire 3 tablet yesterday which is a pretty cool piece of kit. Had quite a few of these running when working at Greencroft in the art department, and was impressed by them. With a new hush hush project being worked on (apart from those that have had sneak peeks…), it’s ideal, as is so much easier doing graphics work with a pen + tablet rather than a mouse.

Running off the desktop rather than the MacBook, as even with 2Ghz RAM, it doesn’t like manipulating 600-700Mb graphics files, so back to trusty Kubuntu and the GIMP (no jokes please!). Works like a charm, and sod the 2 CD’s of tablet drivers and associated software to allow it to work properly. Most modern kernels will have wacom support compiled as a module, so it works as a regular hotplug USB device straight out the box. Did add the following into the xorg.conf though (thanks to http://www.shallowsky.com/linux/wacom.html) to ensure it used the full size of the tablet and the eraser:

# Wacom graphics tablet
Section "InputDevice"
    Identifier  "stylus"  
    Driver      "wacom"
    Option      "Type" "stylus"  
    Option      "Mode" "Absolute"
    Option      "USB"  "on"
    Option      "Threshold" "10"
    Option      "Device" "/dev/wacom"
EndSection
 
Section "InputDevice"
    Identifier  "eraser"
    Driver      "wacom"
    Option      "Type" "eraser"
    Option      "Mode" "Absolute"
    Option      "USB"  "on"
    Option      "Threshold" "10"
    Option      "Device" "/dev/wacom"
EndSection
 
Section "InputDevice"
    Identifier  "cursor"
    Driver      "wacom"
    Option      "Type" "cursor"
    Option      "Mode" "Relative"
    Option      "USB"  "on"
    Option      "Threshold" "10"
    Option      "Device" "/dev/wacom"
EndSection
# End Wacom section
 
Section "ServerLayout"
[ ... ]
        InputDevice    "stylus"   "SendCoreEvents"
        InputDevice    "cursor"   "SendCoreEvents"
        InputDevice    "eraser"   "SendCoreEvents"
[ ... ]

Definatley recommend a graphics tablet to others now I’ve spent a bit of time using one rather than simply seeing them in action elsewhere, and even when I’m skipping between apps or browsing the net, I’ll quite happily use the stylus. Helps combat the old RSI too I guess!

And no, you’ll have to wait to see what I’m working on

Open-Xchange on the Gentoo Sparc64 was just a nightmare! Along with taking an age to run through emerging each package, too many packages weren’t in ’stable’ on the Sparc platform, and stepping back to Blackdown JDK rather than offical Sun-JDK was causing a lot of problems compiling the Java dependencies during the base system install.

So, plan B is running Open-Xchange on my dual-PII testing system. Although mainly for trying out various distros and desktop environments, it’s speed helps, and the fact it’s x86 based! Initially I’ll follow through installing it running off a local OpenLDAP server before complicating matters by powering it from the OpenLDAP server currently configured on one of the Ultra 5’s for user logins and Samba authentication.

Although I’m a little disappointed not to be able to run everything off the stack of Ultra 5’s, I’m more interested in the actual systems configuration and connections across the network than arsing around resolving annoying package dependencies on what appears to be a platform not really receiving much attention for Open-Xchange!

So, I’ve done bugger all with my stash of Sun Ultra 5’s since well before Christmas, and since getting back from my holidays I haven’t been bothered either. Terrible waste of equipment, I know!

But, having received an e-mail from the Open-Xchange team about further migration support and whitepapers from SLOX 4.1 across to Open-Xchange, figured that sooner or later our mail server at school is probably going to be shuffled across. If possible, I’d like to get this done before I leave in May as with SLOX support no longer, applying updates is a right pain, and it’s going on for 2 years since it’s been in operation anyway.

One thing I’ve been looking at for a while is expanding the e-mail systems to incorporate external mail functions as well. At the moment, it’s only handling internal e-mail, but bridging the gap seems logical. I’d want to bring in virus scanning of attachments and spam filters for that, which is why I’ve already been looking at ClamAV and SpamAssassin for my Gentoo network systems.

Anyways, I’ve actually got the 3rd Ultra 5 now running Gentoo Sparc64, integrated with the LDAP server (now I know the steps for creating the certificates from configuring the Samba server…) and have made a start on Open-Xchange on Gentoo. Running Sparc64 has already brough up an issue in that there’s no stable Sun-JDK, though there is a blackdown-jdk ebuild I’m currently compiling.

Of course, running it on such an old system means this may take a while, and since the 2nd package on the (long) list of base software has already caused problems, it may take even longer! But, I do like a challenge…

Truth be told, I just haven’t had the time to play around with this project as much as I wanted. Maybe with it being close to Christmas and stuff winding down at work (plus, just wanting to be in Alaska by now!), I just don’t have the energy on an evening to sit down and crack on.

But, Samba has been running quite happily for a week or so and integrated quite nicely with OpenLDAP. Running on two different severs, thus simulating what you’re likely to get in the network environment, has been a bit of a struggle. All the documentation with regards to running the two of them together are aimed at them being on the same physical machine. Taking out SSL makes this fairly easy and doesn’t cause problems, but most of the tutorials on enabling SSL make it harder. This has been the cause of most of my problems.

In the end, a combination of Samba-OpenLDAP howto from Idealx (a bible almost!) and the LDAP SAMBA PDC Howto from the Gentoo Wiki (always excellent resources!) have got things up + running. Moving between the two doucments is fairly easy, but for the SSL parts, stick with the Gentoo Wiki version - much easier.

Configuring the client machine has been fairly non-eventful in terms of authentication - a couple of simple changes to PAM and configuring of the OpenLDAP connection all that is required. Logging in works fine, correctly authenticating and determining group privileges. It’s getting the correct drives mapped across that’s a challenge at the moment, and this is what I just can’t be bothered to figure out right now!

Again, almost all the tutorials expect you to be running Windows clients, which make it dead easy to configure using the login.bat scripts. However, these don’t work for Linux clients, requiring your own logon scripts. I’ve pretty much got it handling the home directories and the associated shared network drives. I’ve had a quick play with How to Implement Login Scripts into a Pure Linux Environment from the Novell KB which seems to do the trick, but I’m not too happy with the method of grabbing the groups and writing them to disk before mounting them.

Overall, aside from my mistakes and ignorance in not fully understanding SSL connections between the servers, and the struggle in getting login scripts to handle network drives, it’s all been fairly easy, albeit slow going! Certainly the smbldap-tools from Idealx have given the power required to add new users, create these Samba groups for shared network drives, and adjusting the user + group permissions.

For me, one of the core features of a network system for end-users is to allow any information they need to be accessible from anywhere, no matter the machine or OS, hence the design around Samba to facilitate Windows machines, as opposed to going for NFS (a much easier method considering the bulk of the work + clients I’d use would be Linux). This basic setup shows this is possible, but fiddly when compared to the Microsoft AD and NTFS shares it’s designed to replace.

Once additional features such as the web caching + filtering get built-in along with e-mail (both on separate servers - more work!), the true power and benefits should become apparent since they’re all running from a single authentication point and directory from the word go, without the need to hack things together as is the case with current MS AD / Samba connectors.

Well, my first Gentooserver is up and running on the Sun Ultra 5’s quite happily. It wasn’t as problematic as expected to be honest. I guess having done a few Gentoo installs before helped too!

The only couple of things I found was the system didn’t compile the network card driver correctly. I had to go back into the config, de-select the card, exit, head back into config and re-select before re-building the kernel. Plus, with a 3.5Mb limit on 2.4 kernel size on Sparc64, I only just managed to get it down to 3.4Mb after stripping off .comments and .notes as detailed in the excellent Gentoo Sparc Handbook.

Also on this first server, which will become the OpenLDAP server, it wouldn’t set console fonts correctly on boot, causing the system to hang. The correct setting had been applied, but booting off the CD and doing a quick “rc-update del consolefont default” and rebooting cured it with no ill-effects.

Lack of ssh access by default is a bit of an annoyance, but that’s just the way the Gentoo installer does things, so then had to leave the system a while compiling OpenSSH and setting it load on boot. Is easier controlling via ssh then switching back and forth with KVM’s and keyboards.

Onto OpenLDAP, and more great documention from Gentoo in the form of the Gentoo OpenLDAP handbook got everything up and running without too many hassles. The only issue was not including the full hostname within /etc/hosts - it must be hostname.domainname.extension, in this case fatcontroller.homelinux.net, not fatcontroller.homelinux or communicating with the LDAP server would fail. Enabling SSL is a doodle, and importing users, groups, etc. from the local box was fine with the migration-tools. Not sure about how it would handle an import from existing LDAP server such as a Microsoft Active Directory, which would have interesting to try out. Not having one in my pocket hindered that slightly!

My test machine with a Gentoo system already installed has been commandered as the network client since it’s already setup, and a few simple changes to PAM got the workstation authenticating with the LDAP server. The next stage is implementing a Samba server to handle network home directories and profile storage, so whilst authenticating against the LDAP server, you also have the appropriate network drives mapped to the account.

Speaking of which, the Samba server itself installed within one evening having learnt from the problems building the first server. I decided it probably wasn’t worth the hassling unplugging everything, slaving hard drives, imaging them, then plugging everything back to together. Of course, making judicious use of [scp to move the kernel .config file and such across helped a tad! Also, the Samba server didn’t experience the console fonts problem on boot, so is quite happy booting. Currently, it’s starting to compile all the tools as per the Gentoo Samba3/CUPS/ClamAV HOWTO.

Overall, the speed of the systems in terms of booting up and running things seems quite okay. Compiling is a slightly different matter, as to be expected from the hardware. Won’t break any records for compilation time, but it seems fairly stable and that’ll do me! Am looking forward to getting my teeth into this project once Samba is up + running to really start manipulating the LDAP server to control shared group folder permissions and logins in the same manner network clients + users would in the workplace. Sticking an e-mail server into that will be next, but intend on having some fun with OpenLDAP + Samba first!