cyotani

iTrader: (8)

That device uses a digital interface protocol

"•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.

cyotani

iTrader: (8)

Here is a bench testing video of the shift light. Any other idea's of expanding the functionality other than a shift light and warning light?

cyotani

iTrader: (8)

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.

cyotani

iTrader: (8)

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.

vtjballeng

iTrader: (1)

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.

cyotani

iTrader: (8)

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

vtjballeng

iTrader: (1)

1. I'd say it works well and is worth changing the colors.
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

cyotani

iTrader: (8)

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?

vtjballeng

iTrader: (1)

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?

cyotani

iTrader: (8)

For starters I want to set up a warning light system to potentially save my engine if I have an unexpected failure on the track. I then want to add in the necessary sensors to do some basic analysis and improve my driving. However, I do not want to add sensors that I will never use. Shock pots are something that requires a high level of suspension and vehicle dynamics understand to make use of the data which I won't need (at least anytime soon). However, using them to Look at aero download might be useful. The main thing I'd like to set up is a way to overlay different laps for comparison but that will require quite a bit of software development to make a that happen.

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)

mekilljoydammit

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.

nbfather

Cool stuff!
In for the nerdy details !

mekilljoydammit

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?

Leafy

iTrader: (1)

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.

mekilljoydammit

Oh, shock pots are on the list - and purchased already, actually, I found a deal on a bunch of used Motec branded ones a while back. The idea was to use ride height measurement as kind of a sanity check between body movement and wheel movement with a lot of filtering thrown in.

mx5-kiwi

I must have missed it, what ever happened to Cyotani and his project?

That was looking good.

JoshEE

Just wanted to say this is very cool. I'm an ME at NI and it's always fun to see what people do with the hardware/software.

mekilljoydammit

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.

cyotani

iTrader: (8)

Hi,

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.


I haven't played with Labview for the pi yet. It's something I've always wanted to try. For work I do a lot of prototyping data aquisition and the myRIO has been amazing hardware for that task. It was $250 student price when I bought it and $1000 normal price which isn't cheap but it's a bargin compare to most of NI's hardware offerings.

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.

I've tried to integrate OEM TPMS sensor into my system. They are radio frequency sensors. Decoding that communication is beyond my expertise. I got data but couldn't figure out the magic configuration of the transceiver to properly parse the data. I know it can be done with this method and just fed into an arduino or PI. TPMS sensor can be had for as cheap as $10 a piece and the radio receiver is also cheap. I'm hoping to come back to this project again at some point.

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.

With my limited experience of running labview on arduino early on it's library of functions is extremely limited and not flexible. I'd suggest either getting something like the myRIO to program in labview and take advantage of their prebuilt and optimized libraries (SPI, I2C, CAN, PWM, Analog in/out, digital, etc). Or I'd go fully embedded c code which would I'd use a micro controller rather than a microcomputer like the pi. Arduino for starter, or something like the teensy would be ideal.

https://www.sparkfun.com/products/14055


.

mekilljoydammit

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.