The process went pretty well,except at one point bitbake requires and enormous amount of resources. I had to increase the amount of memory available to my VM from 1GB to 1.5GB. Additionally there were a few packages that are currently out of date and need to be obtained from sources that are not the normal repositories. These are added to the /sources folder and the MD5 and SHA256 checksums needed updating for them in their respective recipes as well.

After the build I decided that instead of re-imaging the SD card with he new information, I overwrote the old information with the new to save time. The new installation worked and began a lengthy initial setup. After the setup was completed I was greeted by an Angstrom logo and a login for the board. Although pleased that the installation worked, there were a few problems withe the build. The key problems are that the USB drivers and the wireless drivers do not work. Apparently these drivers were not compiled into the kernel, or a module. Also because of a slightly newer kernel (2.6.35 vs 2.6.32) and the installation of Xenoami, the old drivers do not work.

I need to reconfigure the kernel and ensure that the modules will be compiled for the proper kernel version, then redo this image.

I also made sure to create an image of the “working” SD card so that in any case we will have a Xenomai kernel that works.

After the compilation of the new Xenomai kernel was completed I imaged the SD card with the relevant files. I ran into some trouble however with actually making the kernel boot and run.

Buildroot does not compile the first stage bootloader MLO so I had to pull that file off the boot partition of another SD card. The initial u-boot.bin that was compiled did not work, for unknown reasons so that was also taken from a second SD card.

Once writing all the necessary files, I was greeted by the MLO loading U-Boot which proceeded to load and decompress the kernel. Then nothing. The kernel “finished” decompressing and the bootloader indicated that the kernel was being given control. Following this statement no further output appeared on the terminal.

Today (March 26) I stumbled upon a general emulator with Beagleboard capabilities. I plan to spend sometime setting this up and testing various images with different build settings.

In his blog post he mentions two areas that create instability in the waveform. The first area is kernel context switches which delays the overall reaction time by a fairly predictable amount. The solution, which I have been looking at for a week or so as well, is to memory map the IO registers and manipulate them manually. Below is some code I wrote to facilitate this:

 md = open("/dev/mem", O_RDWR | O_SYNC);
volatile ulong *gpio;
gpio = (ulong*) mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, md, 0x49050000);
if(gpio == MAP_FAILED)
puts("Map Failure.");
close(md);

mmap is used to create a virtual map from the array gpio to the information pointed to by md. The last value is an offset which bases gpio[0] at md [0x49050000]. This value can be found in the OMAP 35xx Applications Processor Technical Reference Manual on page 3400. 0×49050000 is the base address for the GPIO Module 2. From this number each additional GPIO Module is indexed at +0×2000 from the previous module. Within each register segment are a number of registers which control the actions of a particular pin.

We are interested in GPIO_CLEARDATAOUT and GPIO_SETDATAOUT for the control of the PWM pulses. These two registers are offset at 0×0090 and 0×0094 respectively. Since the pins we are using are attached to Module 5 we will be be using an offset of 0×6000 for the module which results in a net offset of 0×6090 and 0×6094 for the CLEAR and SET. According to the documentation (also in the Reference Manual) these registers directly map to the pins in numerical order. When I tried to test this however I somehow blocked any input from the keyboard.

The second source of timing error mentioned in the blog above is from the fact that the linux kernel is not a realtime kernel by default. This means that when performing timing specific functions like waiting, there is no guarantee that the timing will be accurate. The sleep and nanosleep functions we would normally use the wait are not actually accurate timings. Xenomai is discussed as a realtime framework that runs as a sort of hypervisor for the linux kernel. I was originally trying to build Xenomai with the kernel manually, but the source files never matched up properly. Buildroot has been configured to work on the Beagleboard xM. Dr. Malinowski noticed that Buildroot includes an option for compiling Xenomai into the kernel automatically.

I have since begun the process of compiling the kernel using bultroot.

Sites:

http://x4350.blogspot.com/2011/01/digital-io-on-beagleboard-using-gpio.html

http://41j.com/blog/2011/09/beagleboard-gpio-input-driverless/

http://blog.galemin.com/2011/06/buildroot-2011-05-all-in-one-for-beagleboard-xm/

http://www.ti.com/lit/ug/spruf98v/spruf98v.pdf

http://buildroot.uclibc.org/

The industry standard protocol for communicating with servos is a form of PWM. The RC industry uses this PWM signal to communicate information between the receiver and servo driving hardware. The RC signal is actually a pulse repeated every 20ms with a “high time” of 1-2ms with the median value at 1.5ms. The 1ms and 2ms times represent -100% and 100% position (ala a joystick) on that particular channel. Our final PWM solution will require a number of divisions on each side of the 0% mark to accurately control the copter. As an initial benchmark point we are looking to implement at least 10% increments in the pulse. This would require 21 different “positions” (-100%, -90%,…, 0,…, 100%), ten each for positive/negative and one for 0%. This requires timing precision to the 40th of a millisecond or 25 microseconds.

