Division of Information Technology, Engineering and the Environment
Advanced Computing Research Centre (ACRC)
University of South Australia
[WCL] Wearable Computer Lab Home University of South Australia Wearable Computer Lab [WCL]

news

July 2, 2010

An article in the Adelaide Advertiser from Saturday featured our lab director, Bruce Thomas. The article looks at the ways technology is going to infiltrate our everyday life in the future.

Read the article

Filed under: News — Tags: , , , — Michael Marner @ 10:41 am



June 2, 2010

Just a quick note to say the Wearable Computer Lab was featured in an article in the Adelaide Advertiser yesterday. Michael in particular got his face in the paper. The explores the possibilities of Augmented Reality in the near future. For more information, see the media page, or just read the article.

Read The Article!

Filed under: News — Tags: , , , — Michael Marner @ 9:36 am



March 24, 2010

This weekend I presented my paper, Augmented Foam Sculpting for Capturing 3D Models, at the International symposium on 3D user interfaces. Since the conference has passed, I have added the video to youtube and the paper to my publications page. First, the video, then some discussion after the jump.

Foam Sculpting

The inspiration for this work came out of a project we did with some industrial design students. Their job was to create some input devices for my SAR Airbrushing system. First up, we had a  meeting where I showed them a very early stages of development version of the system, to give them an idea of what we were doing. They went away and came up with ideas for input devices, and in the next meeting had a bunch of sketches ready. We discussed the sketches; what we liked and what we didn’t like. Next, they brought us foam mockups of some of the designs. We discussed these, and then eventually they came back with full CAD models ready for 3D printing. They did a great job by the way. But it got us thinking:

How can we make this process better?

Augmented Foam Sculpting is the result of this work. It allows a designer/artist to simultaneously create a physical design mockup and matching virtual model. This is a Good Thing™, because it utilises the skills and tools that designers are already using.

The system works by tracking the position and orientation of both the hot wire foam cutter, and the piece of foam the user is sculpting. We can track the motion of the hot wire as it passes through the foam. From there, we can create geometry that matches the cut path, and perform a Boolean difference operation on the foam geometry, to replicate the cut in the virtual model (Before any of you “Booleans are evil” people get to me, I’d like to point out I’m only dealing with, and creating, triangle meshes. There are no 11 sided polygons here).

Using projectors, we can add extra information to the foam as the user sculpts. We implemented 2 visualisations to aid designers when creating specific models. Cut Animation displays cuts to be made as animated lines on the foam surface. Once a cut has been made, the system moves to the next one. This visualisation could be used to recreate a previous object, or to instruct novices. An algorithm could be developed to calculate the actual cuts that need to be made, reducing the amount of planning needed when making an object.

The second visualisation, Target, projects a target model so that it appears to be inside the foam. The foam is coloured based on how much needs to be removed to match a target model. This could be used to create variations on a previous model.

Finally, we can use 3D procedural textures to change the appearance of the foam. For example, we implemented a wood grain 3D texture. This works pretty well, because as you cut away the foam, the texture updates to appear as though the wood was actually cut. 3D textures are also ideal because we don’t need to generate texture coordinates after each cut.

For all the details, please have a read of the paper. If you have any questions/comments/feedback/abuse, please comment on this post, or send me an email.

Michael



March 19, 2010

New and improved!Well, after far too long, the new [wcl] website is ready to go! However, this is still somewhat of a work in progress, so if there are any problems please let us know.

Cheers
Michael

Filed under: News — Michael Marner @ 10:05 am



January 8, 2010

Recently I was working on a php command line program that required access to a serial port.

Initially developed under Linux the program was then shifted to it’s permanent location on a FreeBSD server. This is where we first started having problems. Initially we discovered the server didn’t have a native serial port. We fixed this using a USB to serial converter/dongle (FTDI Chipset). This was fine as FreeBSD has the ufdti kernel module. Upon loading the module new devices appears in /dev

crw-rw----  1 uucp  dialer    0, 157 Oct  6 08:39 /dev/cuaU0
crw-rw----  1 uucp  dialer    0, 158 Oct  6 08:39 /dev/cuaU0.init
crw-rw----  1 uucp  dialer    0, 159 Oct  6 08:39 /dev/cuaU0.lock
crw-rw-rw-  1 root  wheel     0, 154 Jan  8 10:50 /dev/ttyU0
crw-------  1 root  wheel     0, 155 Oct  6 08:39 /dev/ttyU0.init
crw-------  1 root  wheel     0, 156 Oct  6 08:39 /dev/ttyU0.lock

