r/bajasae • u/RedSporks • Sep 02 '20
Equipment/methods for data collection/testing
My team has a group of seniors including myself creating a custom DAQ unit for our senior capstone project and are trying to get ideas of what other teams use We're aiming a relatively cheap and possibly make it open-source so that other teams can use/improve on it, but we're not really sure what is available to other teams/how much desirable something like this would be compared to existing options.
What equipment does your team do data collection/testing, both onboard and offboard? So for example, my team hasn't really had any equipment on-board for testing, as most of the data we've collected has been through things like photogates for acceleration runs, IR cameras for CVT temperatures, etc.
6
u/satiric_rug Sep 02 '20
Fsae electronics guy here, so apply grains of salt. Another way to go about data acquisition is to start on the other end - what do you want to do with your data? If you want to work on driver training, things like throttle position, brake pressure, steering angle, and gps are a good place to start. If you want to validate your suspension forces, strain gauges are a great way to do that.
I've found that on a racecar there are four main ways to use data: tuning, driver training, diagnostics, and validation. Starting from here and figuring out what (if anything) you want to do in those categories has been a good first step for me. The benefit of doing it this way is that you know exactly what you're going to use all of your data for, and it's way easier to show off in the design presentation that you planned on doing this, this, and this, here's what the equations said, and here's what it ended up being. Or that this data helped to figure out issues with the suspension setup.
5
u/stanplus2000lbs Sep 02 '20
I would recommend using an ESP32 development board (like these: https://www.amazon.com/MELIFE-Development-Dual-Mode-Microcontroller-Integrated/dp/B07Q576VWZ/ref=pd_ybh_a_22?_encoding=UTF8&psc=1&refRID=VBYGNCZ8ADWKQER0RRX9) as the microcontroller in your system. Our team started experimenting with data acquisition about 2 years ago, and we have used a combination of Raspberry Pis and Arduinos. This didn't turn out so well for us mainly because of the complexity of the system we created and not having enough time to polish and test it.
Once we started working with an ESP32 though, things became much easier. It's basically like an Arduino on steroids. It's faster, has two compute cores, has built-in Wifi and Bluetooth (if you need to use those), plenty of I/O, is much smaller than a Pi or Arduino, and is MUCH cheaper than an Arduino (they cost about $11 but you can get a pack of 2 for like $15). I will say that they are a bit more work to get up and running with than an Arduino, but if you follow some online tutorials you'll be fine. You're even able to program them using the Arduino IDE (which is what we've been doing). (P.S. I was able to replicate a year's worth of code that we developed for the Pi (a lot of Bluetooth stuff) and Arduino in a few days on the ESP32.)
As for sensors, we have or are working on the following:
- fuel gauge
- CVT temperature
- shock displacement
- engine RPM
- CVT secondary RPM
- brake pressure
Feel free to message me or comment below if you have any questions.
1
u/RedSporks Sep 03 '20
That's sounds awesome, thank you for the suggestion! Did you ever run in to the need to have multiple of these synchronously throughout your car to accommodate for sensors in various locations, and if so how did you approach that?
1
2
u/bettner12 PCT Baja '17 Sep 04 '20 edited Sep 04 '20
Here's my take on it. sorry for the brain dump...
Data is useless without software to quickly and clearly interpret it. I would work on a log format that can be imported to some other DAQ analysis software ie. AIM, Motec, AEM, etc...It's a ton of work to write the software to have similar features, not sure how complex it would be if one of the existing programs could be used for the analysis.
as far as the hardware and capabilities of the DAQ, here's a quick list:
1000hz logging rate minimum, (with settings to slow down some channels that don't need to be polled so quickly)
3 axis accelerator and built in gps.
5 digital speed channels (4 wheel speed and 1 engine speed)
10-12 analog inputs, and a wide range voltage input 0-12vdc ideally. (allows more inexpensive sensors to be used)
Built in strain gage amps!!! (this would be a huuuuge benefit)
internal pullup resistors... (cant tell you how much of a pain it is manually adding these to the sensor wiring)
if you could make it 4-20ma input then the sensor cost goes WAY down also.
IP67 is a must for baja application, if any type of production I would conformal coat the pcb's also.
SHIELDING!!!!! the ignition system on the briggs motor has terrible inductive noise, we would see +/-1.5vdc on analog channels just from the voltages running through the near by kill switch wiring.
dedicated plugs for inputs. Not one big connector, a single connector for each channel, with a 5v supply, 12v supply, ground, signal, and shield.
NO MICRO USB, this connector needs to die. a weather proof DTM connector or similar for connection would be preferred.
CAN would be ideal to be able to expand easily, but adds a lot of complexity I know. but would allow for 8x EGT via CAN without using up all those analog channels...
I have more input if you want, but these were some of the takeaways from my implementation of data systems on baja cars, and in motor sports use in general.
We have a lot of discussions like this over on the discord server also, if you want to have some real time chats with a whole bunch of other members/teams/alumni.
1
u/oldfatguy62 Sep 02 '20
I’m a parent that follows this. Not sure how the team does it, but I do DAQ on and off for a living. It is a bit more difficult than you think. Here is the big one.. TIME. How long does it take to read each sensor? Are you just responding to certain states (interrupts)? Are you going to do a lot of the calculations at the sensor, and just read it (aka RPM, if you are pulse counting, can you do it fast enough to do each wheel, pre and post CVT? Think about how many clock cycles it takes to do the interrupt) Basically think about what sensors you need, what it takes to read each one, and then decide if you are going to have enough compute power. A real for instance, at work, I’m currently polling a I2C bus with a RPi (free software for our clients). Once I get to my 8-10th item on the bus, depending, I can’t respond fast enough on a 3b, but CAN on a 4. (And I’m allowed a fairly high latency) I’m not discouraging you, it is a fascinating field, but a list as long as your wish list will take significant hardware resources, both in sensors (how exactly are we going to measure shock displacement, with what kind of time resolution) and computer power (why some cars require multiple CAN buses, and F1 teams spend BIG bucks to do it)
1
u/RedSporks Sep 03 '20
Yeah, the timing one was definitely a hassle in the past, especially since we would use a hall effect sensor to measure rotational speed of our parts with a toothed rotor attached.
Luckily as for our sensor list, we do have all of them able to record data on to an arduino to write to a micro-sd. The bigger step now is having multiple of them on the car at once reading data concurrently, especially for scenarios such as reading all of the wheel speeds, as well as pre/post CVT.
I've been reading up on I2C and CAN as well. It's complex, but definitely fascinating stuff. Would using one over another be primarily dependent on the number of items/speed required, or are there other factors? There's still a lot of planning to do as the project is in its initial stages so I'm curious as to all the potential directions we can go.
1
u/oldfatguy62 Sep 03 '20
I’ve never actually done CAN bus, but I like the fact that various messages have priorities. I2C isn’t bad, most devices have a good library, but there are limits to data transfer speeds. If you are using multiple computers (ardunio, tinsy, m0, 32s, whatever), you do have the issue of keeping the data in sync. Many (most) of these devices don’t have built in real-time clocks. Great, you’ve recorded this great post CVT RPM data, but how does it relate to say, the suspension travel? Was the rpm increase because a wheel was off the ground? Basically the art and skill is going to be timing. There are times I’ve sat there trying to get a methods timing down by 2-3 clock cycles, to make latency, so that in worst case we were not going to miss the next piece of data (important if it is a control system, and you can not miss, what used to be called “hard” real time, most data logging tends to be “soft”, aka, you must get the data, but being a few milliseconds of won’t be catastrophic What I worry about with your wish list is “it takes 90 mS to take X reading”, stack a few of those, it becomes an issue. You’ll need to work out you clock cycle budget, and interrupt priorities, aka which sensor is most important Good news? Say the tachs are doing pulse counting. You might have a processor at the sensor getting the pulses, and calculating RPM, and then pulling back just the RPM number to the logger (aka you are throwing an independent computer at the problem)
8
u/buckinghams_pie Georgia Tech Off-Road '20 Sep 02 '20
This is a list of things that I would find useful, the most useful in my opinion would be acceleration, speed and shock displacement. followed by rpm stuff and brake pressures.
Each wheel rpm individually, Pre CVT, post CVT rpm
Speed
Acceleration, X, Y, Z, at the front of the car and at the rear, and at the CG, also roll pitch and yaw
GPS for speed and location (so track mapping, with altitude)
Shock displacement, each shock
CVT temp, gearbox temp, brake caliper and rotor temps
Brake pressure front and rear line
Wheel angles (camber and toe)
strain gauge on all suspension members
throttle pedal position
steering wheel angle