The new high-torque winch servo is 44x22mm instead of the standard 40x20mm, so we made a new radio-plate for it today. The new plate has a bigger cut-out for the new servo, and is slightly wider. The boat will sail again next weekend so we will hear how the new servo works then.
Update: this figure shows the numbering of vertices(red), edges(green), and faces(blue). The arrows show the direction of the X-(red), Y-(green), and Z-axes(blue).
Here the sides of the cube are not generated with Marching-Cubes, they are just extracted directly from the octree. Nodes are subdivided whenever the signed distance-field of the cutter indicates that the surface is contained within the node, i.e. the distance-field evaluates to both positive and negative at the eight four vertices of a node. This apparently leads to transient holes in the surface when the cutter is just about to enter a coarse node which hasn’t been subdivided very far yet. It should be possible to adjust the subdivision criterion so that the octree ‘anticipates’ the cutter slightly and subdivides ahead of the actual cutter surface.
Gone is the HiTec light-blue box, and replaced with a clear one. These servos, which HiTec calls “monster torque” 
are designed for either 6.0V or a LiPo pack at 7.4V. They are about 10% bigger than the standard 20×40 mm footprint, and produce 36 kg*cm (6.0V) or 44 kg*cm (7.4V) of torque. To be tried as a winch servo in the prototype PIKANTO.
CNC-milled three hemispherical (ca 50mm diameter) holes into these bits of plastic yesterday. To fit a steel cup (far left), attached by gluing.
The speed of the new cutting-simulation code makes it possible to run it at a higher resolution than before. That makes the surfaces look smooth and nice. Alas, some problems still remain with holes in the fabric of reality mystically appearing and disappearing .
There is an edge-flipping paper by Kobbelt et al. from 2001 which improves the jagged/aliased look of sharp edges.
Update: Kobbelt provides a LGPLv2 licensed sample-implementation of the algorithm here: http://www-i8.informatik.rwth-aachen.de/index.php?id=17
Been there, done that, have the medal, have the T-shirt!
It was hot and it was humid. I also had a strange ache in both my knees and my ankles which towards the end made each step forward painful. I was doing OKish through 30km and a bit further, but after that the walks at the drinking stations became longer, and I walked the uphills towards the end. Finished in 4h 42min. The breakup into 20k/10k/5k times shows how I got more tired towards the end:
The first 20k took 2h1min and the second 2h 23min.
The first 10k took 59min, 2nd 62min, 3rd 67min, and 4th 76min.
5k times: 29min, 30min, 30min, 31min, 33min, 34min, 36min, 40min
Temp(left) and humidity(right) data from FMI for around 15-19 o’clock shows T=23-25 C and RH=70-80% at least.
In colder weather, with a bit more training, and without the knee-ache, the next goal must be to break 4h!
Update: the finishing times are distributed like this:
This histogram was produced by scraping the results website with one python script and the plotting the results with another.
Download the scripts hcm_scrape.tar (works on Ubuntu 10.04LTS)
A whole series of histograms are on picasa: http://picasaweb.google.com/anders.e.e.wallin/HCM2010Statistics#
This is my second attempt at a machining simulation where a moving milling tool cuts away voxels from the stock material. To save space an octree data structure is used to store the voxels, and to produce a nice looking surface you store the signed distance to the exact surface in each vertex of the octree. You then use marching-cubes to extract triangles for a distance=0 isosurface in order to draw the stock.
Unlike my first attempt, this works well enough to warrant further experiments (on the to-do list are: differently shaped tools, colouring triangles based on which tool cut the voxel, lathe operations, material removal-rate, etc.). It should be straightforward to hook this up to the EMC2 G-code interpreter so that any G-code, not just densely sampled CL-points from OCL, can be simulated. You could also flip the sign of all the numbers, and simulate an additive process, like 3D printing (reprap / makerbot).
This approach to machining simulation is described in a 2005 paper by Yau, Tsou, and Tong.
