Thread: Return of the onboard wooly computer

The data I am hoping to acquire:
GPS Position and Time (used to map to the track and possibly return lap times)
Inertial Measurement (used to get more accurate position)
Front Suspension Position (used to determine suspension loading at various track location for adjustment)
Rear Suspension Position (used to determine suspension loading at various track location for adjustment)
Front tire speed (various uses but one is determine wheel slip by comparing front to rear)
Rear tire speed
Front tire temperature (determine if tires are getting to proper operating temps and how soon into a session)
Rear tire temperature
Engine RPM (obviously )
Throttle Position (used to determine throttle control and how soon and where power is being fed in)
Speed (obviously )
Lap time (OK I got a laptime but this is a freebie in performed in s/w)

I searched for a base system and the best I have found to date is the
Technologic Systems TS7200 running Linux (Debian or TS Linux). I got mine with:
200MHz ARM9 Processor
32MB RAM
16MB Flash
OP-ADC 12 Bit A/D Converter
TS5260 Battery Backed Realtime Clock
OP-16BIT-104 16 Bit Bus (SHOULD HAVE GOT THE PASS THRU OPTION)
OP-EJECT Compact Flash Ejector

This system is open source and real low power. I could likely run it on batteries but plan on running 12V from the bike.

I also got a LCD from them and recommend the wireless USB dongle (not available when I got mine)

Features that make this a great choice are the 8 channels of A/D conversion (though I may need to use a MUX to get more), 10 DIO pins, 2 serial ports, 2 USB ports. In other words lots of I/O capability in a small low power package.

The GPS unit will serve two purposes.

Provide location and time
Provide a correction for an IMU

To provide correction to an IMU the GPS should have a high degree of accuracy. A unit that has WAAS and DGPS is desirable for the accuracy they provide.

To provide location the GPS needs a data rate high enough to reflect the position of the bike traveling at speed. At 140MPH a one hertz rate would have a distance between points of 205.32 feet. While at 50MPH the distance between points is 73.33 feet. Most units manufactured by Garmin have a one hertz update rate. This would seem more of a problem than it is though as turns will be slower and naturally bunch the points. However there is a Garmin OEM board GPS18 5Hz that runs at (suprise) 5 hertz. In addition this device connects via serial port. It will result in distances of 41 and 14 feet which should be much more useful. This has been a good piece so far though the true test will be when I hit the track the first time.

To continue...

Will it show you how many seconds this distraction costs you as Frenchie laps your datalogged ass?

Originally Posted by CBRVFR

Will it show you how many seconds this distraction costs you as Frenchie laps your datalogged ass?

Is breathing a distraction? Got to be what you are

True, true..

Inertial measurement will be performed by accelerometers and gyros. This can give me 6dof measurements. With these measurements I can calculate position even more accurately than with GPS.

The difference is that GPS has a certain amount of error that varies within a maximum. Using WAAS this can get <3meters. In contrast inertial calculations can be much more accurate however they have an inherent drift thus getting further and further off.

While I have not worked out the exact mechanism I plan on using the IMU and correcting it using GPS data.

The units I have now are from Sparkfun.
1) a 3 axis accelerometer that uses a 3.3V supply
2) a 2 axis gyro (to get all three I need a second device) that has a 500º/sec capability also using a 3.3V supply

I can read these devices using 5 of my 8 channels of A/D conversion on the TS7200. Sparkfun has some integrated IMUs but the price is considerably higher.

The main question on the implementation is what sample rate will be needed for adequate data to integrate.

My current plan on measuring front suspension is to use a IR distance sensor and a target of some form on the axle with the sensor on the triples. A candidate is this. With a range of 4-30cm (1.5"-11") it should work if not there is other versions with a bit more distance. This will use another A/D pin. A fairly high sample rate will likely be desired. A similar setup may be used on the rear however the exhaust may interfere with the IR.

For wheel speed I have not totally worked out the details however I am thinking of using a hall effect sensor on the front with a frequency to voltage converter to count revolutions. For the rear I can do that or use the Honda speed sensor (and run it in to the same convertor) I have something from this family to play with and test. This would then be sent to the A/D convertor on the main board (notice I am running out of A/D connections and may need to use 3 DIO pins and a MUX to get 8 more)

Tire temperature is a bit of a puzzle but recently I found a nice candidate device. This is available with the replacement not yet listed on Digikey. These are small and have a good temperature range however any remote IR sensor has one flaw. One gob of hot rubber on the lense and it fails. So I am thinking of covering it with a plastic tear off type thing. The issue that will have to be resolved there is safety (ensure the tearoff only tears off by me not on track) and many clear plastic/glass materials available attenuate or block IR. This is still a solution that I am exploring at this time.

I have not thought much on throttle position and speed yet.

Lap time has many solutions. I could try to capture a beacon like traditional lap timers (something I am leaning away from) or do it in s/w. One way to do it in s/w is by tagging a spot in GPS then doing a proximity check until that spot is achieved.

My basic idea is to record a spot when speed gets above a minimum. Then compare to it. When a set distance is achieved record the spot and the next spot. Continue that for as long as the distance is decreasing. On an increase in distance you have passed the point of closest approach and do a simple linear interpolation between the two points to get the time. There is a bit more to consider but that is the basic idea.

