## Sunday, March 24, 2013

### Minimal HTTP Server Example with WiFly RN-XV and Teensy3.0

The following code is a minimal example for serving content from a Teensy3.0 using the RN-XV WiFly module. The code assumes that the WiFly has been set up to use a baudrate of 115200 bps and has also been set up to receive connections on port 80 via the commands:

set uart baudrate 115200
set ip localport 80


The basic setup procedure that I used is detailed in a previous post covering how to set up an ad-hoc network to configure the WiFly along with some example code make a Teensy3.0 and WiFly operate as an echo server.

Assuming this is done, the following code will serve up a simple HTML page that alternately displays "Welcome!" or "Booyah!" when the page is reloaded.

int read_message( const char *msg, int len ){
for( int i=0; i<len; i++ ){
while( !Serial3.available() ){ }
return 0;
}
return 1;
}

int pos = 0;
char c = '\0';
while( c != '\n' ){
if( Serial3.available() ){
line[pos++] = c;
}
}
line[pos] = '\0';
return pos;
}

void send_response( const char *data ){
Serial3.print( "HTTP/1.1 200 OK\r\n");
Serial3.print( "Content-Type: text/html\r\n" );
Serial3.print( "Content-Length: " );
Serial3.print( strlen( data )+1 );
Serial3.print( "\r\n" );
Serial3.print( "Connection: Close\r\n" );
Serial3.print( "\r\n" );
Serial3.print( data );
Serial3.write( (byte)0 );
}

void handle_connection( int val ){
char cmd[128], line[128];
if( !read_message( "*OPEN*", 6 ) )
return;
Serial.println("client connected!");

Serial.println( cmd );
while( read_line( line ) > 1 ){
Serial.print( line );
if( line[0] == '\r' )
break;
}

const char *page[] = {
"<html><body>booyah!</body></html>\n",
"<html><body>welcome!</body></html>\n"
};
Serial.println("responding with" );
Serial.println( page[val%2] );
send_response( page[val%2] );

}

void setup(){
Serial.begin(115200);
Serial3.begin(115200);
}

int id = 0;

void loop(){
handle_connection(id++);
}


This is obviously some pretty brittle and stripped down code, there is no bounds checking on input, nor are the input requests parsed to see what they actually are.  Parsing the cmd string in the handle_connection function would handle this, however it does demonstrate serving pages from the Teensy.  Output is as expected when the IP for the RN-XV is entered into Firefox, alternating "Welcome!" and "Booyah!" as the page is reloaded.

With some simple input parsing, this would make it easy to do basic querying of the state of the Teensy.

### Setting up the WiFly RN-XV with a Teensy 3.0

A recent order from Sparkfun arrived, including a 3.3V Serial LCD and a Roving Networks RN-XV WiFly module.  The RN-XV module is intended to be a drop-in replacement for an XBee, except that it operates over WiFi.  At about $35, it is just about the cheapest way to make your project wireless enabled. The module is 3.3V, meaning some form of level shifting is needed with a 5V system like an Arduino. You can use this module with an Arduino via an XBee shield pretty easily. However it is even easier to use with the 3.3V Teensy 3.0 ARM board, provided you have a breakout for small-pitch XBee module footprint. The Teensy is also nice for this application because it has multiple serial ports, so you don't need to use the SoftwareSerial library, or program the board, then disconnect to use the wireless. Setting everything up was pretty easy once I knew what to do, but this post summarizes the process should I ever need to do it again. The setup that I am using is shown below: Only four connections are needed once you're set up, 3.3V, GND and two data connections. DOUT from the Teensy3.0 Serial3 connects to DIN of the RN-XV and DIN from the Teensy to DOUT to the RN-XV. This makes the module operate as just a serial port, making it pretty easy to interface with. The remaining orange wire connects the Serial LCD display, more on this later. To get started, I found it was easiest to set the RN-XV in ad-hoc mode. This can be done by connecting pin 8 to 3.3V and will cause the module to create its own wireless network. When this happens you will see the status LEDs blinking green, orange and red; they're doing it, but you can't really see in this picture. Note the additional green wire to 3.3V connected to the 8th pin. You can then look for the network. On a Mac it's pretty easy, it just shows up in the list of networks in the status bar: The WiFly shows up towards the bottom as WiFly-GSX-a8 or something similar. If you connect to this network, you can then telnet to the module using the IP address: 169.254.1.1, port 2000. The module should then respond with a *HELLO* string, at which point you type$ to enter command mode.  Command mode allows you to set up the module for your network.