I have been piecing together some code to implement a PWM signal from userspace. The code will be attached in the next entry. I borrowed the concept of a multi-threaded program and code foundation from here: PWM Generation in Beagleboard. The idea is to spawn a new thread for each necessary PWM channel and passing the thread a pointer to a structure containing timing information. Upon start the thread opens the gpio device file in “/sys/class/gpio###/value” where ### is the GPIO pin number. After the file is opened a cycle of changing the pin value and sleeping creates a PWM signal on the pin.

My modifications include creating 5 PWM threads and relevant structures, adding a sleep to main() replacing the spinlock (which actually doesn’t even look for a lock), modified the PWM thread function to include runtime channel setting and disabling the output buffer by using open() instead of fopen(). I also expanded the PWM structure to include a pin number so that the thread function will be able to allocate the pin at runtime. I currently maintain a bash script to open all the pins for writing, and closing them later but I plan to integrate this functionality into the main code this week.

I was also able to test my program, but found that the frequency and duty cycle were far too variable. I will likely need to run the process in a higher priority or make it into a kernel driver for PWM. This week I will also be mapping out 5 pins to use for PWM by manually testing my program on each possible pin until 5 of them work.

Nelson has been working on compiling a module called Servodrive which is a kernel driver specifically created for RC pulse generation on the Beagleboard. The Servodrive module is built using Open Embedded and Bitbake. Bitbake is a system which automates the process of creating an embedded Linux distribution including building toolchains, cross-compiling, and file systems. Bitbake is also about as well documented as my toenails. Nelson has more information on the “process” of bitbaking in his blog posts.

The presentation this week was interesting. We basically had to give a presentation to Professors Anakwa, Dempsey, Sanchez and Malinowski indicating the progress of the project and any revisions to the goals. The gist of our presentation is that we are behind a decent amount due to various reasons among which lack of documentation features prominently. The Beagleboard xM documentation is often cryptic, useless and flatout wrong. Major pin headers in the manual for our revision are incorrectly labeled and oriented, and some pins do not map where they are “supposed” to. We decided to revise our goals a bit to finish with a fly-by-wire system that uses on-board sensors to prevent the vehicle from colliding with obstacles. The camera and DSP material will be used to enhance the operation of the vehicle in some manner which has not really been pinned down yet.

Last week we determined that we would need to recompile the Linux kernel and U-Boot to properly modify the multiplexer settings. We are using a Linux Kernel 3.0.0 RC2 codebase with the DSP Bridge kernel driver code included. Also installed were the ncurses header files for menuconfig. The codebase can be obtained from git:

git clone git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git

Basic compilation process works like this:

make distclean
make ARCH=arm omap2plus_defconfig
make ARCH=arm menuconfig
make ARCH=arm CROSS_COMPILE=~/armgnu/arm-none-linux-gnueabi- uImage
make ARCH=arm CROSS_COMPILE=~/armgnu/arm-none-linux-gnueabi- modules

Line 1 cleans the source directories of all the generated object and configuration files, as well as final outputs.
Lines 2 and 3 setup the build configuration file which will determine which kernel features will be compiled in the final image. During the menuconfig step we need to enable the DSP Bridge Driver which is found under Device Drivers -> Staging Drivers -> DSP Bridge Driver. Note that Staging Drivers needs to be enabled and Exclude Staging Drivers From Being Built needs to be disabled.
Lines 4 and 5 compile the kernel image and any necessary kernel modules. The CROSS_COMPILE options indicates the location of the proper cross compiler. I chose to link a folder in my home directory (armgnu) to the bin folder for Code Sourcery. arm-gnu-none-linux-gnueabi- is a prefix attached to gcc and related binaries to indicate the proper cross compiler.

The above obviously builds ONLY the kernel image and modules and not any supporting programs and utilities.

On Tuesday the 14th Nelson started recompiling the Angstrom distribution on my laptop using Open Embedded. The process took a very long time, at least 6 hours. During this time I worked on finding a way to access the GPIO pins without modifying the kernel image. As it turns out the GPIO is abstracted into a file just like every other device. By writing single values of 1 or 0 to the proper file (one per pin) the state can be toggled. Currently I am writing some test code to determine exactly which pins will be usable on the expansion header for PWM. Once the pins have been determined I will be testing the timing precision available in the nanosleep() system function and delays inherent in accessing the pins through the OS. If no changes are required we will be able to use the foundation code as the framework for our end project. Code will be posted in a file on Thursday if completed.