We attempted to connect to our device using screen (screen /dev/ttyU0 115200) and everything worked as expected. We could send AT commands to the device all ok.
We then stopped screen and ran our php program. It ended up hanging on a fgets call to the serial port. This is really strange we though.
Next we queried the port to find out what baud rate it was set at:

>stty -f /dev/ttyu0
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb

Strange we thought as we’d just connected with screen at 115200. Under linux we use screen to set the baud rate, all other programs accessing the port use the port at 115200. So what had set it back to 9600 baud?
We tried to use stty to set the speed:

>stty -f /dev/ttyU0 speed 115200
>stty -f /dev/ttyu0
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb

What on earth was happening? We set the speed to 115200 but directly quering the port again indicated it was still at 9600 baud? At this point we were perplexed.
Eventually we found the solution. The newer FreeBSD terminal drivers provide the *.init devices, in this case /dev/ttyU0.init . These devices indicate the terminal settings to be applied to the terminal when the device is closed. Whilst Linux leaves the device in the same state the last program put the port into, FreeBSD restores the terminals state to what ever is specified in the init file. So a quick command:

> stty -f /dev/ttyU0.init -icanon -isig -echo echoe echok echoke echoctl -icrnl -ixany -imaxbel ignpar -opost -onlcr -oxtabs cs8 -parenb -hupcl clocal

And then to check:

> stty -f /dev/ttyU0
speed 115200 baud;
lflags: -icanon -isig -echo echoe echok echoke echoctl
iflags: -icrnl -ixany -imaxbel ignpar
oflags: -opost -onlcr -oxtabs
cflags: cs8 -parenb -hupcl clocal

Excellent. The terminal was now configured exactly how we wanted. We ran the program and it worked like a charm!

Filed under: baud rate,baudrate,FreeBSD,ftdi,News,serial,stty,UniSA — Benjamin Close @ 9:33 am



August 6, 2009

The other day I was working with a few colleges using VNC. We came across an issue with our VNC setup. We could connect a VNC client (be it tightvnc, vncviewer, vinagre or x4vnclient) to our vnc server but never see anything on the screen. It was if the server was freezing or hanging.  This left us wondering why. Initially we thought we had broken something in the VNC server – after all we had made code modifications. However the solution turned out to be a very simple fix.

You see the VNC protocol has the ability to place a client ONHOLD. During this state the clients events are not transmitted and the server sends back no images. This is what was happening to us. Normally the VNCServer will place the client on hold during a connection, asking the user to accept/reject the client. However we had been playing around with configuration files and set the prompt to disabled – we wanted automatic connection, with no prompt. Hence the VNCServer was placing the client on hold, noticed prompts were disabled and because authentication had not been established, sat there twiddling it’s thumbs.