When the module is ready, it will respond with the CMD message to indicate that you're in command mode.  To set up your network you can issue the commands:

set wlan phrase (password);
set lan ssid (your network name);
save
reboot


You can also issue commands to assign a static IP address to the module, but I didn't do this.  For more information, see this excellent introduction http://www.tinkerfailure.com/2012/02/setting-up-the-wifly-rn-xv/

I found that sometimes the module would respond with a confirmation and sometimes would not. I repeated the process a few times in the hopes that some combination would stick.  After this process, remove the power and and connection from pin 8 to 3.3V.  This will cause the device to try to connect to your wireless network.

You should now be able to telnet to the device, but this time with your computer and it connected to your normal WiFi network rather than the ad-hoc network that the device creates.  However first you need to find the IP address of the module.  To do this, I went into my router configuration page:

Conveniently the WiFly module had an entry: 192.168.1.106. Depending on your router, you should be able to set up a specific IP address for the router to assign to the module based on the MAC address.  However my POS router does not allow this.

I could then telnet to the module's IP address, again using port 2000.  This module responds with the same *HELLO* prompt, indicating that everything was successful and the module is on the network and communicating.

With the connections above the Teensy should now see the module as just another serial port.  To test this, I attached the Serial LCD and uploaded the following code to the Teensy:

#include<stdio.h>

void setup(){
Serial.begin(9600);
Serial2.begin(9600);
Serial3.begin(9600);
}

void write_lines( const char *L0, const char *L1 ){

Serial2.write( 0xFE );
Serial2.write( 0x01 );
delay(10);
Serial2.write( 0xFE );
Serial2.write( 128 );
delay(10);
Serial2.print( L0 );
Serial2.write( 0xFE );
Serial2.write( 192 );
delay(10);
Serial2.print( L1 );
}

void loop(){
if( Serial3.available() ){
char L0[17];
char L1[17];
int pos = 0;

L0[0] = '\0';
L1[0] = '\0';

while( Serial3.available() ){
if( c == '\n' ){
pos = 0;
Serial.print('\n');
} else if( c == '\r' ){

} else {
if( pos < 16 ){
L0[pos] = c;
pos++;
L0[pos] = '\0';
} else if( pos < 32 ){
L1[pos-16] = c;
pos++;
L1[pos-16] = '\0';
}
Serial.print( (char)c );
}
}
write_lines( L0, L1 );
}
delay(100);
}


My LCD is a 2x16 character display.  The code above just polls for available data on the third serial port and, when a newline is encountered, prints it out onto the display.  Lo and behold, after the following session:

Jamess-MacBook-Pro:~ jgregson$telnet 192.168.1.106 2000 Trying 192.168.1.106... Connected to 192.168.1.106. Escape character is '^]'. *HELLO* This is James  The result on the display is below: Hooray! An utterly useless internet thingy! ### Putting CMake binaries in a specific directory I've started using CMake for pretty much all my development work and have been quite happy except for a few minor issues. One of those is that the build-products are put in Debug and Release directories by default, instead of single output directory. You can add an install target to do this, but XCode won't apply it through the UI. Ditto goes for a post-build copy step. It took a while to find, but it's actually simple to get binaries placed into a directory of your choosing. In the example project, code and the CMakeLists.txt file is in the code/ subdirectory, I build using CMake/XCode in the build/ subdirectory and I want the build products placed in the bin/ subdirectory, regardless of whether they are built as debug or release. Here's the CMakeLists.txt file: cmake_minimum_required( VERSION 2.6 ) project( entropy ) add_executable( entropy main.cpp ) target_link_libraries( entropy${LIBS} )
set_target_properties( entropy PROPERTIES
RUNTIME_OUTPUT_DIRECTORY_DEBUG   ${CMAKE_SOURCE_DIR}/../bin RUNTIME_OUTPUT_DIRECTORY_RELEASE${CMAKE_SOURCE_DIR}/../bin
)


