There is still a long way to go before this can be called successfull VTOL concept, but it would be really interesting to see how far it is possible to push this hybrid flying wing design.

Stay tuned!

Today I scrapped together some of my old parts to see if I could make something new, the result was this. The airframe is made of some scrap materials and it does not have a real airfoil. The powertrain comes from two brushless motors and accompanying speed controllers from an old scrapped 450 size quadcopter. The flight controller is an extremely cheap NanoWii MultiWii controller configured as a bicopter. I had serious doubts that it would even get off the ground but after a failed attempt with a two cell battery. I slapped a three cell on the plane, the result is below:

There is still a long way to go before this can be called successfull VTOL concept, but it would be really interesting to see how far it is possible to push this hybrid flying wing design.

Stay tuned!

Labels:
arduino,
model airplane,
multirotor,
multiwii,
open source,
rc,
vtol

Location:
Røros, Norge

I am interested in ways of approximating differential equations numerically. Yeasterday I read up on the basics of Smoothed-Particle Hydrodynamics, or SPH for short. It is a way of approximating a PDE using a finite set of particles that represent a quantity, eg. a fluid. To read more about the basics of the method take a look at this PDF.

The algorithm was first prototyped is Octave (Matlab) and found to slow. Then I coded a native C version with SDL graphics and OpenMP to speed up some of the calculations, it worked pretty well. The code is available at my GitHub. A video showing the live rendering is embedded below.

As the video shows the liquid is extremely pressure driven and thus does not represent incompressible liquids, like water. The physical correctness of this simulation as a whole has to be taken with a grain of salt because of the extremely simple implementation. But it serves as a very*visual* way of communicating how the method works and what strengths/weaknesses it has.

One nice property is that the method conserves mass.

The algorithm was first prototyped is Octave (Matlab) and found to slow. Then I coded a native C version with SDL graphics and OpenMP to speed up some of the calculations, it worked pretty well. The code is available at my GitHub. A video showing the live rendering is embedded below.

As the video shows the liquid is extremely pressure driven and thus does not represent incompressible liquids, like water. The physical correctness of this simulation as a whole has to be taken with a grain of salt because of the extremely simple implementation. But it serves as a very

One nice property is that the method conserves mass.

This semester I have been studying at Queensland in Australia, more specificly at Queensland University of Technology in Brisbane. Even though most of a semester abroad is about what happens outside school this post is focused on school.

I have taken a course in Parallel Computation at QUT. As a semester project I created a direct distributed memory solver for Poisson's equation. The solver is written in plain C taking use of technologies as OpenMP, BLAS and OpenMPI.

Compared to a naively written single core solver written in C my solution had a speedup of 200 on a 50 core cluster. Compared to a bleedingly optimized sequential implementation taking use of the Intel MKL library for hand tuned matrix multiply code a speedup of 20 was measured. The distributed nature of the solver can also cope with much bigger problems than the sequential implementation. One run was done over 64 nodes each using 8 cores, that is 512 cores. The problem was a finite difference discretization with 32000x32000 grid points. Calculating the solution took only 2 minutes. A sequential implementation would use take several days to finish. All the code is as usual available in my GitHub together with the report.

I have taken a course in Parallel Computation at QUT. As a semester project I created a direct distributed memory solver for Poisson's equation. The solver is written in plain C taking use of technologies as OpenMP, BLAS and OpenMPI.

Compared to a naively written single core solver written in C my solution had a speedup of 200 on a 50 core cluster. Compared to a bleedingly optimized sequential implementation taking use of the Intel MKL library for hand tuned matrix multiply code a speedup of 20 was measured. The distributed nature of the solver can also cope with much bigger problems than the sequential implementation. One run was done over 64 nodes each using 8 cores, that is 512 cores. The problem was a finite difference discretization with 32000x32000 grid points. Calculating the solution took only 2 minutes. A sequential implementation would use take several days to finish. All the code is as usual available in my GitHub together with the report.

I had the pleasure of taking shots for the closing ceremony movie at ISFIT 2013. The shot's where taken by a GoPro Hero3 strapped to my quad. Movie below, my 5 seconds of fame starts at 6:00

ISFiT 2013 from ISFiT on Vimeo.