It should be reasonably accurate compared to traditional timers, computational simple (I do not want to load the board most hard number crunching will be on the laptop after the session), and unlike traditional timers it cannot miss the beacon.

Don't forget the flux capacitor.

A beacon will be more accurate than a GPS location.

Originally Posted by bda116

A beacon will be more accurate than a GPS location.

A beacon has beam width that varies by track location and can be interfered with. The GPS will have more error without the interpolation between the events but when you interpolate it should drop. Also the GPS will have position error but what really matters is the difference in error position between laps. I believe this will be at or below that achieved with a beacon (though you may be correct). When I get it recording data I will take it in and crunch numbers and compare the two though.

Originally Posted by SheepOfBlue

For wheel speed I have not totally worked out the details however I am thinking of using a hall effect sensor on the front with a frequency to voltage converter to count revolutions. For the rear I can do that or use the Honda speed sensor (and run it in to the same convertor) I have something from this family to play with and test. This would then be sent to the A/D convertor on the main board (notice I am running out of A/D connections and may need to use 3 DIO pins and a MUX to get 8 more)

Sheep, the Hall effect sensors already give you a digital signal, you just need to count the edges and convert that to a speed number.

I believe you are thinking of a Variable Reluctance Sensor (VRS) that is used in place of Hall sensors in some applications. These put out a frequency signal that needs to be converted. Both Hall and VRS are in common use in the auto industry ... with benefits of each. VRS is better when you have very high pulse rates to get better accuracy (like 30+ teeth on a crankshaft spinning at over 7000 rpm). Hall will work fine for lower resolution, and you just have to count edges ... but be sure to check if your system counts both up and down or only one of the edges. You don't want to be off by a factor of 2

Sounds like a very cool project; I'm still interested in your outcome.

EDIT: This is working code. Demonstrating the functionality without flaws
Here is some code that is meant to be a proof of concept for most functionality that is needed to connect the GPS. The standard baud rate for the GPS 18 5Hz is 19200 while standard for NMEA is 4800.

/* Demo code to connect to a GPS. Most units should connect at 4800 Baud while
the Garmin GPS18 5 Hz defaults to 19200.
The program will take three arguments. Device name, 1 = 4800; 2 = 19200, logfile
Example:
./a.out /dev/ttyAM1 1 logfile.txt

The general sequence is New, Open, Configure, Read, Close

Functions:
close_port
open_port
read_port
port_configuration
print_configuration
main
*/

#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <string.h>
#include <unistd.h>
#include <sys/select.h>

/* Used to close the port
file_id file_descriptor returned form open
*/
int close_port(int file_id)
{
return close(file_id);
}

/* Used to open the port, returns file descriptor or -1 on fail
device_name serial device name
*/
int open_port(char* device_name)
{
int file_id;

file_id = open(device_name, O_RDONLY | O_NOCTTY | O_NDELAY);
if(file_id == -1)
{
printf("Failed to open device\n");
return -1;
}
else
{
printf("Open succeeded with result %d\n", file_id);
}
return file_id;
}

/* Read 50 sentences from file_id, print them to the console and log them into a file
file_id file desciptor from open
filename file name to open for logging
*/
int read_port(int file_id, char* filename)
{
char buffer[512];
int total = 0;
int lines = 0;
int result = 0;
fd_set rfds;
struct timeval tv;
FILE* logfile;

logfile = fopen(filename, "a");

FD_ZERO(&rfds);
FD_SET(file_id, &rfds);

while(lines < 50)
{
tv.tv_sec = 1;
tv.tv_usec = 0;
/* Pause on select until data arrives or 1 second */
result = select(file_id + 1, &rfds, NULL, NULL, &tv);

if (result == -1)
{
printf("Error during select\n");
continue;
}
if(!result)
{
printf("No data within a second. Result = %d\n", result);
}
if(FD_ISSET(file_id, &rfds) == 0)
{
printf("Data received for a socket other than the GPS\n");
continue;
}
/* Read the data */
result = 0;
result = read(file_id, buffer, 511);
printf("result = %d\n", result);
fwrite(buffer, result, 1, logfile);
total += result;
lines++;
/* Add terminator and print if non-zero */
if(result > 0)
{
buffer[result] = '\0';
printf("%s\n", buffer);
}
}
printf("%d total characters recieved\n", total);
fclose(logfile);
}