The set_target_properties() command allows you to set the runtime output directory. You'll see this a fix similar to this online in many places, but it will put the built executables in bin/Debug or bin/Release, instead of just bin/. What was not immediately obvious is that it can be set per-build-configuration, causing all build products to be put in bin/.

## Friday, March 22, 2013

### Symmetric Discretization of Linear Boundary Conditions

When solving large-scale PDEs, it's generally preferable (where possible) to have a symmetric discretization so that the conjugate gradient method can be used.  Conjugate gradient uses relatively little memory compared to more general purpose methods (like GMRES) and can also take advantage of symmetric preconditioners (like incomplete LDL^T) that are faster and use lower memory than preconditioners such as incomplete LU.

However applying boundary conditions to the problem can be an issue, since it is easy to end up with a non-symmetric matrix unless the constrained variables are eliminated from the system matrix.  This means that solvers like GMRES have to be used, which is costly in terms of computation and memory.

The following Matlab script gives an example for how to apply linear boundary conditions via an auxiliary boundary condition matrix suggested by a labmate of mine.  It shows both pin (Dirichlet) constraints and gradient (Neumann) boundary conditions at the domain boundary and in the interior.  The only downside is that Neumann constraints are a bit peculiar to specify since one of the variables must be eliminated from the boundary condition matrix.  However this can usually be specified fairly easily, and certainly more easily than eliminating the variable from the system matrix.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Example for showing symmetric discretization  %%
%% of general linear boundary conditions.        %%
%% (c) James Gregson 2013                        %%
%% james.gregson@gmai.com                        %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% solve a 1D Laplace equaiton with 8 mesh points
% subject to the constraint that the leftmost
% grid point has value 1.0 and the rightmost
% grid point has value 2.0 and the fifth is
% constrained to the value of the fourth minus 0.2
%
% then solves the same problem, but with a biharmonic
% operator, to show that the result is different
% from just pinning the values; i.e. the biharmonic
% energy is applied to the constrained grid points.
% If this weren't the case, both problems would have
% the same solution.

% the approach is to use a standard symmetric
% discretization of the Laplace operator A for all
% grid points (including those constrained by
% boundary conditions) and a second boundary
% condition matrix that enforces the constraints
% specifically, the boundary conditions are
% represented as:
%
% u = B v + c
%
% where u has the same dimensions as the Laplace
% operator and B has one column for every
% unconstrained grid-point.  c is a vector of
% constants. this allows the problem:
%
% A u = f
%
% to be written as:
%
% A*B*v = f - A*c
%
% however this is system is rectangular and
% non-symmetric.  This can be remedied by
% multiplying through by B', giving:
%
% B'*A*B*v = B'*(f-A*c)
%
% which is square and symmetric.

% define the objective function, in this case a
% 6-variable 1D Laplace equation. The Laplacian
% is discretized with a standard 3-point stencil
A = [  1, -1,  0,  0,  0,  0,  0,  0;
-1,  2, -1,  0,  0,  0,  0,  0;
0, -1,  2, -1,  0,  0,  0,  0;
0,  0, -1,  2, -1,  0,  0,  0;
0,  0,  0, -1,  2, -1,  0,  0;
0,  0,  0,  0, -1,  2, -1,  0;
0,  0,  0,  0,  0, -1,  2, -1;
0,  0,  0,  0,  0,  0, -1,  1 ];

% we are solving the Laplace equation, so the
% right hand side is zero
f = [ 0, 0, 0, 0, 0, 0, 0, 0 ]';

% the boundary condition matrix.
B = [  0,  0,  0,  0,  0; % first grid point, set to c[1]
1,  0,  0,  0,  0;
0,  1,  0,  0,  0;
0,  0,  1,  0,  0;
0,  0,  1,  0,  0; % fifth grid point, set to c[4]-0.2
0,  0,  0,  1,  0;
0,  0,  0,  0,  1;
0,  0,  0,  0,  0 ]; % last grid point, set to c[8]

