Carputer
From GrinningMonkey
Other pages related to the Carputer
Carputer Progress is where I'm keeping track of what's been done, what's going on, etc.
What is Trux II
Trux II is a computer. A computer that goes in a car. It's named after Trux.
What's this webpage for? The first part is a bit of history and description about what Trux is, and the second part is a collection of ideas about what Trux should do.
History: Trux the Original
Trux was a computer that I built back in 1999/2000 or so.
I made a wooden box big enough for a standard PC mainboard. Then I ripped apart a standard PC and shoved its mainboard, sound and video, hard drive, and power supply into this wooden box. I had some stuff mounted on the walls and lid of the box so it would all fit. I had to take the casing off of the power supply (got better ventilation that way anyways). I used grey outdoor carpeting to cover the box, along with velcro straps to hold it shut and a drawer handle for carrying it.
It had a regular PC power supply in it (minus the casing) so it ran off of 115VAC, which I got by plugging it into a power inverter.
It ran Linux, and it ran in my truck (an '85 GMC High Sierra) so I called it Trux. What else?
I had designed it specially so that it would boot very quickly. I recompiled the kernel, optimizing for speed, customized the boot sequence. All it did was play MP3s so it didn't need much. The BIOS took about 2 or 3 seconds, and from 6 seconds after clicking the power switch Trux was playing random music.
No video, no keyboard. Just turn on and play random music.
Nowadays you can do that with any MP3 player out there, except totally beating the crappy 6 second bootup time.
Trux II: The Hardware
Around August 2005 I competed in DARPA's Grand Challenge. My team didn't win, but I learned things and we had fun so 'twas all good. One of my jobs was to find PCs that we could use in the truck. Later, I talked to the Man in Charge (as opposed to the team leader, which was me d:) and convinced him to sell me one of the PCs and monitors we used.
This was the start of Trux II.
The PC is a 1GHz VIA C3 (Nehmiah) running on a MiniTX form-factor motherboard (the VIA C3 is a very low power x86-compatible chip) with 512MB of RAM and a 20GB laptop HDD. It's enclosed in a black metal box which also has room for a couple of PCI boards and other bits if necessary. It could be smaller, but who knows, the extra space inside may come in handy for housing custom-made circuit boards.
The power supply is designed to be vehicle friendly -- it takes 11-18VDC which is always-on, and a signal line from the ignition. When the ignition signal goes high, the P/S waits about 4 seconds and then starts the PC. Later, when the ignition signal goes low, the P/S sends a signal to the motherboard to shut down. If the PC manages not to shutdown gracefully after a certain amount of time (one minute) then it assumes that the PC is crashed and shuts off power anyways. A little flashing LED will tell you whether it shut down gracefullly or not.
The monitor is a small TFT LCD display (7" diagonal, 16:9 ratio). It's very liberal about power, too (11-24VDC).
The peripherals
Here's what I have so far, but keep an open mind for cool stuff to stick in there in the future!
- A Garmin eMap GPS interfaced via RS232
- An ElmScan5 OBD-II, also RS232
- I have an aftermarket tachometer so it would be easy to tap that signal (with appropriate optoisolation), vastly increasing datarate and accuracy freeing up OBD-II bandwidth for other things
- I may will upgrade the monitor to one that is the same size, but with touchscreen (once the project actually gets off the ground)
- I have two thoughts for data input other than touchscreen:
- Alphagrip (a USB kbd/mouse which is held in your hand like a game controller)
- Gyrations kbd/mouse (a compact wireless keyboard with a mouse that you can wave in the air)
- All functions needing more than simple touchscreen taps must be passenger-only or only for use when stopped
- I may add a DAQ card if I need analog input; I'm open to tapping some of the car's sensors (I really want the fuel status...)
My car is a 2002 Toyota Corolla. Here's what's available on its OBD-II:
1 - 0x01 Number of trouble codes and I/M info Bit encoded. See below. 0 - 0x02 1 - 0x03 Fuel system status Bit encoded. See below. 1 - 0x04 Calculated engine load value 0 100 % A*100/255 1 - 0x05 Engine coolant temperature -40 215 °Celsius A-40 1 - 0x06 Short term fuel % trim—Bank 1 -100 (lean) 99.22 (rich) % 0.7812 * (A-128) 1 - 0x07 Long term fuel % trim—Bank 1 -100 (lean) 99.22 (rich) % 0.7812 * (A-128) 0 - 0x08 0 - 0x09 0 - 0x0a 0 - 0x0b 1 - 0x0c Engine RPM 0 16,383.75 rpm ((A*256)+B)/4 1 - 0x0d Vehicle speed 0 255 kph A 1 - 0x0e Timing advance -64 63.5 ° relative to #1 cylinder A/2 - 64 1 - 0x0f Intake air temperature -40 215 °C A-40 1 - 0x10 MAF air flow rate 0 655.35 g/s ((256*A)+B) / 100 1 - 0x11 Throttle position 0 100 % A*100/255 0 - 0x12 1 - 0x13 Oxygen sensors present [A0..A3] == Bank 1, Sensors 1-4. [A4..A7] == Bank 2... 1 - 0x14 Bank 1, Sensor 1 (pre-catalytic): Oxygen sensor voltage, Short term fuel trim (0-1.275V, 0-99.2%) A * 0.005, (B-128) * 0.7812 (if B==0xFF, sensor is not used in trim calc) 1 - 0x15 Bank 1, Sensor 2 (post-catalytic): Oxygen sensor voltage, Short term fuel trim (0-1.275V, 0-99.2%) A * 0.005, (B-128) * 0.7812 (if B==0xFF, sensor is not used in trim calc) 0 - 0x16 0 - 0x17 0 - 0x18 0 - 0x19 0 - 0x1a 0 - 0x1b 1 - 0x1c OBD standards this vehicle conforms to Bit encoded. See below.
Trux: The plans
This is the fun part. This is where we let our imaginations run wild. I envision this thing as a selection of modules. I'm not sure what the module structure is right now. First we'll think of what we want to do, then we'll design a module structure that allows us to do it.
The idea behind the module structure is that there will be a GUI framework -- a cross between a menuing system and a mini-OS -- that lets you manage your modules, turn them on and off, select active ones (who knows what that means yet), etc.
Preliminary infrastructure thoughts
Here's what I'm thinking so far, although once again, the best plan is to see what we want to do first, and then figure out how that's done:
- GUI with Qt (high-level, easy to kick out code)
- Perl/Qt for most stuff (high-level, easy to kick out code -- is there a pattern here?)
- UDP and/or IPC and/or shared memory for things to talk to other things
- C for the lower-level stuff like monitoring sensors
So we start with a collection of ideas, and then we build a management structure that accomodates them and figure out the best way to write the code.
A couple of the ideas below have (LL??) beside them. There will probably be a limited collection of low-level drivers and code, and these modules should be considered for integration.
Infrastructure
The high-level modules
FUN FUN FUN! Gnurple Forum readers have given some great ideas, too. Found at: http://forums.gnurple.net/forum/cgi-bin/yabb/YaBB.cgi?board=press;action=display;num=1142397985
Vehicle status
A GUI will show key stats, such as speed, temperatures, RPM, GPS location, distance to destination, etc. Probably use a dashboard view with little gauge widgets (QWTPlot)?
Efficienator
This module will monitor engine RPM and speed.
It will calculate acceleration and display it. I'm thinking of a slider with the middle being zero and it slides up and down to show acceleration.
When the vehicle is maintaining a speed (e.g. highway driving) then it will check the RPM and compare to speed to determine if the driver should shift to a higher gear for better efficiency. Additionally, the slider should be sensitive enough to tell the driver when he's drifting. It should not require the user to enter a "set speed", instead relying on rolling averages.
(older stuff follows)
Code will check to see if car has not been maintaining a steady speed for the last n seconds. If it has, then it will analyse the current speed and engine RPM to recommend that the driver shift to the highest possible gear for efficiency.
This is because I have a terrible habit of speeding up to pass or whatever and then forgetting to shift back to a higher gear afterwards, usually 'cause the music is cranked so loud I can't hear or feel the engine d:)
Logginator
Wireless-Home Sync (WHS)
This manager module will use the Wifi device to detect when the vehicle is able to connect to my home's wireless infrastructure. Once it detects this it should ask some questions like "will I be staying within range and remain turned on for long enough to complete a synchronization" and then it should synchronize.
See other modules for examples of things that might be synchronized, like the next two.
MP3 synchronizer
This module works in conjunction with WHS (above) to update the on-board MP3 collection.
Shopping list synchronizer
This module works with WHS to update shopping lists. Cool features:
- Use GPS to detect when you're near a store, and say something like, "You are 500m from Canadian Tire. You have 3 items to purchase there"
- If vehicle stops near a store, and there are items on the list to be purchased at same, ask user if they want to print the list (would require a printer, of course... I'm thinking of one of those small printers that roadwarriors carry around with their laptops... mount in glove box or trunk)
Car Email Dispatcher (CED)
This manager module works with WHS and with the home base network to cause emails to be sent to the owner about the car, such as "Low on gas, please plan to fill up soon" or "Next oil change due soon"
Other modules will be able to place email events in this module's queue for dispatch.
Fuel status watcher
This module works with CED. It watches the fuel status and queues an email to go out to the owner if the car is low on gas. It should only check this if the car has just pulled into home-base range (why queue an email that we can't send -- the driver might refill before getting home anyways).
Car maintenance scheduler
This module works with CED. It keeps track of the last time certain maintenance events like oil checks, oil changes, filter changes, fluid checks, etc. have been done. Should include anything the owner/maintenance manuals say to check. My car's OBDII is too stupid to give odometer via an OBDII reading, so we should come up with another way of guesstimating the odometer.
Odometer guesstimator (LL?)
My car's OBD-II is too stupid to give the odometer reading, so we'll come up with some ways to guesstimate odometer. We can allow the user to initialize the odometer, and we can (whenever we're turned on) use the speed and a timing loop to periodically update what we thing the odometer is. We can ask the user to provide updates once in awhile. Maybe ask for updates when car detects that it's at home base.
Engine Warm-Up Monitor
We can watch the IAT and the fuel system status (open loop due to temperature) to see if the engine's warm enough to drive yet. Put a popup on the screen that shows the current IAT and FSS until it's ready, at which point, chime and say it's ready, then close window shortly thereafter.
Gas Pedal Gauge
Draws the state of the gas pedal. Just for fun because we can.
Vehicle Data Collector and Logger (LL??)
This management module will be designed to collect data from OBD-II and other sources as quickly as possible. It'll keep the information available for any other process to read, probably via UDP over local sockets.
It should include a way for other modules to tell it which data bits they need. For example, if the Gas Pedal Module isn't turned on (or more accurately, nobody needs to monitor throttle position sensor), why waste OBDII cycles on it?
This code should be responsible for keeping track of how quickly we're pulling OBDII data and adjusting the timer (OBDII is evil because the protocol says "ask OBDII a question and wait nnn milliseconds for an answer; even if you get an answer, wait the full time before asking another question, just in case". With the ElmScan device you can adjust nnn so this code should enter some kind of closed loop where it tries to maintain a balance between lowest nnn possible and lowest number of errors possible.
This code probably needs to be written in C since it involves tight timing loops (including other, non-OBDII stuff like tachometer). Or maybe only the part responsible for collecting data and updating shared memory / IPC / UDP. A more high-level manager can command the C code on which stats to collect.
Start-up Monitor
When the computer starts up, probably the first thing it should do once it gets into X is do a little panel and status bar showing which things are up and running, etc.
Drive-O-Volumator (not volumeter!)
You know how it is. When you're driving on the highway, you get a lot more noise from wind and wheels on pavement and stuff. What was an acceptable volume while driving around on those 50km/h neighbourhood streets around your home just doesn't work when you're cruising at 110km/h on the highway. Conversely, when you've been driving on the highway and you take an exit, or you come to traffic and slow to a crawl, suddenly your volume is too loud. Sometimes we don't notice and correct.
This module will have an algorithm that adjusts the current volume depending on the speed. Trial and error will determine what's a decent scaling factor, and from there the user can choose what they want.
The module should work such that the user can adjust their volume at any time, independently of the scaling factor.
Something with Blue LEDs
I don't know what, but there should be at least a few blue LEDs on the car, interior or exterior, whatever, and Trux II should do something cool with them. Make them flash to the beat of the music. I dunno.
Route Study stuff
Detect when you're driving routes you've driven before (like work->home or vice versa, whatever) and keep track of statistics for the trip, like now long it took, km driven, etc. Based on the stuff I did for Route Study.
Low-level things
Logging
The low level code will probably be responsible for collecting all data, e.g. from OBDII, tach. signal, fuel status (if I can tap it), and others. It will probably also derive some data, such as an algorithm for guessing odometer.
Some modules may need this data in real-time. Some may need a 30-second history to calculate some averages, etc. Some may need an entire trip's worth of data.
I'm thinking of the following:
- Store n seconds of the latest data in memory.
- Some process can dump the data to a database every once in awhile.
- On shutdown, ensure the database is sync'd.
In addition to data, many modules may well have status messages of different levels. There should be some set of message types (INFO, WARN, SYSTEM, MULTIMEDIA, whatever). All modules can log messages. There should be a module that can display them. It could be configured as to what types of messages from which modules should be displayed. In addition, all log messages should be saved to disk somewhere (database?).
The module management system
- UDP inter-process communication?
dave0's idea:
- Use something like dbus instead of roll-your-own UDP
Temporary list
- How will MP3 playing be done?
- How do we do GPS mapping?
dave0 from Gnurple Forums gave this list of ideas:
- log OBDII data on a per-street basis so you can calculate which routes to/from work are hardest on your car
- let it automatically detect and share info with other carputers (gps data, location, swap music files, etc) if one comes within wireless range
- auto-detect wireless accesspoints when stopped, and then VPN over any open wireless to "home base" for data updates
- when wireless available, cache latest news/weather/traffic info for later playback on demand
- Wireless AP for back-seat passengers using laptops
- add a cellphone for upstream data connection when no external wireless available
- mount paddles on your steering wheel (ie: like racing shifters) as an input device
- add sensors under each seat to detect how many passengers you have (maybe OBDII provides this info for front-seat passengers if you have airbags). Then you can automatically calculate the difference in gas mileage when you have more weight in the car
- temperature sensors for inside/outside the car
- have the car remind you when the weather is cold enough (or when it's forecast to be cold enough) to require being plugged in
- sync your TODO list to the car, so it can remind you of things when you drive by various locations (ie: "You're approaching Canadian Tire. I need oil, and you need a pair of pliers and a lawnmower blade")
- sync sale info from store websites, and have it remind you of those on the route
- Log locations of bad potholes, and have the GPS remind you so you can be in the less-potholed lane
- ceiling-mounted camera that can rotate 360d so you can take photos or video out the windows, or internally to use the car as a photo booth
- printer in the glove compartment.
- large programmable sign in the back window for insulting tailgaters
- record gps coords of each song played, and use it to generate location-based playlists.
ideas from the office:
- add an FM transmitter broadcasting on some unused local frequency. Add a bumper sticker "Listen to my music at 88.1 FM". Some of the off-the-shelf transmitters intended for portable MP3 players are good to 1-2 carlengths, but to avoid tailgaters you might want to boost the signal strength too.
The NBT: CarPC plus NITS
Imagine this: under the passenger seat (or in the dashboard somewhere) is the CarPC. It's wired to 12V power, to the OBDII interface for data, and perhaps with a Data AQuisition card for car data not available on the OBDII.
On the dashboard are mounted some number of Nokia Internet Tablets. Let's say there are three. One shows GPS data. One shows car information (gauges, LCD-type numbers, etc.). The third has music controls.
As you're driving along, a fellow in the back asks about changing the song. The driver grabs the music control tablet, slides it out of its mount and hands it back. "Here, you control the music."
Concepts
- The NITs connect to the CarPC using remote X11 (or VNC) via Bluetooth or WiFi
- There is a "launch" screen which displays a list of modules
- Each module is formatted to display its data nicely on the NIT 800x480 screens (note: car displays like the Xenarc are also 800x480...)
- For mounting NITs, there's a little gimbal-type tripod mount that would be perfect for this. Similar to the mount for the Xenarc screens.
Modules
Example modules:
- GPS (display your position, route, heading, speed, etc. etc.)
- Car data (gauges for stuff you want to display from OBDII and/or DAQ)
- Audio controls (play/pause/jump/seek/etc, what's playing, what's next, queue next, edit playlist, etc.)
- Reminders and list management
- Movie player (CarPC has media repository of videos formatted for NITs. would use Maemo mPlayer for playback...)
See above TruxII ideas which incorporate well into this scheme
