My Raspberry Pi Project - OBD2 Data Recorder
Discussion
Hi Rover. Thanks for your thoughts on the rpm to speed ratio used to determine gear. This is what I was originally planning to do, but my plan has changed.
I was on circuit last year with Dad driving, and he mis-shifted from top of 4th into 3rd, rather than into 5th. Fortunately not much damage resulted as he got the clutch back in quickly, but we did need a new gearbox! So the plan with this is that I can have 4 micro-switches, monitoring side to side and for-aft movement of the gear lever. That will be translated using logic into a gear, 1 to 6. I'll then pickup the road speed (from OBD2 probably) and compare that to the known max speed per gear. I can then have a warning event (bulb/buzzer) in the event of a mis-shift, which will alert the problem BEFORE the clutch is lifted.
I was on circuit last year with Dad driving, and he mis-shifted from top of 4th into 3rd, rather than into 5th. Fortunately not much damage resulted as he got the clutch back in quickly, but we did need a new gearbox! So the plan with this is that I can have 4 micro-switches, monitoring side to side and for-aft movement of the gear lever. That will be translated using logic into a gear, 1 to 6. I'll then pickup the road speed (from OBD2 probably) and compare that to the known max speed per gear. I can then have a warning event (bulb/buzzer) in the event of a mis-shift, which will alert the problem BEFORE the clutch is lifted.
Yeah, well I'm hoping to learn a bit about Linux, and Python and a bit more about electronics. Plus hopefully I'll have something useful at the end of it.
Ohhhh, no I hadn't... but that's a bloody good idea! I'd like to think that once I've got the basic environment setup (see diagram above/prev page) it should be fairly easy to add extra sensors. Since all I'd need would be the sensor itself, and a program to enable it to publish to one of these global variables (which I'm still only hoping exist!) and then it could be picked up and displayed like any of the others using the same graphics program.
Nice one, I'll add the accelerometer to the spec sheets! haha!
Ohhhh, no I hadn't... but that's a bloody good idea! I'd like to think that once I've got the basic environment setup (see diagram above/prev page) it should be fairly easy to add extra sensors. Since all I'd need would be the sensor itself, and a program to enable it to publish to one of these global variables (which I'm still only hoping exist!) and then it could be picked up and displayed like any of the others using the same graphics program.
Nice one, I'll add the accelerometer to the spec sheets! haha!
julian64 said:
Probably going to cause a stir here but I would say stop with python, and switch to c on the pi.
Reason being that although python is native to the pi linux system, c is gaining a lot of ground with the pi because it is orders of magnitude faster.
I find that phython is quicker to code especially for a VBA user, but once you get c it won't take you long.
Look on the pi site and you'll see someone has done a comparison, with sampling to show just how much faster c is than python in terms of operating the gpio ports.
If you are some time in the future going to try inserting the digits on the video c will have much less limitation than python.
I'd say stick with Python, and if necessary write a C callout module if you can't get the sample rate high enough using pure Python. Also look at using NumPy rather than native Python for any processing of the data - in fact, make getting your head around NumPy a priority.Reason being that although python is native to the pi linux system, c is gaining a lot of ground with the pi because it is orders of magnitude faster.
I find that phython is quicker to code especially for a VBA user, but once you get c it won't take you long.
Look on the pi site and you'll see someone has done a comparison, with sampling to show just how much faster c is than python in terms of operating the gpio ports.
If you are some time in the future going to try inserting the digits on the video c will have much less limitation than python.
I've been looking at capturing data from I2C inertial sensors via Python rather than native C on the Pi, vs. the current Arduino-based setup I've been using, and given the 400KHz I2C clock rate I think Python on the Pi wins over C on the Arduino. C on Pi is obviously faster, but the I2C clock rate is the limit. If you want to go SPI, then equally obviously you may want to get closer to the metal.
Have also put together a simple framework for doing networked I2C development - PyDev plus Eclipse on the PC, accessing SMBus on the Pi via RPyC - using all of the Eclipse goodness to develop the code and test, and then sync to the Pi using Unfuddle Subversion to test at full speed - works well for most of the sensors I'm using.
You might want to look at extending the bike app with some inertial attitude data - I've just finished a Python port of the I2CDevLib MPU6050 MPU reverse-engineering, and it seems to be pumping out attitude quaternions at 100Hz without a problem.
My interest is in aerobatic data logging - some early Arduino-based results here: http://www.youtube.com/watch?v=B4NQlIJiDuE&hd=... - sensor fusion of basic acc/gyro/mag rather than the MPU6050, but looking to move to Pi-based sooner rather than later.
A 3-axis/something for lean angles is a great idea. eharding, what hardware do you have? does the i2c connect to the gpio or is it translated to usb via a virtual com port or something?
Roverspeed - I've been thinking about just that, it can't be that hard to determine what the gear should be based on the RPM and the speed. Although I imagine it might get a bit dodgy at low revs, although should still be quite possible. Might lookup the maths for that and write that up myself.
As for the C vs Python decision, my day job is writing c++ all day, but I would much prefer to do this in Python, and I don't really even know python very well. I agree that it's possible that a few things might not be fast enough, but the baud rate of the OBD2 cable is 38400 or something, which I'm sure python can keep up with. It's also much easier to change things at a whim, and there are also many ready made libraries for things like this. The Pi is definitely not the fastest, but when that becomes a problem i'll address it.
The next step is to buy a USB GPS receiver to get a mini map going possibly. Also I think I'll incorporate the gear calculations.
Roverspeed - I've been thinking about just that, it can't be that hard to determine what the gear should be based on the RPM and the speed. Although I imagine it might get a bit dodgy at low revs, although should still be quite possible. Might lookup the maths for that and write that up myself.
As for the C vs Python decision, my day job is writing c++ all day, but I would much prefer to do this in Python, and I don't really even know python very well. I agree that it's possible that a few things might not be fast enough, but the baud rate of the OBD2 cable is 38400 or something, which I'm sure python can keep up with. It's also much easier to change things at a whim, and there are also many ready made libraries for things like this. The Pi is definitely not the fastest, but when that becomes a problem i'll address it.
The next step is to buy a USB GPS receiver to get a mini map going possibly. Also I think I'll incorporate the gear calculations.
Salgar said:
> A 3-axis/something for lean angles is a great idea. eharding, what hardware do you have? does the i2c > connect to the gpio or is it translated to usb via a virtual com port or something?
I2C is available on the GPIO - grab a HobbyTronics RPi GPIO breakout and a cable, an MPU6050 breakout from eBay (the dual voltage versions work fine with the RPi, just be sure to use the 3.3V rail and don't connect anything to the 5V pin). The MPU6050 is a combined gyro/accelerometer, if you want full-blown sensor-fusion you need a magnetometer as well, and for attitude under dynamic G the static algorithms in the MPU6050 motion sensing stuff may not be enough (I've been recording raw acc/gyro/mag and post-processing). In the first instance, try just grabbing the acc/gyro and recording that. Cheapest MPU6050 I've seen is about $5 - couple of weeks delivery time).Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff