DirectX Front-End finished

Today I finished the DirectX front end of my project. To be honest I should have thought of this in the first place.

First of all I can now display and simulate a real sphere with the artificial horizon on it, and I can rotate it pretty easily with rotation matrices from DirectX. Let me show you a picture and then comment on it:


Here you see a background PNG image file with transparency in the middle circle. Behind it is a sphere with a texture of an horizon wrapped around it.

Now, in DirectX or any other Graphics Engine API, the transformation of objects in a scene is done using Transformation matrices, for example: Translation, Scalling or Rotation. The last one is the one we are interested in, and since we normaly can move in 3-Dimensions, then it is normal that we have 3 kinds of Rotation Matrices, one for each axis. To combine the effect of any transformation matrices you just have to multiply them in the order you want them to take affect.

Therefore it is now standard arithmetics to convert the reading from the Accelerometer (3 Voltages for 3 axis of movement) to 3 Rotation Matrices which multiplyed give the relative position of the accelerometer board.

I now must add a CALIBRATE button to the scene, to remember the normal horizontal position, and implement an .ini file system for the hardware configuration. Wish me luck!

Agony and pain

During these last few days I began to write the computer frontend of my Artificial Horizon application, using MFC. It has proven to be the worst decision I made since the beginning of this project. I am using Visual Studio 2008 and MFC 8.0 and I thought that Microsoft had improved the stability of MFC applications, but I was wrong. It is incredibly buggy, and the IDE seems to work against the programmer. Every time I added a header file, I had to restart Visual Studio to update IntelliSense, if I deleted a simple editbox from the Resource View I had to manually delete all the references that were automatically added at creation and so on.

The PictureBox control of MFC only allows to display BITMAPS, and I need to be able to display PNG image files with transparency. After an extensive search on the net I learned that I could use CImage, which is an ATL template. It is capable of displaying PNG files in an MFC dialog. I easily wrote a test program, it worked fine at first glance, but after closer inspection I saw that the transparency did not extend to the picture beneath the first PNG, but only to the background color of the CImage control. Another dead end!!

Then I wrote a simple program in a Windows Forms project, which is normal Visual C++ combined with .NET. I managed to get the desired result from the use of it's PictureBox control, but the drivers for the PC/104 platform generate 240 errors at compile time...

I closed the programming session, before I exploded... After cooling of I found a possible solution, and that is to use DirectX.

I will make another post when I have some progress with DirectX.

Artificial Horizon Progress 1

Today was a crucial day for this project because I tested the accelerometer breakout-board at work with an oscilloscope to view the actual variations in voltage associated with the movement of the board.

Just a few days ago I finished the assembly of the board. I planned to use 4 springs attached at one end to the 4 corners of the PCB and at another end to a solid back piece, so as to move the board and then release it, to come back to its original position. This didn't work unfortunately, looks like I need some serious springs, and the trouble of finding them is just not worth it.

Let me show you a couple of photos of the finished board:

In this last photo you can see the connector with 8 pins and 6 cables and a 3 pin connector for the power supply (don't worry, only two pins are actually used)



I stole a 3.3 V voltage from the second pin from the left and placed it on the last pin which is the SLEEP pin, and as you guessed it is activated in 0, so I need to set it to 1 so I can get a reading out of the X, Y and Z pins.

I have left 2 pins unconnected, because I want to leave the accelerometer in its default range of 800mV/g and a maximum of ±1.5 G detected on any axis. Thanks to the reading I got today from the oscilloscope, this range of detection is perfect for my application.

I must admit that this type of sensor is truly amazing, at a level state, the X and Y axis are at mid-supply (i.e 1.6V) meaning no G is detected, while Z axis signals it is sensing 1G (i.e. 2.4V). If I turn the sensor up-right, the Y arrow on the PCB points down so the Y pin is at 2.4V, meaning 1G, which is correct, because it is sensing the natural attraction force of the earth. Now if I turn it up side down, the Y pin is at 0.6V meaning -1G(the arrow for the Y axis is pointing away from the earth)

Feeling pretty happy right now... I leave you with my messy desk:

Shopping again

I went shopping for parts that help me mount and interface my PCB accelerometer to the PC/104 system from my Faculty.

So I bought :

• 2 9x15 cm perforated test boards
• 1 NSL 8 pin connector
• 4 springs hacked from 4 identical pens

Here are some pictures:



The design will become apparent later on, as It is hard to describe it in words.

I must mention that I have not tested the accelerometer yet, I will do that as soon as I solder the parts enumerated above.

First success and another challenge

I managed to finish the Etch a Sketch project. It has been a good learning trip for me, and I can not wait to start another project.

Today was a good day to pay tribute to international mail service, because I received an important package. My license project implies the use of an accelerometer, and after long searches on the Internet, I ordered the part from Sure Electronics, a company based in China. Well it came and can't wait to start fiddling with it.

Here is a picture of it:It's called 3-Axis low-g Accelerometer MMA7260 prototype PCB, and it measures the G forces on all 3 axis of orientation, it has analog outputs so I must use an ADC to convert the output voltages to useful digital data.

I will make another post to show you how I will mount this PCB onto a bigger control surface.

At last some news

It has been a while since my last post, mainly because I have been very busy with school and stuff, but know I finished most of my school duties and I can now focus on my personal projects.

Needless to say, I had a lot of time to think about new projects, and some of them seem interesting, but first things first, I have to finish what I have started a few months ago and that is my Etch a Sketch embedded clone.

Las time I wrote in this blog, the hardware part was finished, all that was left was the software, both the embedded software and the computer software. Let me specify that I have worked on this project in my spare time(very limited indeed) and some things have changed, my previous post has now become veryyy obsolete, and as a lesson learned, I will reframe myself from posting code until it is working 100%.

The main changes are as follows:

• OpenGL was not needed for this project
• I used Visual C# to write the computer frontend
• The embedded software now waits for a request for data from the computer, acquires the data from the 2 potentiometers, and sends it back to the computer software, this repeats several times a second

I have learned some important lessons in hardware design like how to arrange wires as to not interfere with each other. This is important because the approach I used in my last software design was to send data through the wire only when the data read was different that the last reading. In theory this sounded perfect, the simulator worked perfect, but as I was told again and again, a simulator never replaces the real thing. In real world operation the data read was very gettered, and oscillated between several very close values, and ended up that the hardware was sending data very often, the exact thing I was trying to avoid.

I will begin work again to finish this project and to move on to another. In order to consider this project finished, I have to implement an error detection system on the computer side to ensure that the data read from the hardware is formated correctly. At the moment the software sometimes goes nuts and displays strange lines as a result of bad input.

Embedded C Code

PLEASE READ THE POST ABOVE
-----------------------------------------------------------------------------------------
Below I have posted the content of the Embedded C PIC program (CC5X compiler) that drives the software inside the microcontroller. It basically sends the readings from the 2 potentiometers at the very beginning, and then stop transmitting, until it notices a change in any value. If that happens it modifies the high order byte of the conversion in order to notify the computer as to which potentiometer has changed its value.

#pragma chip PIC16F870

#include

#pragma origin 4

bit channel_is_0; //global variable to flag that first A/D channel is selected
unsigned char old_low0; //last converted low byte of channel 0
unsigned char old_high0; //last converted high byte of channel 1
unsigned char old_low1; //last converted low byte of channel 0
unsigned char old_high1; //last converted high byte of channel 1

interrupt isr(void)
{
int_save_registers
if (ADIF == 1) //if we have an interrupt from ADC conversion
{
// if channel 0 conversion and low byte value is different than the last, OR
// if channel 1 conversion and low byte value is different than the last
if (((ADRESL != old_low0) && (channel_is_0)) || ((ADRESL != old_low1) && (!channel_is_0)))
{
while (TXIF !=1 );
if (channel_is_0)
ADRESH.7 = 1; //signal the computer that this is the reading for the first channel
TXREG = ADRESH; //send last 2 bits of the conversion

while (TXIF !=1 );
TXREG = ADRESL; //send first 8 bits of the conversion
}
if (channel_is_0)
{
old_high0 = ADRESH;
old_low0 = ADRESL;
}
else
{
old_high1 = ADRESH;
old_low1 = ADRESL;
}

ADIF = 0; //clear the flag
}
if (RCIF == 1) //we have a byte received in the buffer
{
if (RCREG == 255)
ADIE = 1; //enable A/D interrupt
else
ADIE = 0; //disable A/D interrupt
}

int_restore_registers
}


void main(void)
{
//configuration of ADC
ADCON1 = 0b.1000.0100; //RIGHT Justified format, all pins of PORTA are analog inputs)
ADCON0 = 0b.0100.0001; //FOSC/8, channel 0, ADC module is now ON
//next we must enable global interrupt from ADC complete conversion
INTCON.6 = 1;
INTCON.7 = 1;
//clear ADC interrupt flag bit
ADIF = 0;
ADCON0.2 = 0;
RCIE = 1; //enable reception interrupt
//next we must configure the UART Transmit
SPBRG = 25; //this would generate a 9600 baud rate
TXSTA = 0b.0010.1100; //8 bit trabsmission, enable transmit, async mode, high baud rate
RCSTA = 0b.1001.0000; //serial port enable, 8 bit reception, enable reception
while(1)
{
if (ADCON0.2 == 0) //if ADC GO bit is not set
{
if (ADCON0.3 == 1) //if first channel is selected
{
ADCON0.3 = 0; //select the second channel
channel_is_0 = 0;
}
else
{
ADCON0.3 = 1; //else select the first channel to convert
channel_is_0 = 1;
}

ADCON0.2 = 1; //Set ADC GO bit
}
}
}