A simple configuration file fix and everything was working again. Ironically at the same time we also discovered that modifying files by had in ~/.gconf/* doesn’t do anything as there’s a daemon that holds the configuration and it periodically writes to ~/.gconf/* overwriting any changes you might have made – hence we used gconftool2.

The Fix?

To allow gnome to prompt the user for authentication. Hence a dialog would show up and the authorisation could take place.

gconftool-2 -s -t bool /desktop/gnome/remote_access/prompt_enabled true

You can also find this same setting in gconf-editor if you want a gui way to update it.

Filed under: Computers,connection hangs,freezes,News,no image,onhold,OpenSource,UniSA,vnc — Benjamin Close @ 3:26 pm



March 6, 2009

One project I’ve been working on with fellow members of the Wearable Computer Lab (WCL) has been a project we’ve called ‘Snappy’. Snappy is simply an old Canon IXUS camera that is connected to an old Dell Laptop. It was setup to monitor the construction of a new building here at the University of South Australia. The building will be used for a number of things but in particular it will host the Visualisation Lab used by the WCL.

Snappy was something setup so the lab could see how construction was going and also so we could have some time lapse photography about the building being built.

Ironically, it appears that Snappy has grown. The VC of the Uni checks it, the architechs in Canberra are using it to monitor progress and a lot of the people involved are using it!

You see snappy consist of the camera and a web frontend to the photos snappy has taken. The frontend is a bunch of PHP scripts created by myself (Benjamin Close), Aaron Stafford, Ross Smith and Micheal Marner. Each one of us has worked on a part of either the scripts, the hardware or getting things working. Robert Speedie has been a big help in making this work as well. He has the contacts and funding to help it happen.

So if your interested in seeing Snappy, visit the url:

and have a look. One of the photos he’s taken is below –  a great sunrise.

Filed under: camera,canon,News,php,Projects,snappy,UniSA,wcl,website — Benjamin Close @ 10:12 am



February 2, 2009

Recently Ben and I have been trying to get a FreeBSD box to join an Active Directory domain. The domain controller was running Windows Server 2008. After a *lot* of stuffing around to get this working we finally found the solution to our problem – the version of samba.
You see the problem we were facing was:

# net ads join -U cis-closebs
cis-closebs's password:
Failed to join domain: Improperly formed account name

Now we checked the logs, checked kerberos, samba, but could not get this working. The debug logs showed something but nothing really useful:

# net ads join -U cis-closebs
cis-closebs's password:
Failed to join domain: Improperly formed account name
# net ads join -d 3 -U cis-closebs
[2009/02/02 12:55:26, 3] param/loadparm.c:lp_load(5031)
  lp_load: refreshing parameters
[2009/02/02 12:55:26, 3] param/loadparm.c:init_globals(1430)
  Initialising global parameters
[2009/02/02 12:55:26, 3] param/params.c:pm_process(572)
  params.c:pm_process() - Processing configuration file "/usr/local/etc/smb.conf"
[2009/02/02 12:55:26, 3] param/loadparm.c:do_section(3770)
  Processing section "[global]"
[2009/02/02 12:55:26, 2] lib/interface.c:add_interface(81)
  added interface ip=130.220.236.62 bcast=130.220.237.255 nmask=255.255.254.0
[2009/02/02 12:55:26, 3] libsmb/namequery.c:get_dc_list(1489)
  get_dc_list: preferred server list: "130.220.64.77, uninet.unisa.edu.au, *"
[2009/02/02 12:55:26, 3] libads/ldap.c:ads_connect(394)
  Connected to LDAP server 130.220.64.77
[2009/02/02 12:55:26, 3] libsmb/namequery.c:get_dc_list(1489)
  get_dc_list: preferred server list: "130.220.64.77, uninet.unisa.edu.au, *"
[2009/02/02 12:55:26, 3] libsmb/namequery.c:get_dc_list(1489)
  get_dc_list: preferred server list: "130.220.64.77, uninet.unisa.edu.au, *"
cis-closebs's password:
[2009/02/02 12:55:27, 3] libsmb/namequery.c:get_dc_list(1489)
  get_dc_list: preferred server list: "130.220.64.77, uninet.unisa.edu.au, *"
[2009/02/02 12:55:27, 3] libads/ldap.c:ads_connect(394)
  Connected to LDAP server 130.220.64.77
[2009/02/02 12:55:27, 3] libads/sasl.c:ads_sasl_spnego_bind(213)
  ads_sasl_spnego_bind: got OID=1 2 840 48018 1 2 2
[2009/02/02 12:55:27, 3] libads/sasl.c:ads_sasl_spnego_bind(213)
  ads_sasl_spnego_bind: got OID=1 2 840 113554 1 2 2
[2009/02/02 12:55:27, 3] libads/sasl.c:ads_sasl_spnego_bind(213)
  ads_sasl_spnego_bind: got OID=1 2 840 113554 1 2 2 3
[2009/02/02 12:55:27, 3] libads/sasl.c:ads_sasl_spnego_bind(213)
  ads_sasl_spnego_bind: got OID=1 3 6 1 4 1 311 2 2 10
[2009/02/02 12:55:27, 3] libads/sasl.c:ads_sasl_spnego_bind(222)
  ads_sasl_spnego_bind: got server principal name = not_defined_in_RFC4178@please_ignore
[2009/02/02 12:55:27, 3] libsmb/clikrb5.c:ads_krb5_mk_req(593)
  ads_krb5_mk_req: krb5_cc_get_principal failed (No such file or directory)
[2009/02/02 12:55:27, 1] libsmb/clikrb5.c:ads_krb5_mk_req(602)
  ads_krb5_mk_req: krb5_get_credentials failed for not_defined_in_RFC4178@please_ignore (Server not found in Kerberos database)
[2009/02/02 12:55:27, 1] utils/net_ads.c:net_ads_join(1470)
  error on ads_startup: Server not found in Kerberos database
Failed to join domain: Improperly formed account name
[2009/02/02 12:55:27, 2] utils/net.c:main(1036)
  return code = -1

Turns out that it was the version of samba we were using. Version 3.0.28 had issues with joining a Windows Server 2008 Active Directory domain. This was fixed in Samba 3.0.28a and as can be seen with the FreeBSD ports commit:

Revision 1.169download - view: textmarkupannotated - select for diffs
Thu May 1 16:32:53 2008 UTC (9 months ago) by timur
Branches: MAIN
Diff to: previous 1.168: preferredcolored
Changes since revision 1.168: +2 -2 lines

Update port to the 3.0.28a revision.

Major changes:

  o Failure to join Windows 2008 domains
  o Windows Vista (including SP1 RC) interop issues

Approved by:	shaun (mentor, implicit)

So if you find yourself hunting around chasing something that surely should work.. consider upgrading samba!

Filed under: active directory,ad,domain,net ads,News,OpenSource,samba,UniSA — Benjamin Close @ 11:35 am



November 25, 2008

For a while now I’ve been working on modifying FLTK to support multiple Mice. We need this functionality for applications we are working on. FLTK was chosen for a number of reasons. 

  1. It’s light weight
  2. It’s cross platform
  3. It was already in use by the applications being extended.
However, FLTK didn’t support multiple mice out the box. Multiple Mice support exists both under Win32 via the RAWINPUT api and under Xorg via MPX.
Though support in the various toolkits is still lacking. Not surprizing considering how recent MPX/RAWINPUT is.

MPX was the natural choice for the first implementation of multiple choice in a toolkit. 
MPX is built into the windowing system hence focus, grabs and cursor rending is all semi transparently delt with where as RAWINPUT has you doing most the work yourself.
Hence I set about modifying FLTK to support Multiple Mice using MPX.
Results so far have been quite good. Due to FLTK internally doing most of it’s own component hit testing, having to deal with a window per component wasn’t needed. Instead a simple API extending the existing toolkit has been created.
The patch implementing this API and the relevant glue to use it is available at: http://wcl.ml.unisa.edu.au/~closebs/downloads/fltk-1.3-mpx.patch
This patch against the current 1.3 SVN (rev 6524) development branch and provides the following API extensions:
Creation of FL/Fl_Mouse.H which defines two important types:
Types:
  • FL_MouseID - A type indicating the id of a mouse
  • FL_Mouse   - A type that records information about a mouse (ie x, y, button state, etc)
Functions/Variables
New functions/variarables in FL/Fl.H
  • FL::e_mouse_id       - The id of the last mouse to cause an event
  • FL::e_last_mouseid - The id of the last mouse in the system
  • Fl::grab(Fl_MouseID)- Put a grab on a specific mouse
  • Fl::get_last_mouseid- Return the ID of the last mouse know to the toolkit
  • Fl::create_mouse() - Register a new mouse with the toolkit
  • Fl::event_mouse_id()- Return the id of the mouse that caused the last event
There has also been a number of changes to existing functions but all in a way which should be API compatible – sadly not ABI compatible.
These changes basically support passing in mouse id’s or storage of grabs/focus per mouse, etc.
There’s also been a test application created: test/multiplemice
This application, whilst very simple shows an example use of the MULTIPLE_MICE functionality. In it you can use two mice to drag two FLTK widgets around at the same time. 

I want to try

If you want to give the FLTK changes a shot it’s fairly simple all you have to do is:

 

  • Build a version of Xorg with MPX support (see http://wearables.unisa.edu.au/mpx) for details.
  • Build a version of xinput with MPX support
    • This will allow you to create multiple mice via
      xinput create-master mymouse
      xinput list –short       # Take note of one of the mouse id’s, lets call it x and mymouse id y 
      xinput reattach  x y
  • Grab the latest version of the 1.3 branch of FLTK from SVN (http://fltk.org/svn.php)
  • Apply the patch at http://wcl.ml.unisa.edu.au/~closebs/downloads/fltk-1.3-mpx.patch
    • patch -p0 < fltk-1.3-mpx.patch
  • Configure with multiple mice support: ./configure –enable-multiplemice
  • Build the toolkit: make
  • Test the multiple mice application: test/multiplemice

 

Future

Win32 support is currently under way with large chunks being already done. Though the lack of native cursor rendering under Win32 is causing greif. Other patches not far around the corner are a custom cursor patch, which allows a custom cursor per mouse as well as the ability to capture input events from the toolkit and inject input events into the toolkit – great for distributed event reconstruction.

Filed under: fltk,MPX,multiple mice,News,OpenSource,toolkit,UniSA,win32 — Benjamin Close @ 3:53 pm



November 18, 2008

I’ve been recently trying to work out why jhbuild fails to build xorg on my FreeBSD box. Traditionally I compile to /usr/local/ however after wanting to experiment with MPX I’ve set things up so that I compile to /usr/local/MPX

Sadly this kept breaking in xorg/lib/libX11 with the error:

xcb_io.c: In function 'require_socket':
xcb_io.c:35: warning: implicit declaration of function 'xcb_take_socket'
xcb_io.c:35: warning: nested extern declaration of 'xcb_take_socket'
xcb_io.c: In function 'process_responses':
xcb_io.c:188: error: 'GenericEvent' undeclared (first use in this function)
xcb_io.c:188: error: (Each undeclared identifier is reported only once
xcb_io.c:188: error: for each function it appears in.)
xcb_io.c:189: error: 'xcb_ge_event_t' undeclared (first use in this function)
xcb_io.c:189: error: expected expression before ')' token
xcb_io.c:193: error: expected expression before ')' token
xcb_io.c: In function '_XSend':
xcb_io.c:332: warning: implicit declaration of function 'xcb_writev'
xcb_io.c:332: warning: nested extern declaration of 'xcb_writev'

 

For the life of me I couldn’t make sense of it. GenericEvent is defined in xcb/xcb.h and checking the preprocessor output xcb.h was being included. Likewise the lack of xcb_ge_event_t was baffling me as it was certain in xcb/xcb.h. It wasn’t till I looked a little closer that I realised that the wrong xcb.h was being used. Turns out that /usr/local/include/xcb/xcb.h was being used however I wanted /usr/local/MPX/include/xcb/xcb.h to be used. Hence I tried adding -I/usr/local/MPX to CFLAGS with no success and also tried setting CC=”gcc -I/usr/local/MPX” also with no success. It just didn’t make sense!

Looking at the gcc line, /usr/local/MPX should have been used first. It wasn’t until I finally check the preprocessor what it thought the system paths were did it all make sense.

The output from cpp is below:

Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719  [FreeBSD]
 /usr/libexec/cc1 -E -quiet -v -I. -I../include/X11 -I../include -I../include/X11
-I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -I/usr/local/include 
-D_LONGLONG -DHAVE_CONFIG_H -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -D_THREAD_SAFE -D_BSD_SOURCE
-DX11_t -DTRANS_CLIENT -isystem /usr/local/MPX/include xcb_io.c -o xcb_io.lo -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -fworking-directory -O0
ignoring duplicate directory "/usr/local/MPX/include"
ignoring duplicate directory "/usr/include"
ignoring duplicate directory "../include/X11"
ignoring duplicate directory "../include"
ignoring duplicate directory "../include/X11"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../include/X11
 ../include
 ../src/xcms
 ../src/xkb
 ../src/xlibi18n
 /usr/local/include
 /usr/local/MPX/include
 /usr/include
End of search list.

It turns out that jhbuild sets the environment variable C_INCLUDE_PATH, in this case to /usr/local/MPX/include. This variable adds a library to the system search path. Whilst it prepends to the system search path,  -I options prepend the system search path, hence with one -I option being /usr/local/include, we get the ordering incorrect and the wrong header is used.  

So now it was up to working out why /usr/local/include was needed. Searching config.log it turns out the bigfontproto was needed by libX11, pkg_config was searching for it and finding it not in /usr/local/MPX/lib/share/pkg_config but in /usr/local/lib/share/pkg_config. The reason for this is bigfontproto wasn’t listed as a dependancy in the xorg.modules file used by jhbuild (avaliable at:http://cgit.freedesktop.org/xorg/util/modular/tree/xorg.modules). Because of this bigfont proto wasn’t being built by jhbuild. Hence the only bigfontproto that existed on the box was the default system bigfont proto which WAS located under /usr/local/include. 

The fix was simple. List xf86bigfontproto as a dependency in xorg.modules and all was good. bigfontproto is now pulled in as a dependency and hence gets built before libX11. pkg_config now correctly finds bigfontproto in /usr/local/MPX/lib/share/pkg_config hence doesn’t need to fallback to the system version so -I/usr/local/include doesn’t get added to the gcc line. Hence the compiler uses /usr/local/MPX/include/xcb/xcb.h rather than the one in /usr/local/include/xcb/xcb.h and the compiler errors vanish.

So now things are building and I’m off for a coffee!
(xorg.modules has also been correctly updated so some other poor person doesn’t have the same issues).



« Newer PostsOlder Posts »

All content copyright © 1998-2010 Wearable Computer Lab.