SheepOfBlue

So I am updating and transferring to here so some of this is a repeat for veteran members.

The purpose of the onboard wooly computer is to amuse me and gather data while on the track.

This project arose when I started looking at lap timers and found that not only were they not Mac friendly the companies that made them told me to pound sand when I asked for an API to make my own s/w. This was then compounded by the desire to gather data which all systems I found appeared closed or semi-closed in nature (and again anti-Mac).

Ideally I would like to ride up flip up the laptop and download the data using wireless. Then run various reports to indicate things like lean angle, throttle position, speed, etc. at various places. I have considered various languages but will likely use either Python or Objective C on the Mac (Python would have the advantage of being portable). Both can be interfaced with OpenGL for 3D graphics, 2D graphics can be in Quartz with both able to be saved a PDF files. Another possible plotting solution would be to use gnuplot for generation.

On the board I am probably going to use Debian on a 512MB card as that way I can bring an entire spare in case of failure etc.

The on bike portion will consist of a remote GPS, computer box with some sensors in it, remote sensors and a console up near the instruments. The console will have a power switch, shutdown button, power LED, Shift LED and character LCD. The LCD could be used to display status and laptimes.

One thing that I have not worked out yet is how to determine when to start logging and gathering and stop it. I want this to occur automatically anytime the unit is powered on.

For those that want to emulate this let me warn you, I bit off WAY to much . However the project has been fun so far and will continue to advance, slowly.

So...

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue

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)

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue

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.

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue

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.

Attached Thumbnails

   

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue

To continue...

__________________
A man who carries a cat by the tail learns something he can learn in no other way

CBRVFR

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

__________________
"...the TV also never took away the screwdriver and shoved it up the repairman's ass."

Our own Mr.2nd Amendment, explaining the difference. Perfectly.

Rich Herald, the Gentle Giant

SheepOfBlue

Is breathing a distraction? Got to be what you are

__________________
A man who carries a cat by the tail learns something he can learn in no other way

CBRVFR

True, true..

__________________
"...the TV also never took away the screwdriver and shoved it up the repairman's ass."

Our own Mr.2nd Amendment, explaining the difference. Perfectly.

Rich Herald, the Gentle Giant

SheepOfBlue

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.

__________________
A man who carries a cat by the tail learns something he can learn in no other way

Hammer

Attached Thumbnails

 

__________________
SOME PEOPLE ARE LIKE SLINKIES. NOT REALLY GOOD FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS

SheepOfBlue

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.

__________________
A man who carries a cat by the tail learns something he can learn in no other way

gthotchkiss

Very interesting project!

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)

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue

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.

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue

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

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue

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.

__________________
A man who carries a cat by the tail learns something he can learn in no other way

phobe

Don't forget the flux capacitor.

__________________
Cum hoc, ergo propter hoc

bda116

A beacon will be more accurate than a GPS location.

__________________
"Islam isn't in America to be equal to any other faith, but to become dominant. The Koran should be the highest authority in America, and Islam the only accepted religion on Earth." - Omar M. Ahmad, founding chairman of CAIR.

SheepOfBlue

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.

__________________
A man who carries a cat by the tail learns something he can learn in no other way

gt702

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.

__________________
Reality is merely an illusion, albeit a very persistent one.
Albert Einstein

SheepOfBlue

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");
}

__________________
A man who carries a cat by the tail learns something he can learn in no other way

SheepOfBlue