The battery to power the system will be strapped to the bottom of the copter using a provided Velcro strap and fastening. The sensor unit containing gyros and accelerometers is mounted on top of the copter. We are thinking of mounting the BeagleBoard upside-down under the copter to both provide clearance for the camera and to correct for the camera’s flipped image.

Preliminary testing showed that the copter platform uses a minimum of 1.6A at 11.1V when the motors are activated at the minimum speed setting. We have not tested the copter with the propellers yet. The BeagleBoard has a current draw of 1.3A at 5V with the HDMI connected monitor and wireless dongle. Removing the monitor sees a reduction of about .05A and removing the wireless dongle sees a reduction of .2A. For the purposes of creating a suitable supply to convert 11.1V to 5V we will say the BeagleBoard draws 1.5A at 5V. Other electronics on the 5V power rail are the 6 IR sensors and the 8-channel ADC module.

We will be using a switching power supply created for Dr. Malinowski’s robots to convert our battery voltage into 5V. We will however need to spend some time to redo the soldering on the board to minimize the weight and reduce any sensitivity to vibration. The board currently outputs a maximum of 3A at 4.8V. The BeagleBoard accepts a supply anywhere from 4.8V to 5.2V so we will be adjusting the resistor feedback path to bump the voltage up a little to 5V to ensure we do not drop below the 4.8V threshold under load.

Today we submitted a number of parts to be ordered so that the power supply can be completed for further testing:

AmainHobbies Thunder Power Pro Lite “G6″ 3S Li-Poly Battery 25C (11.1V/5000mAh)
AmainHobbies Deans Female Ultra Plug
AmainHobbies Bantam E-Station Balancing Adapter Board (Thunder Power)
AmainHobbies ProTek R/C Heavy Duty (14awg) Ultra Plug Charge Lead (Male Plug to 4mm Banana Plugs)

The ADC board uses 5V logic while the BeagleBoard uses 1.8V logic.  The ADC board will be connected to the BeagleBoard via a logic level converter.  We spent some time finding the pinout for the SDA and SDL pins on the board.  The manuals have not been updated for our revision so the header is labeled improperly, but we were able to find the pin position on the board.  Next week we plan to connect the I2C output bus to Nelson’s logic analyzer and run tests to ensure we can communicate properly with the I2C bus.

The afternoon we assembled the quadrocopter platform.  The assembly went smoothly until the end when we discovered we were missing a piece  which mounts the flight controller.  This is annoying, but we have already come up with a few ways to mount the controller without this backing panel.  A timelapse of the build can be watched on Youtube here:

sudo opkg install kernel-module-mt9p031
sudo modprobe -v mt9p031

Additionally the uEnv.txt file on the boot partition needed a line added for the camera.  This tells the kernel that a driver needs to be loaded for the camera.  The line was added at the end of the file, but I believe that the line can be added anywhere.

camera=lbcm5m03

After a quick system reboot the camera is loaded automatically.

We used the mplayer application to pull and display the images from the camera.

mplayer tv:// -tv width=640:height=480:device=/dev/video0:fps=10 -vo x11

Today we were made aware of an alternative model of the XAirCraft X650 platform.  The new XAirCraft X650 Value platform is available in lieu of the original carbon fiber platform which was sold out.  The new platform uses different motors, a modified ESC system and plastic booms.  These features make this platform comparable to the original X650 in terms of utility.  We have given the go ahead to have this model procured.

Thursday I spent the morning working on some interface code for the Logitech Wingman joystick that we will be using for the backup fly-by-wire controls in the project. The code itself is based off a code template provided as part of my Real Time Operating Systems course for communicating joystick information over a serial port.

As a test I decided to simulate mouse movements using the joystick. The X and Y positions correspond to X and Y mouse movements while the Z axis changes the speed at which the mouse pointer moves. The trigger sends a left click to Windows. The code is platform specific. Relevant code is below:

//* Example illustrating Joystick access in Windows *
#include <windows.h>
#include <limits.h>
#include <Winuser.h>
#include <Wtsapi32.h>
// We need winmm.h but it needs some more of windows.h
// Add to the linked libraries list: winmm.lib

// We need to print debug information in this particular example
#include <stdio.h>

