I am attempting to make data acquisition system for a Dirt Racecar using a Arduino Mega. First off I was wondering if that is the correct board to use, or if I should use something such as a Due instead (or any other suggestions). The sensors go as follows.
MPU9250 using I2C (feel free to suggest any other MPU's that may work better)
U-Blox M8N using Serial1 (capable of I2C and SPI)
6 Incremental Rotary encoders (needs to use interrupts. Aiming to use pin-change interrupts)
Rf-24 (to send data live to a computer)(using an Arduino Uno)
Taking RPM from motor (figuring out how to effectively take it from 12v to 5v)
We are trying to keep it as cost effective as possible so we are not just going to "buy absolute rotary encoders" to make it easier. We are currently getting 50HZ but more is always better with the quick changing dirt racing cars.
Mostly wondering what suggestions are out there for board selection, but feel free to mention any other changes that would make a difference from a hardware and theoretical perspective.
50Hz is ambitious, but should be do-able. I've done projects with both Due and Mega and I'd probably go with the Due. That doesn't have the special pin-change interrupts - any pin can be an interrupt.
Incremental-only is tough. You don't want to have 6 different buttons to manually set the zero position on each encoder each time you switch the car on. It's impractical to have the steering and everything else centered when you start the motor. Taking the example of steering, I would try to add a single center switch. That will give you an absolute position and you can be pretty sure that you'll get at least one hit on that switch between starting the motor and starting the race.
Power supply is important. Fortunately these days you can get phone chargers that give you clean 5V from the 'dirty' automotive system. They are small and cheap.
You're obviously going to be working on this car. Think about what might go wrong with the wiring to your Arduino. It's too easy to unplug a sensor and accidentally drag that plug over a live 12V part. That sends 12V directly to the heart of your project. Think about creating a secure perimeter inside your box. Everything which crosses that perimeter must be protected against simple accidents like that. The full SAE standard is way too complex to read in one go but it does define all the possible failure scenarios. Read up about "load dump" to see one of the worst ones.
You may get away with stand-alone 328P chips on your own small board or just wired up sockets, not kidding. In qty 100 you should be able to get ATmega328P-PU for $2 or less. If you're looking at 1000's or more then get the boards made with surface mount chips but DO NOT LET THEM PROGRAM THE CHIPS for you even though it'd save work/time and what you do distribute needs to be locked tighter than it's worth. And even then, get ver 2 out before reverse-engineered ver 1 is on eBay cheaper than you can get them.
All ATmega chips have the same core processor which is very capable. I say this as someone who programmed much slower cpu's with a paucity of registers compared in the 80's.
If you write non-blocking code, you can run digital sensing at >50K/sec. How long between 1 rotary click and the next? Using direct port read on a 328P, 6 can be read in 1 cycle and processed in maybe less than 10us. How many times an ms will you need to read that? An interrupt has 86 or 87 cycles overhead each call, if you need it then fine but I doubt than you do.
If you can watch the motor leads with a scope, you might find RPM between the PWM effects.
Play with a magnet and a Hall Switch and a ferrous barrier with holes or slits in it. With stationary magnet and switch and the motor turning a disc with slots might save you the cost of a gear and gear tooth counter.
The GPS and accelerometer, how often do you read them? At some point you dedicate a chip to them and maybe put the RF on that and have the motor chip feed it data. I'm not so thrilled with the libraries for some products because they have functions that block execution so long they need a dedicated controller just for the one device.
Look on youtube for arduino led cube to get an idea of what usually an Uno or Nano/Mini (328P chip) can drive.
You code it as non-blocking information sharing tasks that all reside in void loop() and you should be able to hit your timing very close without taking special measures, especially if you can engineer your needs to fit reasonable and cheap capabilities. That's one of the things my design school teacher taught us was to design to regular production tolerances where possible because of cost. But that was a while ago now.
Line of sight, outdoors, a good ways. What kind of antenna? A trace on the end of a PCB, a stick, a boosted stick?
What about the receiver options?
I wouldn't want to run an RC airplane with a minimal radio unless it was small and could stay within 30 ft to give a safe margin. But even cheap regular BT is good past 100 ft LOS.
It will be covering about 300-500 FT. We have the RF with an amplifier (antenna) which is rated for 1000Ft. No clue if it can actually reach that distance with our current situation.
It will 95% be a clean line of site, there is the occasional point where the car will be behind a scoring tower, but it will be a fraction of a second, and is avoidable if it is an obvious problem.
Also, our code makes the data inflow dependent on the interrupt from the MPU. This makes our data very accurate for timing considering it is independent of the Arduino microcontroller. (will make a different post about the code)
srnet:
At what distance are you wanting to receive this live data ?