% the boundary condition constant matrix
c = [ 1, 0, 0, 0, -0.2, 0, 0, 2 ]';

% form the system with boundary conditions
M = B'*A*B
rhs = B'*( f - A*c );

% solve for the primary variables
x = M\rhs;

% use the primary variables to solve for the
% grid values
u1 = B * x + c;

% now solve a biharmonic problem with the same constraints
% in the same manner, note the A' factor in the  system
% matrix and right-hand-side.
M = B'*A'*A*B;
rhs = B'*( f - A'*A*c );
x = M\rhs;
u2 = B * x + c;

% plot the results
figure
hold on
plot( u1, '-ro' );
plot( u2, '-b+' );
legend( 'Laplace', 'Biharmonic' );  

The plot produced by this script is shown below:

Both solves reproduce the boundary conditions correctly, but the biharmonic solve finds a solution that is smoother than the Laplace solution around the interior constraints.

## Wednesday, March 13, 2013

### Playing with Some Fluid Simulation

A recent project has me playing around with some fluid simulation.  I got some nice looking results and thought I would post a few.

The first is a buoyancy-driven flow simulated using a Marker-And-Cell (MAC) grid with the Boussinesq approximation.  This is simply a source term applied to the vertical velocity based on the fluid density, making it trivial to add to a basic solver.  Although I have no explicitly simulated viscosity, numerical viscosity is enough to cause some interesting unsteady flow effects

The second is a simulation of smoke in box, using a 3D 'Stable Fluids' solver with the first order advection replaced by the second-order 'BFECC' scheme.  This gives -way- better results than standard first order semi-Lagrangian discretizations:

The results compared to the first order scheme (shown below) are pretty impressive:

That's it..

### Reducing Warping/Shrinkage in Large 3D Prints

I've been doing a bit more 3D printing lately and having problems with large 3D prints warping due to uneven cooling. Most of the prints I work on are fairly large, roughly 10x8x4 cm or larger, so this can be a big problem, particularly if the dimensions change enough to mess up the fit of parts. Basically the problem is that as layers cool, they contract and pull off the build-surface. Generally I'm printing PLA on painter's tape, so this will just pull up the tape. An example is shown in the photo below:

You can see how the tape is pulled up at the near edge; this is about 2mm of shrinkage which is not too bad. But this is also a relatively small part, perhaps 5x5x4 cm, and the problem gets worse as the parts get bigger.  A partial fix is to use a heated bed, but the Gen6 electronics for my printer do not support controlling a bed.

However a more practical solution was suggested by another member of the Vancouver Hack Space.  He's working on a very large printer for very large prints; I highly suggest visiting his site ottersoft.ca if you're interested.  Anyway, his suggestion is to space the part up from the bed using some dummy geometry and then print with support material.  The support material forms less connected layers than the object, which gives it more...'give' when printing. Here's an example:

The little block is some dummy geometry added to lower the bottom of the geometry about 1.5 cm. When printed with support, the extra flex of the support lets the object stay attached to the bed without the terrible shrinking.

Part of this seems to be the extra flex, but I suspect that another part is less direct contact with the large metal build-plate, which acts like a heat sink, so the whole part cools more uniformly.

After pulling it off the build plate, you can see that the support material on both sides is in contact with the table, indicating little to no warping.  And this is a big part, roughly 10x8x3 cm.

The downside is that you now have to deal with the support material. If this is the same as the print material, it can be difficult to clean off without leaving a nasty surface finish or changing the part accuracy. For example, filing the support out of the horizontal holes without accidentally changing the hole diameter.  But once done carefully, the part is remarkably accurate: the height as measured at all four corners only differs by about 0.15 mm (with a layer height of 0.3 mm), and the holes are actually round and not elliptical.

I wish that I could take credit for this trick, but that belongs to Loial (ottersoft.ca) of VHS (hackspace.ca)