To test my understanding of the FDM method I made a simple implementation of the Crank-Nickelson method
applied on the heat equation. The physical intepretation is this:
You have a perfectly insulated rod of length $l$.
At time $t_0$ you know the temperature distribution in the rod, $f(x)$.
You also know that each end of the rod will have a temperature that is a
function of time, $g_0(t)$ and $g_1(t)$.
Given this information, what will the temperature in the rod be at an arbitraray
time $t$ and position $x$?
This is what the heat equation tells you, the problem, as usual with partial differential equations is that
you can't always solve them explicitly. This is where numerical techniques comes to play and saves the day.
Below is the result of a numerical simulation of such a senario.
For simplicity the rods length is $1$.
\[
f(x) = (2+2 \sin(6 \pi x)) (1-|2(x-1)|), 0\leq x \leq1
\]
\[
g_0(x) = g_1(x) = \sin(t), 0 \leq t
\]
This gives rise to the following solution:
Here is the Octave code that calculates this plot, quite simple and self explanetory:

M = 401; % number of space nodes h = 1/(M+1); % space step size T = 40000; % number of timesteps t = 0.0000005; % time step size %U0 = 1-abs(linspace(-1,1,M)); % initial data U0 = (2+2*sin(linspace(0,6*pi,M))).*(1-abs(linspace(-1,1,M))); % initial data G1 = sin(linspace(0,2*pi,T)); GM = G1; r = t/h^2; U = zeros(M,T); U(:,1) = U0; n = M; e = ones(n,1); A = spdiags([e, -2*e, e], -1:1, n, n); lkern = eye(M) + (r/2)*A; rkern = eye(M) - (r/2)*A; %for y=1:100 U(:,1) = U0; for i=1:T-1 U(:,i+1) = rkern\(lkern*U(:,i)); U(1,i+1) = G1(i+1); U(M,i+1) = GM(i+1); end %end downscale = 1000; Y = zeros(M,T/downscale); for i=1:T/downscale; Y(:,i) = U(:,downscale*i); end tx = linspace(0,1,M); tt = linspace(0,t*T,T/downscale); hold off mesh(tt,tx,Y); %contour(U) ylabel('space'); xlabel('time');

I've done a good deal of tinkering since the last post. A new frame was ordered from HobbyKing, replacing the homemade one. This got rid of the vibrations that the pine one had problems with. I also changed the controller ho a Kaptein KUK controller. It's much simpler and cheaper. That way I can try out and experiment whitout worrying about crashing. Here are two videos of the new version flying.

This one was done right after I had changed the frame, see the difference is stability.

In this one i stuck my mobile phone to the copter and did some flying around the garden at home in Røros.

This one was done right after I had changed the frame, see the difference is stability.

In this one i stuck my mobile phone to the copter and did some flying around the garden at home in Røros.

I'm found of music, it colors my day. This also applies to the rest of my family. Because of that I've set up an Ampache server where we add our music. This makes it really easy to discover new music and listen to eachothers suggestions.

The only problem with Ampache is that all the clients, well, they suck. There are a lot of half finished plugins, small tests etc. but no real client that just works. Works cross platform. Lets you cache music so that you can listen to it while offline etc. All these nicks and picks made me so frustrated that I started rolling my own. I wanted this:

- Browse artist/album/track
- Cache things so they are available offline
- Be truely cross platform

I started hacking at an already existing python player Quickplayer. It worked out ok untill I needed to change the interface while keeping it cross platform. I realized that this would never work.

After some thinking I started wishing I could've done it as a webpage, that would be esay except for the "offline" mode. I read around the net and discovered that Chrome apps actually can be offline, as well as get permissions to XMLHttpRequst to an arbitrary host. This combined with the new File Api support was all I needed. I started coding and in about 3-4 days I had a finished player.

It's written as a Chrome app, that is a tottally normal webpage only that it's hosted from your harddrive. It also has relaxed access control allow origin so that I can communicate with the webserver that runs the Ampache instance.

It lets you create your own subset library from that is cached locally, enabeling you to listen to your music wherever you've got your laptop.

To view it in the Chrome Web Store.

The code is available at GitHub.

Cheers!

Subscribe to:
Posts (Atom)