int main()
{
POINT pt; // cursor location
static int repeat = 1; // repeat key counter
short keeprunning = 1;
bool button = false;
int speed;
INPUT Input = {0};

while (keeprunning)
{
JOYCAPS jc; // to keep features of the joystick
JOYINFOEX lastJoyState; // to keep joystick state

if (joyGetNumDevs()==0)
{
fprintf(stderr, "Please connect a joystick\n");
Sleep(5000);
continue;
}

if (joyGetDevCaps(JOYSTICKID1, &jc, sizeof(jc))!=JOYERR_NOERROR)
{
fprintf(stderr, "Please connect a compatible joystick\n");
Sleep(1000);
continue;
}

lastJoyState.dwSize=sizeof(lastJoyState);
lastJoyState.dwFlags=JOY_RETURNALL | JOY_RETURNPOVCTS | JOY_RETURNCENTERED | JOY_USEDEADZONE;

{
const unsigned int naxes = jc.wNumAxes;
const unsigned int nbuts = jc.wNumButtons;
const int MID_VALUE =(int)(USHRT_MAX/2);

int cur_b = 0;
int cur_x = 0;
int cur_y = 0;
int cur_z = 0;

int old_b = 0;
int old_x = 0;
int old_y = 0;
int old_z = 0;

while(keeprunning)
{
if (joyGetPosEx(JOYSTICKID1, &lastJoyState) != JOYERR_NOERROR)
{
fprintf(stderr, "Please reconnect the joystick\n");
Sleep(1000);
break; // exit to the outer loop and check for a new joystick connection
}

old_b = cur_b;
old_x = cur_x;
old_y = cur_y;
old_z = cur_z;

cur_b = lastJoyState.dwButtons;
cur_x = (int)(lastJoyState.dwXpos)-MID_VALUE;
cur_y = (int)(lastJoyState.dwYpos)-MID_VALUE;
cur_z = (int)(lastJoyState.dwZpos)-MID_VALUE;

speed = (cur_z + MID_VALUE) / 16;
if(speed == 0) {++speed;}
GetCursorPos(&pt);
pt.x += (cur_x / speed);
if(cur_y > 2000 || cur_y < -3000)
pt.y += (cur_y / speed);
SetCursorPos(pt.x, pt.y);
Sleep(50);
if((cur_b & 0x001) != button) {
button = (cur_b & 0x001);
::ZeroMemory(&Input,sizeof(INPUT));
Input.type = INPUT_MOUSE;
if(button)
Input.mi.dwFlags = 0x02;
else
Input.mi.dwFlags = 0x04;
::SendInput(1,&Input,sizeof(INPUT));
}

if (cur_b==15)
{
fprintf(stdout, "End program button sequence initiated\n");
keeprunning=0;
}
}

Sleep(10); // wait 10ms between checks for the next sample
}
}

return(0);
}

Edit:  Blog is stripping preceding tabs and spaces from the code.  If you need the formatting copy and paste this into Visual Studio, highlight everything and press CTRL + K + F to auto format.

Lab time from the afternoon was spent working on the official project proposal. The rough draft was due in to Dr. Malinowski on Friday.

This morning I spent time to setup the wireless adapter so that we could use opkg to update packages and begin working on wireless communications in following weeks.

The department ordered three 802.11g wireless adapters by Belkin which came in recently.  The adapters have been numbered 1, 2 and 3 to distinguish between them in the event of failure.  This is actually convenient because adapter number 3 uses a slightly different chipset than 1 and 2.  Also each adapter was registered to the Bradley University network by Mr. Mattus.

The method for activating wireless is fairly simple.  First the network adapter (wlan0 or wlan1 in my case) is taken down and the adapter is given an essid to connect to.  Next the adapter is brought back online and the DHCP client is activated.  The iwconfig command is used to determine whether wlan0 or wlan1 is to be used as the two different chipsets are given different numbers.  wlan# is the device to be used.

iwconfig

ifconfig wlan# down
iwconfig wlan# essid BUother
ifconfig wlan# up
dhclient wlan#

Once wireless was working we gave our project proposal presentation which lasted about an hour.  We got some good feedback on things that we need to take into account for our project and hope to have some specifics in a week or so.  After the presentation I worked on automating the process of activating wireless so that a script to perform this action on startup.

The first step was to use iwconfig and grep to find the adapter to be used, and store that in a variable.  The rest of the process is identical except a variable is used in place of the wlan#.  This script is then added to the init process by the update-rc.d command.

#!/bin/sh
val=$(iwconfig | grep -o ^wlan.)
ifconfig $val down
iwconfig $val essid BUother
ifconfig $val up
dhclient $val

update-rc.d wireless.sh defaults 51

The update command parameter of 51 makes the script run after the DHCP and usb drivers are initialized.  defaults places the symbolic links in the default locations.

Last item of importance for the day was to install the TIC6x compiler and toolchain for Austin to work with the DSP core.  Simple install since wireless is working.

opkg install ti-c6accel
opkg install ti-c6accel-apps
opkg install ti-c6accel-dbg
opkg install ti-c6accel-dev