/* Configure the port, printing the configuration before and after the changes
file_id file desciptor from open
speed 1 for 4800; 2 for 19200
*/
void port_configuration(int file_id, int speed)
{
struct termios options;
int err;
char err_str[16]= "tcgetattr error";

err = tcgetattr (file_id, &options);
if(err)
{
printf("Error of %d calling tcgetattr\n", err);
perror(err_str);
}
printf("Before configuration reset\n");
printf("speed in %u out %u\n", cfgetispeed(&options), cfgetispeed(&options));
printf("mode in %u out %u\n", options.c_iflag, options.c_oflag);
printf("control flag %u\n", options.c_cflag);
printf("local flag %u\n", options.c_lflag);
if(speed == 1)
{
cfsetispeed (&options, B4800);
cfsetospeed (&options, B4800);
}
else if(speed == 2)
{
cfsetispeed (&options, B19200);
cfsetospeed (&options, B19200);
}
tcsetattr (file_id, TCSANOW, &options);
if(err)
{
printf("Error of %d calling tcsetattr\n", err);
perror(err_str);
}
tcgetattr (file_id, &options);
if(err)
{
printf("Error of %d calling tcgetattr\n", err);
perror(err_str);
}
printf("After configuration reset\n");
printf("speed in %u out %u\n", cfgetispeed(&options), cfgetispeed(&options));
printf("mode in %u out %u\n", options.c_iflag, options.c_oflag);
printf("control flag %u\n", options.c_cflag);
printf("local flag %u\n", options.c_lflag);
}

/* Print the port configuration without making changes
file_id file desciptor from open
*/
void print_configuration(int file_id)
{
struct termios options;
int err;
char err_str[16]= "tcgetattr error";

err = tcgetattr (file_id, &options);
if(err)
{
printf("Error of %d calling tcgetattr\n", err);
perror(err_str);
}
printf("speed in %u out %u\n", cfgetispeed(&options), cfgetispeed(&options));
printf("mode in %u out %u\n", options.c_iflag, options.c_oflag);
printf("control flag %u\n", options.c_cflag);
printf("local flag %u\n", options.c_lflag);
}

int main(int argc, char **argv)
{
int file_id = 0;
int running = 1;
int the_char;
char device_name[256];
int speed;
char** endptr;
int x;

if(argc < 4)
{
printf("serial_tester <device> <speed> <logfile>\n");
return 0;
}
else
{
for(x = 0; x < argc; x++)
{
printf("arg[%d] = %s\n", x, argv[x]);
}
}
strcpy(device_name, argv[1]);
/* Print menu */
while(running)
{
if(the_char != 10)
{
printf("Q = quit; O = Open; R = Read; C = Configure; N = New device; P = Print configuration; W = Close\n");
}
the_char = getc(stdin);
if(the_char == 10) continue;

switch(the_char)
{
case 'q':
case 'Q':
{
running = 0;
printf("Quitting\n");
break;
}
case 'r':
case 'R':
{
read_port(file_id, argv[3]);
break;
}
case 'o':
case 'O':
{
file_id = open_port(device_name);
break;
}
case 'n':
case 'N':
{
file_id = 0;
break;
}
case 'p':
case 'P':
{
print_configuration(file_id);
break;
}
case 'c':
case 'C':
{
if(file_id > 0)
{
switch((argv[2])[0])
{
case '1':
{
speed = 1;
break;
}
case '2':
{
speed = 2;
break;
}
default:
{
printf("Invalid speed selection defaulting to 4800 Baud\n");
speed = 1;
break;
}
}
port_configuration(file_id, speed);
}
else
{
printf("New device must be configured first\n");
}
break;
}
case 'w':
case 'W':
{
printf("Closing\n");
close_port(file_id);
break;
}
default:
{
printf("Invalid choice of %d\n", the_char);
break;
}
}
}
printf("Exiting\n");
}

For those that don't know NMEA is a standard ASCII output of GPS data. The first part of the sentence is a tag of the form $GPGLL where the tag determines the type of information provided. For my uses not all sentences will be saved (exact ones to be determined still) The manual for the GPS 18 5Hz defines the tags output (and much more). The plan is to save the desired data for post processing on a laptop or desktop machine (more CPU and space) the exception being the laptime info.

Small progress to report. I made a base and moved the power board off the PC104 bus onto its own posts. While not as tidy looking the TS12W power board I have supplies 5V at two sets of pins and should accept the DC from the bike. When in the PC104 bus it powers the stack (and thus the main board) however that is all. By moving it off I can use the second set of pins to supply power for the GPS saving me from adding a power board of my own for now. Also I have a realtime battery backed clock that I can now use to go on the board (PC104 bus). That was my original intent but neither the clock board nor the power board are pas through connectors making stacking impossible.

I made a small cable to go from the 8 pin (I only used one side though) connector on the power board to the TS7200 board power inputs (that needs 5V regulated power)

Picture one is the board on the new base with ethernet, gps serial and console serial connected.
Picture two is a my cheesy cable work
Picture three is another board view where you can see the TS5260 realtime clock

Sheep.... can I borrow the Onboard Woolie Computer? I'm trying to prop a door open at work and need something heavy.

Originally Posted by Tuffy6969

Sheep.... can I borrow the Onboard Woolie Computer? I'm trying to prop a door open at work and need something heavy.

Wouldn't work. It will add a small amount of weight but it really pretty small and light If I go with thinner plexiglass and lexan mix for the case it will get lighter still.

EDIT:
Besides like the video it will get done one day. Well OK in this case never done, but operational. There will always be features I can add to it or the desktop/laptop side.

post 22 isn't working. I still don't know where I am or which direction to go. so much for a gps.

I HATE MAKING CABLES!

Anyone with tips on how to do Waldom connectors

Gently.