Author: admin

Cutsim driven by g-code

Based on Mark Pictor's cam-occ work I've been able to use the emc2 g-code interpreter 'rs274' binary that gets built during an emc2-build. It reads g-code files and outputs 'canonical' motion commands (see e.g. "The NIST RS274/NGC Interpreter - Version 3"). I'm positioning the tool at densely sampled points along each move, and subtracting it from the stock (see Yau and Yau) . The stock model is a distance field stored in an adaptive octree (see Frisken and Frisken).

This is very experimental: There's one kind of stock and one kind of tool, namely spherical!, The stock and tool sizes and colors are hard-coded, There's only one thread which means the UI becomes unresponsive and greyed-out during about 57s of processing. It's slow, 57s for a fairly simple 20-line g-code file. We assume hard-coded paths for the 'rs274' binary and the emc2 tooltable-file.

Another milky way time-lapse

Before shooting auroras, I captured 60s exposures for this milky way time-lapse:

The bright star that starts out about mid-height to the left of the middle is Deneb, the brightest star in the constellation Cygnus. As it swings down and to the right the Andromeda galaxy becomes visible in the top left corner towards the end of the video.

Aurora Borealis, Oravais

Some nice northern lights (aurora borealis) appeared just as I was going to pack away by tripod and camera after shooting another fixed-tripod milky-way time-lapse.

So no packing away and instead Aurora Borealis shooting for another three hours. These are 20s exposures through a 17mm/F4 lens on a Canon 500D at iso3200. Fixed tripod.

The time-lapse video is 340 frames shot from around midnight to 3am on Wednesday 28th September 2011 looking north from Oravainen, Finland. As with all photography the camera sees things differently from the eye. The lights look brighter and more yellow on the camera, and the red hues visible on camera are very faint or nonexistent by eye.

Photo equipment was fairly simple: I hung a plastic bag containing stones on the tripod to stabilize it in the wind. Timing and shooting with an intervalometer. Shoe-driers taped to the lens with masking-tape worked as improvised dew-heaters. I'm using a Canon ACK-E5 powersupply so I don't have to change batteries constantly.

Time-lapse movie was compiled by first resizing images (JPEGs straight from the camera, no modifications) with
mogrify -resize 1280 *.JPG
and then compiled into a movie with
mencoder -nosound mf://*.JPG -mf w=1280:h=853:type=jpg:fps=8 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=2160000:v4mv -o movie.avi

Update: I also had my older 20D camera with me, and a 50/1.4 lens. No tripod, just camera placed on a wooden board pointed towards the sky. No dew problems despite no dew-heater. Here is a time-lapse of ca 400 frames exposed for 3 s. This is much darker than the first video, and doesn't bring out as much red/yellow color. This is probably closer to how it looks to the naked eye.

Octree operations

I've looked at set-operations (union, difference, intersection) for octrees again. Previously I tried it with linear-octrees and visualization with python and VTK. Now I'm using a traditional pointer-based octree data-structure, and drawing with OpenGL VBOs. With the addition of a g-code interpreter, a user-interface, and an isosurface extraction algorithm (such as marching-cubes) this should converge towards a milling/turning/3d-printing cutting-simulation sometime soon...

References: Frisken2000 and Frisken2006.

Quassel notes

To keep myself "forever" logged onto IRC, I wanted to run quassel-core on my isp shell-account, and quassel-client on whatever computer I am using at the moment (home/work/laptop, etc).

I first downloaded the statically linked core quasselcore-static-0.7.3.bz2 and unzipped it onto the server.

To use SSL, a certificate on the server is needed, made by copy/pasting from the quassel-wiki:

openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout ~/.config/quassel-irc.org/quasselCert.pem -out ~/.config/quassel-irc.org/quasselCert.pem

Then, my ISP doesn't have the port open that quassel uses (4242), so the connection needs to be tunneled through SSH. For testing a 'local port forwarding' tunnel can be opened like this (this is run on the client machine):

ssh -lmy_user -L 4242:localhost:4242 my.remote.server

If I understand correctly this redirects traffic trying to connect to 4242:localhost through SSH (port 22), and actually connects to 4242:my.remote.server. However it isn't convenient to always have to type in the password when opening the tunnel, so I set up SSH login without password.

Now we can go ahead and start the server, under screen, so that it stays alive when I log out of the server shell. The server-side (quasselcore) needs no further configuration through the server shell.

screen
./quasselcore-static-0.7.3
CTRL-A - d (to detach screen)
logout

Now we can connect with quassel-client, specifying 4242:localhost as the server. When doing this for the first time quassel-client will ask for some set-up data. It's possible to use an SQL server backend on the server-side, but I'm using SQLite.

Then I started googling for advice on how to automatically start and keep alive an SSH tunnel on Ubuntu. There seems to be no consensus on how this is best done, and two or three attempts I tried failed. Most seem to use autossh. Ry4an's blog suggests an upstart script (but I couln't get that to work, and it requires a special user with no password). Or should it be done with a script in /etc/network/if-up.d ? Since I only use the this SSH-tunnel with quassel-client, maybe the easiest solution is to create a launcher-script that first opens the SSH-tunnel, and then launches quassel-client (how do I kill the tunnel when quassel-client exits?). Suggestions? sshuttle?

For now quassel-core has been running OK on the server for a few hours, and everything seems to work. I'll be able to test connecting with more clients from home later... stay tuned.

Drumsö Runt

19k long slow run around lauttasaari on Saturday. Since the shoreline of an island is supposed to have a fractal dimension greater than one, it's possible to lengthen the run by following the shoreline more closely. Here the lap around the island is about 16-3 = 13km.

Between 6-7km and slightly after 7km it's probably possible to run on the cliffs and in the woods to get a bit more distance. I'm not sure about the area around 10km, seems private with no path around the shoreline. At 12km and slightly after 14km I don't think there's a shoreline-path either.