Custom Data Acquisition - LabView Powered (IR Tire Temps, PID control systems, etc.)
#21
Senior Member
Thread Starter
iTrader: (8)
Join Date: Jan 2012
Location: Azusa, CA
Posts: 1,407
Total Cats: 116
I thought many times about trying to put together an array of IR sensors for live tire temp data. It would be pretty cool to try it with a cheap IR capable camera too and get the entire tire surface and overlay it on video.
I've also been kicking around the idea of adding a heart rate monitor like they used to in F1. Found this on sparkfun that would be pretty easy to tie into my RacePack USM or any other analog input.
https://www.sparkfun.com/products/8661
I've also been kicking around the idea of adding a heart rate monitor like they used to in F1. Found this on sparkfun that would be pretty easy to tie into my RacePack USM or any other analog input.
https://www.sparkfun.com/products/8661
"•Multiple interfaces: USB, Logic-level serial and I2C"
you would need an arduino or National instruments or similar hardware and program it to talk to each other. The USM is only an analog or frequency input.
#23
Senior Member
Thread Starter
iTrader: (8)
Join Date: Jan 2012
Location: Azusa, CA
Posts: 1,407
Total Cats: 116
I finally got around to programming the tach signal into the myRIO and I now have a functional shift light. However the LEDs are not bright enough for daytime driving. I will need brighter LEDs and have the pointed at the driver more but good progress nonetheless.
#24
Senior Member
Thread Starter
iTrader: (8)
Join Date: Jan 2012
Location: Azusa, CA
Posts: 1,407
Total Cats: 116
Hi guys. Here is Revision 2 of the shift light project. It is now fully sequential with 5 stages. LEDs point straight at the driver and are much brighter 70 ma ones rather then the tri-color 20ma in Rev 1. They are controlled by PWM outputs so I have control over the brightness. I used an analog read on my headlight switch to auto dim the system for night driving.
#25
Hi guys. Here is Revision 2 of the shift light project. It is now fully sequential with 5 stages. LEDs point straight at the driver and are much brighter 70 ma ones rather then the tri-color 20ma in Rev 1. They are controlled by PWM outputs so I have control over the brightness. I used an analog read on my headlight switch to auto dim the system for night driving.
1. Vary color across the LEDs. Green, Amber, Red is common and those LEDs are common.
2. Flash/cycle at ~5hz at a hard pre-programmed limit.
3. Ambient light sensor to drop brightness at night, increase during the day. In both cases, increase during the flash/cycle event in #2.
#26
Senior Member
Thread Starter
iTrader: (8)
Join Date: Jan 2012
Location: Azusa, CA
Posts: 1,407
Total Cats: 116
Looks good. Three suggestions.
1. Vary color across the LEDs. Green, Amber, Red is common and those LEDs are common.
2. Flash/cycle at ~5hz at a hard pre-programmed limit.
3. Ambient light sensor to drop brightness at night, increase during the day. In both cases, increase during the flash/cycle event in #2.
1. Vary color across the LEDs. Green, Amber, Red is common and those LEDs are common.
2. Flash/cycle at ~5hz at a hard pre-programmed limit.
3. Ambient light sensor to drop brightness at night, increase during the day. In both cases, increase during the flash/cycle event in #2.
1. I acquired these LEDs for free from work and only had Red. If this worked well and I was considering buying different color LEDs and swapping some out.
2. it is currently programmed as:
stage 1: 5800 - 2 LEDs on solid
stage 2: 6100 - 4 LEDs on solid
stage 3: 6400 - 6 LEDs on solid
stage 4: 6700 - 8 LEDs on solid
stage 5: 7000 - 8 LEDs on Flashing (5hz)
If this is not similar to what you are referring to I am open to other suggestions for programming. I will be playing with the spread between sequences the next time I go to the track. I also might later make the shift points more time consistent per gear if I implement a gear position input on my DAQ.
3. I currently have a 2 setting dimmer based on the headlight position. So Dim at night with the headlights on and bight during the day. I can also unplug the DAQ easily to kill the shift light for everyday driving
#27
Thank for the feedback.
1. I acquired these LEDs for free from work and only had Red. If this worked well and I was considering buying different color LEDs and swapping some out.
2. it is currently programmed as:
stage 1: 5800 - 2 LEDs on solid
stage 2: 6100 - 4 LEDs on solid
stage 3: 6400 - 6 LEDs on solid
stage 4: 6700 - 8 LEDs on solid
stage 5: 7000 - 8 LEDs on Flashing (5hz)
If this is not similar to what you are referring to I am open to other suggestions for programming. I will be playing with the spread between sequences the next time I go to the track. I also might later make the shift points more time consistent per gear if I implement a gear position input on my DAQ.
3. I currently have a 2 setting dimmer based on the headlight position. So Dim at night with the headlights on and bight during the day. I can also unplug the DAQ easily to kill the shift light for everyday driving
1. I acquired these LEDs for free from work and only had Red. If this worked well and I was considering buying different color LEDs and swapping some out.
2. it is currently programmed as:
stage 1: 5800 - 2 LEDs on solid
stage 2: 6100 - 4 LEDs on solid
stage 3: 6400 - 6 LEDs on solid
stage 4: 6700 - 8 LEDs on solid
stage 5: 7000 - 8 LEDs on Flashing (5hz)
If this is not similar to what you are referring to I am open to other suggestions for programming. I will be playing with the spread between sequences the next time I go to the track. I also might later make the shift points more time consistent per gear if I implement a gear position input on my DAQ.
3. I currently have a 2 setting dimmer based on the headlight position. So Dim at night with the headlights on and bight during the day. I can also unplug the DAQ easily to kill the shift light for everyday driving
2. Sounds good. Being able to alter the shift points is good.
3. I'd still go with the ambient sensor. People have their lights on for a variety of reasons in varying conditions. The ambient sensor will be able to adjust based on real conditions. They are pretty cheap and simple. Your solution is simpler.
Good work
#28
Senior Member
Thread Starter
iTrader: (8)
Join Date: Jan 2012
Location: Azusa, CA
Posts: 1,407
Total Cats: 116
Hi guys. Here's where I'm at with this project. I'm going to test it at the track in a couple weeks. I've used the shiftlight code a few weeks ago at the track and it was awesome!
-12 IR Tire Temp Sensors
-3 axis accelerometer
-tachometer with sequential shift light
-Hall Effect wheel speed sensor
-Oil and water Pressure sensors
-4 thermocouples for temp measurements
-USB drive data logging of all sensors
-LCD display with 4 pages of data
-Custom warning lights based on sensor data
In progress additions:
-GPS
-Steering Angle sensor
-Brake Pressure Sensor
-Suggestions?
-12 IR Tire Temp Sensors
-3 axis accelerometer
-tachometer with sequential shift light
-Hall Effect wheel speed sensor
-Oil and water Pressure sensors
-4 thermocouples for temp measurements
-USB drive data logging of all sensors
-LCD display with 4 pages of data
-Custom warning lights based on sensor data
In progress additions:
-GPS
-Steering Angle sensor
-Brake Pressure Sensor
-Suggestions?
#29
Hi guys. Here's where I'm at with this project. I'm going to test it at the track in a couple weeks. I've used the shiftlight code a few weeks ago at the track and it was awesome!
-12 IR Tire Temp Sensors
-3 axis accelerometer
-tachometer with sequential shift light
-Hall Effect wheel speed sensor
-Oil and water Pressure sensors
-4 thermocouples for temp measurements
-USB drive data logging of all sensors
-LCD display with 4 pages of data
-Custom warning lights based on sensor data
In progress additions:
-GPS
-Steering Angle sensor
-Brake Pressure Sensor
-Suggestions?
-12 IR Tire Temp Sensors
-3 axis accelerometer
-tachometer with sequential shift light
-Hall Effect wheel speed sensor
-Oil and water Pressure sensors
-4 thermocouples for temp measurements
-USB drive data logging of all sensors
-LCD display with 4 pages of data
-Custom warning lights based on sensor data
In progress additions:
-GPS
-Steering Angle sensor
-Brake Pressure Sensor
-Suggestions?
Here is a quick list:
- The obvious math channels on the analysis side
- Direct measurement based or calculated yaw, pitch, roll
- If turbo, air temp before & after intercooler, if NA just intake air temp
- Wheel speed per wheel
- Shock pots
- Level / ride sensor
- Throttle Position
- Lap time
- In car temp
- Water temp
- If turbo, boost pressure
- More depending on what you want out of the system. Is it for improving lap times? Improving the car? Improving the driver?
#30
Senior Member
Thread Starter
iTrader: (8)
Join Date: Jan 2012
Location: Azusa, CA
Posts: 1,407
Total Cats: 116
Basically same stuff you would want on an FSAE car or pro car.
Here is a quick list:
- The obvious math channels on the analysis side
- Direct measurement based or calculated yaw, pitch, roll
- If turbo, air temp before & after intercooler, if NA just intake air temp
- Wheel speed per wheel
- Shock pots
- Level / ride sensor
- Throttle Position
- Lap time
- In car temp
- Water temp
- If turbo, boost pressure
- More depending on what you want out of the system. Is it for improving lap times? Improving the car? Improving the driver?
Here is a quick list:
- The obvious math channels on the analysis side
- Direct measurement based or calculated yaw, pitch, roll
- If turbo, air temp before & after intercooler, if NA just intake air temp
- Wheel speed per wheel
- Shock pots
- Level / ride sensor
- Throttle Position
- Lap time
- In car temp
- Water temp
- If turbo, boost pressure
- More depending on what you want out of the system. Is it for improving lap times? Improving the car? Improving the driver?
Active aero would or water meth injection is another control system project I might try to tackle just for the hell of it. I enjoy these electronics hardware and coding projects that are like challenging puzzles that are rewarding once you solve them. Trying to develop systems that big buck race teams use at fractions of the price is fun. (yes I know... I'm a nerd)
#31
Oh hey, I missed this. Hi, I'm gradually working on bashing together a DAQ setup based on Labview too, though ideally complied for a RasPi (https://www.tsxperts.com/labviewforraspberrypi/) for more affordable hardware. One of the things I want to try looking at is using an optical flow sensor to get slip angle directly and start doing tire mapping, but haven't messed with them. Have you made any progress lately? Also ThePass said that you had some setup reading brake temperature - what sort of temp sensors were you using for that? Most of the Melexis ones I'm seeing max out at around 700F.
I'm also using an ebayed high speed NI card for an engine dyno project, but that's a whole different thing.
I'm also using an ebayed high speed NI card for an engine dyno project, but that's a whole different thing.
#33
All right, screw it, might as well do some thinking out loud here. A lot of this is stuff that won't be fully realized at first, especially since right now I'm sharing an NC with my dad, and it's built to a class that doesn't allow much modding.
In an ideal world, per corner, I'd like 3+ IR sensors for tire temperature, brake rotor temperature, wheel speed, tire pressure, and shock position. Something like 10hz for everything but the shock pot, which should ideally be about 1khz. Looking at either something like 3x MLX90614 IR thermometers for the tire temperatures or 1x MLX90621, which has a 16x4 pixel array on a 120 degree spread. Brake thermometer would be either something like the MLX90616, which reads to 1000C or a rubbing thermocouple and just replace them every so often. Tire pressure is an unsolved question - or at least unsolved on how to do it cheaply; I know Stack has racing grade sensors available but that's kilobucks.
I'm kind of torn between having all the sensors go to one single black box, or having per-corner boxes with relatively simple processors to condense everything into a serial stream. Either way has its advantages and disadvantages.
Main chassis stuff is even easier... front and rear ride height (ultrasonic or laser TOF or... there's a bunch of ways to do that) GPS, basically the standard 9DOF drone sensor package (accels, rate gyros, magnetometers), brake pressure and steering angle, plus engine diagnostic stuff and various temp sensors. I also want to figure out how to have optical flow sensors working because then you can sense slip angle directly.
Acquisition is honestly pretty simple though - you have signals coming in through various ways (analog to digital converters or direct serial for some sensors) and yeah there's a lot of individual sensors but that's just wiring and circuit design.
What should be possible, and clever, is having the DAQ figure things out in real time or after the fact. If you do some reading with the various data acquisition books, go to some seminars and pick people's brains, you start finding that a lot of car behaviors will be reflected in the data even if they're not necessarily apparent to the driver - drivers often just compensate for things when fixing the issue in car setup would be worth time. So long story short, it should be possible to feed the logs into a separate program post-race that would sanity check shock valving, figure out if the balance is out of whack (and in which phase of things so as to suggest fixes) and highlight a bunch of other basic issues... or, while on track, be able to give the driver warning about tire pressure or temperature, suggest brake bias adjustments, point out they're braking early, things like that.
Hardly ambitious at all, right?
In an ideal world, per corner, I'd like 3+ IR sensors for tire temperature, brake rotor temperature, wheel speed, tire pressure, and shock position. Something like 10hz for everything but the shock pot, which should ideally be about 1khz. Looking at either something like 3x MLX90614 IR thermometers for the tire temperatures or 1x MLX90621, which has a 16x4 pixel array on a 120 degree spread. Brake thermometer would be either something like the MLX90616, which reads to 1000C or a rubbing thermocouple and just replace them every so often. Tire pressure is an unsolved question - or at least unsolved on how to do it cheaply; I know Stack has racing grade sensors available but that's kilobucks.
I'm kind of torn between having all the sensors go to one single black box, or having per-corner boxes with relatively simple processors to condense everything into a serial stream. Either way has its advantages and disadvantages.
Main chassis stuff is even easier... front and rear ride height (ultrasonic or laser TOF or... there's a bunch of ways to do that) GPS, basically the standard 9DOF drone sensor package (accels, rate gyros, magnetometers), brake pressure and steering angle, plus engine diagnostic stuff and various temp sensors. I also want to figure out how to have optical flow sensors working because then you can sense slip angle directly.
Acquisition is honestly pretty simple though - you have signals coming in through various ways (analog to digital converters or direct serial for some sensors) and yeah there's a lot of individual sensors but that's just wiring and circuit design.
What should be possible, and clever, is having the DAQ figure things out in real time or after the fact. If you do some reading with the various data acquisition books, go to some seminars and pick people's brains, you start finding that a lot of car behaviors will be reflected in the data even if they're not necessarily apparent to the driver - drivers often just compensate for things when fixing the issue in car setup would be worth time. So long story short, it should be possible to feed the logs into a separate program post-race that would sanity check shock valving, figure out if the balance is out of whack (and in which phase of things so as to suggest fixes) and highlight a bunch of other basic issues... or, while on track, be able to give the driver warning about tire pressure or temperature, suggest brake bias adjustments, point out they're braking early, things like that.
Hardly ambitious at all, right?
#34
I think you still want shock pots (or linear transducers) for measuring suspension travel more than laser or sonic. Lots of that stuff is showing up in the oem world so junk yard scavenging should make it cheap. Looks the the ND has something that'll work in the rear of it, for example. Mounting a reflector for a laser or sonic rigid enough to the car so it doesn't vibrate like crazy is pretty hard in practice and shooting it at the ground is guaranteed to give to bad data.
#38
I'd like to comment that I love Labview - I'm a mechanical engineer, not a coder (by choice anyway) so I judge every programming language by the amount of BS hoops it makes me jump through to do what I want - well, it doesn't hurt either that various jobs have paid to put me through training. The hardware and software costs for doing stuff on my own time got daunting fast though, until the Home Edition was released and I realized what you can find on the secondary market. For the engine dyno project I touched on before, I picked up a PCIe-6251 card that came out of some decommissioned lab off ebay for all of $200.
For the on-car stuff I'm working on, I'm looking at the TSXPERTS products that will compile (a slightly limited subset of) Labview code onto a Raspberry Pi or (a more limited subset onto) an Arduino - I know NI sells embedded systems but I think I can cut down size a lot (and price) by rolling my own hardware for my specific purpose.
For the on-car stuff I'm working on, I'm looking at the TSXPERTS products that will compile (a slightly limited subset of) Labview code onto a Raspberry Pi or (a more limited subset onto) an Arduino - I know NI sells embedded systems but I think I can cut down size a lot (and price) by rolling my own hardware for my specific purpose.
#39
Senior Member
Thread Starter
iTrader: (8)
Join Date: Jan 2012
Location: Azusa, CA
Posts: 1,407
Total Cats: 116
I'm still around and tinkering around with this from time to time. The packaging of tire temp sensor on a street car with fenders is a nightmare. I've decided to focus on open wheel cars for now. A couple guys are running the tire temp system (CAN bus based now) on competitive karting in Europe. Once it's well refined I'll try to start promoting them more but its all just from people who found this thread or the youtube video and reached out to me.
Oh hey, I missed this. Hi, I'm gradually working on bashing together a DAQ setup based on Labview too, though ideally complied for a RasPi (https://www.tsxperts.com/labviewforraspberrypi/) for more affordable hardware. One of the things I want to try looking at is using an optical flow sensor to get slip angle directly and start doing tire mapping, but haven't messed with them. Have you made any progress lately? Also ThePass said that you had some setup reading brake temperature - what sort of temp sensors were you using for that? Most of the Melexis ones I'm seeing max out at around 700F.
I'm also using an ebayed high speed NI card for an engine dyno project, but that's a whole different thing.
I'm also using an ebayed high speed NI card for an engine dyno project, but that's a whole different thing.
I just used the mlx90614 for his setup which does cap off at 700 F but you can overlay two laps with and without their brake ducts system to get an idea of how effective it is. I haven't looked much into a adequate IR temp sensor for a full range brake temp system yet.
All right, screw it, might as well do some thinking out loud here. A lot of this is stuff that won't be fully realized at first, especially since right now I'm sharing an NC with my dad, and it's built to a class that doesn't allow much modding.
In an ideal world, per corner, I'd like 3+ IR sensors for tire temperature, brake rotor temperature, wheel speed, tire pressure, and shock position. Something like 10hz for everything but the shock pot, which should ideally be about 1khz. Looking at either something like 3x MLX90614 IR thermometers for the tire temperatures or 1x MLX90621, which has a 16x4 pixel array on a 120 degree spread. Brake thermometer would be either something like the MLX90616, which reads to 1000C or a rubbing thermocouple and just replace them every so often. Tire pressure is an unsolved question - or at least unsolved on how to do it cheaply; I know Stack has racing grade sensors available but that's kilobucks.
I'm kind of torn between having all the sensors go to one single black box, or having per-corner boxes with relatively simple processors to condense everything into a serial stream. Either way has its advantages and disadvantages.
Main chassis stuff is even easier... front and rear ride height (ultrasonic or laser TOF or... there's a bunch of ways to do that) GPS, basically the standard 9DOF drone sensor package (accels, rate gyros, magnetometers), brake pressure and steering angle, plus engine diagnostic stuff and various temp sensors. I also want to figure out how to have optical flow sensors working because then you can sense slip angle directly.
Acquisition is honestly pretty simple though - you have signals coming in through various ways (analog to digital converters or direct serial for some sensors) and yeah there's a lot of individual sensors but that's just wiring and circuit design.
What should be possible, and clever, is having the DAQ figure things out in real time or after the fact. If you do some reading with the various data acquisition books, go to some seminars and pick people's brains, you start finding that a lot of car behaviors will be reflected in the data even if they're not necessarily apparent to the driver - drivers often just compensate for things when fixing the issue in car setup would be worth time. So long story short, it should be possible to feed the logs into a separate program post-race that would sanity check shock valving, figure out if the balance is out of whack (and in which phase of things so as to suggest fixes) and highlight a bunch of other basic issues... or, while on track, be able to give the driver warning about tire pressure or temperature, suggest brake bias adjustments, point out they're braking early, things like that.
Hardly ambitious at all, right?
In an ideal world, per corner, I'd like 3+ IR sensors for tire temperature, brake rotor temperature, wheel speed, tire pressure, and shock position. Something like 10hz for everything but the shock pot, which should ideally be about 1khz. Looking at either something like 3x MLX90614 IR thermometers for the tire temperatures or 1x MLX90621, which has a 16x4 pixel array on a 120 degree spread. Brake thermometer would be either something like the MLX90616, which reads to 1000C or a rubbing thermocouple and just replace them every so often. Tire pressure is an unsolved question - or at least unsolved on how to do it cheaply; I know Stack has racing grade sensors available but that's kilobucks.
I'm kind of torn between having all the sensors go to one single black box, or having per-corner boxes with relatively simple processors to condense everything into a serial stream. Either way has its advantages and disadvantages.
Main chassis stuff is even easier... front and rear ride height (ultrasonic or laser TOF or... there's a bunch of ways to do that) GPS, basically the standard 9DOF drone sensor package (accels, rate gyros, magnetometers), brake pressure and steering angle, plus engine diagnostic stuff and various temp sensors. I also want to figure out how to have optical flow sensors working because then you can sense slip angle directly.
Acquisition is honestly pretty simple though - you have signals coming in through various ways (analog to digital converters or direct serial for some sensors) and yeah there's a lot of individual sensors but that's just wiring and circuit design.
What should be possible, and clever, is having the DAQ figure things out in real time or after the fact. If you do some reading with the various data acquisition books, go to some seminars and pick people's brains, you start finding that a lot of car behaviors will be reflected in the data even if they're not necessarily apparent to the driver - drivers often just compensate for things when fixing the issue in car setup would be worth time. So long story short, it should be possible to feed the logs into a separate program post-race that would sanity check shock valving, figure out if the balance is out of whack (and in which phase of things so as to suggest fixes) and highlight a bunch of other basic issues... or, while on track, be able to give the driver warning about tire pressure or temperature, suggest brake bias adjustments, point out they're braking early, things like that.
Hardly ambitious at all, right?
You should have enough processing power to do everything in a single black box. But one box per corner with CAN communication to a central logger would simplify wiring. Maybe one front and one rear box could be a good compromise..
The only thing I didn't see listed is CAN bus Engine/ECU data. Either OBD2 if you have a factory ECU or CAN broadcast parsing if you have megasquirt or similar aftermarket ECU. This data is all digital and readily available.
Yup, all of the data in the world is useless unless you know what to do with it. A post processing script to reduce the data into an easy to view report is a must or you'll end up never looking at the data. I haven't started on this section yet but it should be a fun challenging project.
I'd like to comment that I love Labview - I'm a mechanical engineer, not a coder (by choice anyway) so I judge every programming language by the amount of BS hoops it makes me jump through to do what I want - well, it doesn't hurt either that various jobs have paid to put me through training. The hardware and software costs for doing stuff on my own time got daunting fast though, until the Home Edition was released and I realized what you can find on the secondary market. For the engine dyno project I touched on before, I picked up a PCIe-6251 card that came out of some decommissioned lab off ebay for all of $200.
For the on-car stuff I'm working on, I'm looking at the TSXPERTS products that will compile (a slightly limited subset of) Labview code onto a Raspberry Pi or (a more limited subset onto) an Arduino - I know NI sells embedded systems but I think I can cut down size a lot (and price) by rolling my own hardware for my specific purpose.
For the on-car stuff I'm working on, I'm looking at the TSXPERTS products that will compile (a slightly limited subset of) Labview code onto a Raspberry Pi or (a more limited subset onto) an Arduino - I know NI sells embedded systems but I think I can cut down size a lot (and price) by rolling my own hardware for my specific purpose.
https://www.sparkfun.com/products/14055
.
#40
Skipping the quotes because there's a lot of text.
I did leave out ECU communication, but yeah, definitely that. My basic thinking is to feed all of the engine health related sensors into the ECU and have it talk to a dash and the logger... I don't want any part of the stuff keeping the engine healthy to be compromised by my ... uhm... unknown quality hard/software.
Simplifying wiring is exactly what I was looking at with the CAN communication - all the little subboxes would need to do is a crunch the data and send it, so they could really be down in the ATMega328 range - probably coded like an Arduino rather than trying to mess with compiled Labview code. The main reason I want to try to make it run Labview is the crazy idea of having various analysis scripts running in realtime... well, OK, and I want to play with that Labview Pi compiler, honestly. If I stuck to having the onboard stuff just acquiring data I could almost definitely just do it with a Teensy and some added hardware.
I did leave out ECU communication, but yeah, definitely that. My basic thinking is to feed all of the engine health related sensors into the ECU and have it talk to a dash and the logger... I don't want any part of the stuff keeping the engine healthy to be compromised by my ... uhm... unknown quality hard/software.
Simplifying wiring is exactly what I was looking at with the CAN communication - all the little subboxes would need to do is a crunch the data and send it, so they could really be down in the ATMega328 range - probably coded like an Arduino rather than trying to mess with compiled Labview code. The main reason I want to try to make it run Labview is the crazy idea of having various analysis scripts running in realtime... well, OK, and I want to play with that Labview Pi compiler, honestly. If I stuck to having the onboard stuff just acquiring data I could almost definitely just do it with a Teensy and some added hardware.