Electronic – arduino – Get current gear from rpm and speed through OBD2

You can definitely transmit data using just TX & GND.

Firstly, you want to hook up the ATtiny85 TX line to the FTDI RX line (yellow on the TTL-232R). Make sure that the USB adapter can handle 5V - I'm fairly sure even the 3.3V TTL-232R is 5V tolerant.

According to the example page for SoftwareSerial, you need to set the direction of the TX & RX lines in your setup function:

// include the SoftwareSerial library so you can use its functions:
#include <SoftwareSerial.h>

#define rxPin 2
#define txPin 3
#define ledPin 13

// set up a new serial port
SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin);
byte pinState = 0;

void setup()  {
  // define pin modes for tx, rx, led pins:
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
  pinMode(ledPin, OUTPUT);
  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
}

The baudrate will be 4800 in your case. The SoftwareSerial library doesn't seem to support CTS & RTS, so just make sure you aren't using them on the host software.

Check out the reference page for more details, where they talk about some potential timing issues which may be exacerbated if you're running at 1MHz using the internal oscillator on the tiny.

"Even after removing gravity I suspect from simply integrating acceleration I could end up with crazy speeds."

Yes, the biggest error in accelerometers is the "zero-g bias". The typical accelerometer bias will rapidly accumulate in a simple integrator to crazy speeds. However, there are ways of automatically compensating for this bias. The simplest method is to stop frequently, and zero things out during the stop. More sophisticated accelerometer autocalibration techniques can compensate for this bias even while we are moving, and even if there are slow (possibly temperature-related) changes in that bias. Some of those techniques take advantage of the fact that, the average acceleration over "long" time periods must be approximately zero (otherwise we would soon reach Mach 100), and indoors the average velocity must be approximately zero (otherwise we would soon exit the building).

"Accurate absolute ground-speed, not relative to device"

The swarm of quadcopters at the UPenn GRASP Lab is pretty amazing.

Most people don't notice that the position and speed sensors are not attached to the quadcopters themselves, but firmly bolted to the walls of the room the quadcopters are in. Unreliable sources tell me they get millimeter accuracy with a $30,000 motion capture system.

I'm pretty sure gyros and accelerometers are mounted on the quadcopters, and the GRASP people use a Kalman filter to convert the raw data (rotation, acceleration, and motion-capture approximate position) into position and velocity information.

I hear a lot of people use a string potentiometer a b c d or ultrasonic pingers to measure distance. There's a way of using 3 (or more) of them to find absolute x,y,z, position. I hear each string potentiometer is "only" $200.

"Detecting zero movement"

Many systems (including low-cost "laser mice") detect movement using "optical flow". If you're lucky, perhaps a hacked mouse or two a b c d e f will give you adequate data?