Joint Data-Acquisition hardware development?

[aaahaaap]

Since most FSAE teams will have about the same requirements for a data acquisition system I was wondering if it would be possible to join forces and start the development of an (open-hardware/open-source) data-acquisition system in a group effort.

Basically when looking around for a decent data acquisition system it is pretty obvious a proper one can not be had for less than €1500.
And those usually come with sub-par software.

What I would like to know is if there are more people interested in this?
If so, maybe we can define our common requirements and try to spec the hardware around those requirements.

I personally feel like leaving the software part alone for the beginning, since the logged data can be imported and analyzed in Excel/Matlab/Pylab/Windarab/etc.

[Gregor]

That is a really good idea. Our team this year is designing a DAQ system using ARM microcontrols CAN bus to interface with sensors. A team member is modifying a RTOS he made for ARM to run the DAQ.
The hardest part of this project for us will be writing good and refined data analysis software to use with the DAQ.

After our hardware design is done we could release it under an open source hardware license and then get a development community around the programing for it.

At our next meeting I will see how the idea goes over with the other team members. possibly soon have project documentation online some where.

[MalcolmG]

why write a data analysis software when so many good ones already exist? I have never looked at importing different data formats, but I'll bet you can either import CSVs into Motec i2 (or any other free data analysis software) or reverse engineer the data format they use.

[scott_rfr]

Here at Rutgers we have had our own data system for a while. Student designed boards and firmware on the boards.

As far as software goes we have always used Matlab. Over the years (espically the last two) a couple of us have wrote a ton of m-files to process the data. Our data collection software was written in VB and we just click an export button, select the m-file and its all done. Matlab has a lot of really great easy to use built in functions (fft, filtering, etc).

I would focus more on the hardware development and leave the software to matlab. You can write m-files so quick. Just getting the hardware to run reliably is a lot more work than you might think.

Scott

[aaahaaap]

I agree with both Malcolm and Scott about focussing on the hardware (first).

If any teams are willing to share their design documents and/or their hardware designs we could start defining common properties from there.

IMHO there doesn't have to be 1 single implementation, different solutions could be developed (based on PIC, AVR, ARM, etc), as long as there is a common way to connect different modules. This would probably be the CAN bus, which would also make it possible to be compatible with existing ECU's, dataloggers and dashes.

I did some searching and found the following:
http://code.google.com/p/fsae-dash/
http://ecee.colorado.edu/~ecen...xpos06/darsi_PDR.ppt (http://ecee.colorado.edu/%7Eecen4610/expos06/darsi_PDR.ppt)
http://instruct1.cit.cornell.e...p22_spg32/index.html (http://instruct1.cit.cornell.edu/Courses/ee476/FinalProjects/s2008/dhp22_spg32/dhp22_spg32/index.html)

Simon

[JeffreyH]

Heh, wow. That's our dash there, I'd forgotten about that. We used google code as a convenient SVN repository to collaborate on the hardware design. By the looks of that it's an early design though. It's not a datalogger, rather it's designed to sit in the steering wheel and suck data off our Motec datalogger and display it on an LCD in a variety of modes.

[aaahaaap]

Originally posted by JeffreyH:
Heh, wow. That's our dash there, I'd forgotten about that. We used google code as a convenient SVN repository to collaborate on the hardware design. By the looks of that it's an early design though. It's not a datalogger, rather it's designed to sit in the steering wheel and suck data off our Motec datalogger and display it on an LCD in a variety of modes.
Hi Jeffrey,

I'm aware of the fact it's "only" a dash, but it uses CAN and an AVR (and is FSAE related) so I thought I'd link to i anyway (don't know if it was intended to be this openly accessible?)

Pity there isn't any actual code though.
Do you know how they got on with the AT90CAN128?

Would your team be willing to share some (morehttp://fsae.com/groupee_common/emoticons/icon_wink.gif) data?

Simon

[JeffreyH]

Yea we haven't put the code in the SVN repository. The only problem we have with the AT90CAN is that we're pretty much at its performance limit with it drawing the screen. Similarly a bit more memory would be nice. We're hoping to move to an ARM in a future dash but it's definitely adequate. The main designer of the dash posts on this forum from time to time, I'll ask him to read this. Both of us are generally in favour of open source development so I don't think there's a problem with us sharing some info.

Here's a pic of it so you can kinda see the context.

http://www.fsae.co.nz/images/stories/news/dash_in_car.jpg

[JeffreyH]

To better explain that pic, that display is one of a number of modes on the dash, you poke it to get back to the main menu then move to the one you want. We use it for a number of things.

It's not directly applicable but if we can help you out in any specific way, let me know.

[aaahaaap]

Already found the picture before your post was approved http://fsae.com/groupee_common/emoticons/icon_wink.gif
Another one here (http://www.fsae.co.nz/index.php?option=com_gallery2&Itemid=28&g2_itemId=357).

What you're saying about the AT90CAN is what I was worried about, not having enough processing power/memory to do multiple things.

Would an external CAN controller help (by taking the processing power and storage requirements for the CAN part out)?

[aaahaaap]

Originally posted by JeffreyH:
To better explain that pic, that display is one of a number of modes on the dash, you poke it to get back to the main menu then move to the one you want. We use it for a number of things.

It's not directly applicable but if we can help you out in any specific way, let me know. Thanks for the explanation and offering your help.

A dash could (or should?) end up being part of this project as well, so anything you are willing to share is welcome.

The design document/choices would be a good start, as input for defining the requirements.
And any issues/problems your team ran into whilst implementing it (both hardware and software) are more than welcome as well! http://fsae.com/groupee_common/emoticons/icon_smile.gif


Originally posted by Gregor:
That is a really good idea. Our team this year is designing a DAQ system using ARM microcontrols CAN bus to interface with sensors. A team member is modifying a RTOS he made for ARM to run the DAQ.
The hardest part of this project for us will be writing good and refined data analysis software to use with the DAQ.

After our hardware design is done we could release it under an open source hardware license and then get a development community around the programing for it.

At our next meeting I will see how the idea goes over with the other team members. possibly soon have project documentation online some where.
Gregor, if your team would be willing to share the hardware design under an open license, that would be awesome!
The documentation would be great as well as input for defining common requirements.

I could setup a google code/launchpad/github/etc. account to start the project and discussion, but it might be a bit early.

Simon

[lozo]

Originally posted by aaahaaap:
Already found the picture before your post was approved http://fsae.com/groupee_common/emoticons/icon_wink.gif
Another one here (http://www.fsae.co.nz/index.php?option=com_gallery2&Itemid=28&g2_itemId=357).

What you're saying about the AT90CAN is what I was worried about, not having enough processing power/memory to do multiple things.

Would an external CAN controller help (by taking the processing power and storage requirements for the CAN part out)?

Hi there,

I designed the electronics of the dash that Jeffrey put up. With regards to chip selection, the AT90CAN128 is pretty much maxed out in both capacity and processing power (fonts are expensive in memory, and drawing screens continuously is computationally expensive). Given a choice I'd have gone for something more grunty (16 or even 32 bit perhaps). In my opinion the AT90CAN128 could work for small scale datalogging, but you'd hit the wall relatively quickly.

A CAN controller would be a good thing to use, but quite a few 32 bit chips like the LPC2194, PIC32s, AT91SAMs) have inbuilt CAN controllers and that reduces component count.

The dash itself is implemented using CAN input packets generated from our EDL2. Software issues are mainly performance based, and the fact that our ECU outputs a serial stream of information at 20Hz means that most information is not updated immediately within the dash (~50ms latency).

Hope that helped http://fsae.com/groupee_common/emoticons/icon_smile.gif

[GTS]

Originally posted by Gregor:
The hardest part of this project for us will be writing good and refined data analysis software to use with the DAQ.


Some might consider this to be more important (if less glamorous) work, and a good area for collaboration.

[aaahaaap]

Originally posted by GTS:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Gregor:
The hardest part of this project for us will be writing good and refined data analysis software to use with the DAQ.


Some might consider this to be more important (if less glamorous) work, and a good area for collaboration. </div></BLOCKQUOTE>
I will be the first to admit the analysis software is of great importance (if not more than the hardware), but IMHO there are enough solutions out there, be it general purpose like Matlab/pylab, manufacturer specific (WinDarab/I2) or non-manufacturer specific (Atlas), that can be used with general datalogging data to make it the lowest priority part of the DAQ development.

But if anybody wants to develop a decent data-analysis software package he or she is more than welcome to join http://fsae.com/groupee_common/emoticons/icon_smile.gif

[murpia]

Finding a data analyis package that meets the following criteria will be your problem:

Decent function set, with motorsport specific features, especially lap overlays and math channels
Cheap (or free)
Imports ASCII or similar open file format
Licenced to use with other manufacturers dataloggers (although you may not care about that one http://fsae.com/groupee_common/emoticons/icon_smile.gif)

I know of none, and I've looked hard!

Note: programming MATLAB to act as a decent motorsport analysis package is not a trivial task. Mainly because the graphs are not multi-y-axis (just 2-y-axis), and decent MATLAB GUIs are hard to implement.

Regards, Ian

[aaahaaap]

Originally posted by murpia:
Finding a data analyis package that meets the following criteria will be your problem:

Decent function set, with motorsport specific features, especially lap overlays and math channels
Cheap (or free)
Imports ASCII or similar open file format
Licenced to use with other manufacturers dataloggers (although you may not care about that one http://fsae.com/groupee_common/emoticons/icon_smile.gif)

I know of none, and I've looked hard!

Note: programming MATLAB to act as a decent motorsport analysis package is not a trivial task. Mainly because the graphs are not multi-y-axis (just 2-y-axis), and decent MATLAB GUIs are hard to implement.

Regards, Ian
Personally I don't read licenses, so I don't really care about that one http://fsae.com/groupee_common/emoticons/icon_wink.gif

Windarab can import CSV-files directly.
Racestudio can't (though I don't consider Racestudio good software)
Don't know about PI software, as I haven't used it yet

Has anybody contacted Atlas/McLaren for an FSAE discount?

I agree that it would be great if there would be an open-source data-analysis package, but it's not that hard to live without one.

[SNasello]

Someone from 2D-Datarecording posted about a year ago on these forums that they were seeing a lack of good data analysis software being used by Formula Student teams. They wanted to provide their software free of cost to any team that wanted it.

I have yet to use the software but apparently it can to import data in generic formats. This software is also used by MotoGP teams so I would presume that it is quite powerful.

The link to the post I am talking about is here:
http://fsae.com/eve/forums/a/t...10721641#31610721641 (http://fsae.com/eve/forums/a/tpc/f/412600868/m/31610721641?r=31610721641#31610721641)

[GTS]

I am not sure, aaahaaap.

You can acquire data with almost anything - many suitable systems exist, new, under EUR1500 - data processing is the key. Even the best commercial programs aren't suited to FSAE and won't prove much 'out of the box'. There's a lot to learn - and to be gained - in writing your own analysis codes.

There's a lot to be gained, and saved, in understanding/collaborating on sensor selection (which, unabated, can cost considerably more than your logger). There's a lot to be gained in collaborating on DAQ procedures (design of experiment, sensor setup/calibration, wiring installation/noise reduction etc procedures).

Your own DAQ hardware - a sort of DAQ take on MegaSquirt - would be a very commendable achievement. I would wonder how much faster it makes your car though, or what depth of development it adds to it.

It's been a long time since I did FSAE - I'd written a good number of codes for various motorsport applications since that were very effective. I put a proposal to my university to write most of these into a common codebase, set it up as a code repository, have students contribute etc. Unfortunately we couldn't find someone to maintain it (myself included). The demonstration I was able to put together did a lot of useful things that commercial packages simply don't do out of the box, and could be configured very quickly. It was able to generate session reports very quickly and was compatible with logging formats from a few commercial platforms. Highly configurable and able to generate all sorts of visualisations (3D is not a problem), including dynamic kinematic viz. It was based on commonly available (MATLAB) and/or free (Octave) software, with the reporting done in another free package called from the former.

It really doesn't matter what you use, though for those of you interested in a career in professional motorsports you'll find experience in either MATLAB or VBA (or both) to be very useful.

Best of luck with your projects.

[murpia]

Originally posted by aaahaaap:
I2 can import them indirectly.
Care to explain how?

Pi Toolbox, ATLAS and WinTAX will import ASCII data - at a price!

Regards, Ian

[aaahaaap]

You can acquire data with almost anything - many suitable systems exist, new, under EUR1500 - data processing is the key.
There is enough hardware available under €1500, but when you want a decent logging rate (1000Hz+), CAN-connectivity, at least 10 (or 12)-bit accuracy and to connect your own sensors it quickly becomes a lot more expensive.
(though if I've missed a device that's capable of all this apart from the EVO4 please let me know http://fsae.com/groupee_common/emoticons/icon_smile.gif)


There's a lot to be gained, and saved, in understanding/collaborating on sensor selection (which, unabated, can cost considerably more than your logger). There's a lot to be gained in collaborating on DAQ procedures (design of experiment, sensor setup/calibration, wiring installation/noise reduction etc procedures).

Your own DAQ hardware - a sort of DAQ take on MegaSquirt - would be a very commendable achievement. I would wonder how much faster it makes your car though, or what depth of development it adds to it.
MegaSquirt for DAQ's is a nice way to look at it http://fsae.com/groupee_common/emoticons/icon_wink.gif
As we all know DAQ's don't make the car faster, but it will help in making the process of improving the car and the driver(!) faster.

+When done as a collaborative effort, it would mean less time spent on DAQs by individual teams, so more time for other issues.


Even the best commercial programs aren't suited to FSAE and won't prove much 'out of the box'. There's a lot to learn - and to be gained - in writing your own analysis codes.
I agree with both of these points, it's just that without the hardware it's impossible to do anything and without the self-written software it's still possible to do most of the analysis (it just might take a little more time and/or effort).


It's been a long time since I did FSAE - I'd written a good number of codes for various motorsport applications since that were very effective. I put a proposal to my university to write most of these into a common codebase, set it up as a code repository, have students contribute etc. Unfortunately we couldn't find someone to maintain it (myself included). The demonstration I was able to put together did a lot of useful things that commercial packages simply don't do out of the box, and could be configured very quickly. It was able to generate session reports very quickly and was compatible with logging formats from a few commercial platforms. Highly configurable and able to generate all sorts of visualisations (3D is not a problem), including dynamic kinematic viz. It was based on commonly available (MATLAB) and/or free (Octave) software, with the reporting done in another free package called from the former.
Sounds really interesting!
I know it's hard to get and keep(!) things going when there's only a small group of people involved, that's why I'm trying to get this started as an open-source/open-hardware project.

You happen to have any screenshots (or more) of the software you can share?


Best of luck with your projects.
Thanks (for your in-depth reply as well)!



Pi Toolbox, ATLAS and WinTAX will import ASCII data - at a price! Maybe they do educational/FSAE discounts?

Simon

[GTS]

Simon

I'm not sure you'd need >1kHz for anything on a FSAE car - what are you hoping to acquire at >1kHz? I can think of a few applications but none that I'd put through a standard logger, and none that I've seen a need to run through an FSAE racer. You've got me interested - what do you think you'll need >1kHz for?

CAN is useful but not a deal-changer for an FSAE project. You'll live with RS232 - or not at all. More important on an ECU in a dyno cell.

There are a few loggers in that price range that do 12-bit (most stuff does 10-bit). I don't see that connecting your own sensors is a problem?

I would like to see teams get together and put together a wiki or something similarly structured on DAQ procedures. It'd help a lot, and ensure that knowledge year-to-year doesn't go to waste.

I'm not a specialist in hardware, but reliable hardware is no small for task seasoned pros, let alone for a group of impassioned students trying to build a car whilst finishing engineering degrees. MS took Bowling and Grippo many years. Development for reliable units by experienced professionals takes at least a year for something simple (I've seen a few examples). In your position, I'd take being hamstrung with hardware that does 80% of what I want it to but that works the second I take delivery, such that I could start doing things. Any improvements against the clock come in analysis - sure, for that you need data - but analysis takes time. If you can't bet on your DAQ package giving you a deeper insight than a talented/experienced driver and some simple head checks, then it's worthless - just hire a professional driver for an afternoon or two, bring tools/spares and take notes - developing the hardware from scratch doesn't necessarily get you further along this route.

Sharing pics involves disclosing the team and sharing their data (or those of some of my previous projects/clients), though rest assured that there's nothing Earth-shattering. What's more important is that at the end of every session, you'd download data and within three minutes (code wasn't optimised) you'd get a nice PDF with (largely) full vector graphics that'd give you what you needed to make decisive decisions based on software whose functions you understood.

A good deal of work went into coding in 'head checks' to see how reliable data actually was. With any problems, the software would trash suspect channels and write reasons and suggestions back to the report. I've lost count of the number of times I've seen FSAE students spend hours trying to make sense of data i2 (or similar) that has major acquisition flaws that they can't appreciate - a lot of wasted time. Professional packages assume your data is reliable from word go. I'd prefer to assume you're students and that this is a learning exercise... so code in your learning and help it happen faster! This sort of stuff still helps me too.

Where possible, logical arguments based on data assessment would alleviate a lot of work and give an initial report of notes and warnings, e.g. 'The left front reaches full bump during corner 4 at xx.xx during lap 5'. Simple stuff (a bunch of IF statements) but it makes making sense of data very simple. Lap-to-lap comparisons for all valid laps (some simple logic trashed 'off' laps) were automated. Some other people I'd worked with previously contributed some more detailed logic for suspension assessment, and the observations the software could generate were pretty insightful regards suspension setup or driver performance (there was a lot more that could be done here). The track positioning engine was quite nice and could take two GPS streams (one trackside) for better repeatability and made good use of any accurate 'real' speed channels (again, I can't take credit for it).

There were quite a few other nice, unique touches, too long to go into here. At the end of the day I'm sure a few of you could get a lot further than I. This was a small effort over a number of disparate projects over a few years by myself primarily and a few colleagues as needs arose and projects overlapped. By contrast you'll never have as much energy to complete something like this (or as much time) as you will whilst doing FSAE. Plus, writing the DAQ analysis code's a nice challenge - you get to learn a bit about every aspect of the car as team members require something new of the package to show up some key phenomena in their work.

[aaahaaap]

I'm not sure you'd need >1kHz for anything on a FSAE car - what are you hoping to acquire at >1kHz? I can think of a few applications but none that I'd put through a standard logger, and none that I've seen a need to run through an FSAE racer. You've got me interested - what do you think you'll need >1kHz for?
Basically for suspension/damper analysis and development, integrating halves the effective sample-rate, so for damper speed you end up with 500Hz and for accel 250Hz.
You feel like those are (too) high sample-rates?
I'm no data-analysis superuser, so if I'm mistaken please tell me.

CAN is useful but not a deal-changer for an FSAE project. You'll live with RS232 - or not at all. More important on an ECU in a dyno cell.
Both CAN and RS232 would be best, to be compatible with all possible ECU's.


There are a few loggers in that price range that do 12-bit (most stuff does 10-bit). I don't see that connecting your own sensors is a problem?
AFAIK some DAQs/software doesn't allow custom sensors (calibration).
Not saying this is a common thing, but I just don't want to get stuck with sensors that are way too expensive just because I have to buy them from the DAQ manufacturer.


I would like to see teams get together and put together a wiki or something similarly structured on DAQ procedures. It'd help a lot, and ensure that knowledge year-to-year doesn't go to waste.
That's the main thing I'm trying to achieve at the moment, just get some thoughts and ideas exchange so documentation can be written for everyone so energy can be spent on improving things next time instead of re-thinking and re-doing things that were already done in the past.


I'm not a specialist in hardware, but reliable hardware is no small for task seasoned pros, let alone for a group of impassioned students trying to build a car whilst finishing engineering degrees. MS took Bowling and Grippo many years. Development for reliable units by experienced professionals takes at least a year for something simple (I've seen a few examples). In your position, I'd take being hamstrung with hardware that does 80% of what I want it to but that works the second I take delivery, such that I could start doing things. Any improvements against the clock come in analysis - sure, for that you need data - but analysis takes time. If you can't bet on your DAQ package giving you a deeper insight than a talented/experienced driver and some simple head checks, then it's worthless - just hire a professional driver for an afternoon or two, bring tools/spares and take notes - developing the hardware from scratch doesn't necessarily get you further along this route. Fully agree, but I've seen my share of issues with commercial DAQ packages as well, no guarantees for a painless route therehttp://fsae.com/groupee_common/emoticons/icon_wink.gif
I'm not saying we would be able to do better in 6months time than what's already available, just that it would be a great idea and possibility to develop the hardware ourselfs and see it as a longer term investment to save money (and possibly time) in the future.
For people who'd like to participate I'd still say make sure you've got a working DAQ before you start the project, no guarantees it'll work as planned the first time round.

It doesn't have to be anything fancy, basically and MCU+ADC+CAN/RS232+storage (and offcourse the added complexity of the supporting circuits/noise-isolation/automotive environment) would be sufficient.
By keeping it simple with as few and as simple as possible components you can prevent a lot of issues the easy way.

And there are already a lot of teams who have created (parts of) the ECU/DAQ/dash system.
And it would be a waste to not make use of the knowledge and experience they gained from that (apart from things teams would like to keep in-house offcourse).
Teams are already spending resources on the development of their own ECU/DAQ/dash/other parts, working together can help to improve the final product.



Sharing pics involves disclosing the team and sharing their data (or those of some of my previous projects/clients), though rest assured that there's nothing Earth-shattering. What's more important is that at the end of every session, you'd download data and within three minutes (code wasn't optimised) you'd get a nice PDF with (largely) full vector graphics that'd give you what you needed to make decisive decisions based on software whose functions you understood.

A good deal of work went into coding in 'head checks' to see how reliable data actually was. With any problems, the software would trash suspect channels and write reasons and suggestions back to the report. I've lost count of the number of times I've seen FSAE students spend hours trying to make sense of data i2 (or similar) that has major acquisition flaws that they can't appreciate - a lot of wasted time. Professional packages assume your data is reliable from word go. I'd prefer to assume you're students and that this is a learning exercise... so code in your learning and help it happen faster! This sort of stuff still helps me too.

Where possible, logical arguments based on data assessment would alleviate a lot of work and give an initial report of notes and warnings, e.g. 'The left front reaches full bump during corner 4 at xx.xx during lap 5'. Simple stuff (a bunch of IF statements) but it makes making sense of data very simple. Lap-to-lap comparisons for all valid laps (some simple logic trashed 'off' laps) were automated. Some other people I'd worked with previously contributed some more detailed logic for suspension assessment, and the observations the software could generate were pretty insightful regards suspension setup or driver performance (there was a lot more that could be done here). The track positioning engine was quite nice and could take two GPS streams (one trackside) for better repeatability and made good use of any accurate 'real' speed channels (again, I can't take credit for it).

There were quite a few other nice, unique touches, too long to go into here. At the end of the day I'm sure a few of you could get a lot further than I. This was a small effort over a number of disparate projects over a few years by myself primarily and a few colleagues as needs arose and projects overlapped. By contrast you'll never have as much energy to complete something like this (or as much time) as you will whilst doing FSAE. Plus, writing the DAQ analysis code's a nice challenge - you get to learn a bit about every aspect of the car as team members require something new of the package to show up some key phenomena in their work.
Thanks for the explanation, sound like software that was made by people with experience (instead of just number-crunchers http://fsae.com/groupee_common/emoticons/icon_wink.gif).

There IS a lot to learn in creating a decent (FSAE) Data-Analysis package, I wouldn't mind to discuss its features and implementation as well.
Like I said before, if there are any volunteers to start developing a Data Analysis package I'm all for it!

Simon

[GTS]

Simon;

Aware that your fastest sample rate is on channels requiring integration (suspension movement the quickest of these) though >1kHz is excessive. This said, making good sense of you suspension data beyond head checks, sector times and good driver feedback is much harder work than just acquiring it.

Don't worry about CAN or RS232 if you're squeezed on price. Run a lap beacon signal into both your logger and ECU, use this to synchronise your data in post processing. A reliable lap timer with output is inexpensive and easily available (there's one I use often). I keep CAN on the ECU as:

<UL TYPE=SQUARE>
<LI>It allows better in-field tuning where this is supported (but I'm yet to see this happen in FSAE, most tuning is post-run - this is relevant to cars I can fit a laptop into).
<LI>It allows interfacing with other hardware - on the dyno, this is important, as I run other acquisition hardware that's important to have in real time beyond the scope of what's on the ECU itself (think about this one).
[/list]

You could use this argument for a dash as well but consider quite seriously what information a driver needs to actually go quicker and what information a driver has time to digest on the move. If you have time to take into account anything that demands a CAN interface of your logger... you're not going quick enough! I'm not saying it's not useful, more that there's very little information you actually need. A two wire connection is nice, it's not going to kill you not to have it. If all you want are lap times and engine speed then a second-hand MyChron is easy enough to come by... or a lap timer and a shift light circuit is even cheaper. There are few other things I'd put on a dash but I'm yet to see them implemented in FSAE.

Most decent hardware in your bracket (e.g. a DL1) will allow custom hardware.

I'd suggest the task is a little more involved than what you specify, but not impossible either. Whether you build a logger or not, a good exercise would be to undertake the initial engineering design exercise - to formally go through initial abstraction, generating a PDS, concept generation and selection, FMEA etc, just as you would if you were intent on committing time and resources to designing a proper logger. Done properly in a collaborative environment, it'd give everyone a better idea of what's really required.

It might also give a better insight into the other major expenditure here - sensor selection - an area where much $ can be saved with a little forethought.

[aaahaaap]

Don't worry about CAN or RS232 if you're squeezed on price. Run a lap beacon signal into both your logger and ECU, use this to synchronise your data in post processing. A reliable lap timer with output is inexpensive and easily available (there's one I use often).

Good suggestion, I thought about it as well, but there's one problem. Not everybody has an ECU that has logging capabilities, and if it can its data has te be imported in the DAQ software (which get's us to the software-issue again http://fsae.com/groupee_common/emoticons/icon_wink.gif)


You could use this argument for a dash as well but consider quite seriously what information a driver needs to actually go quicker and what information a driver has time to digest on the move. If you have time to take into account anything that demands a CAN interface of your logger... you're not going quick enough! I'm not saying it's not useful, more that there's very little information you actually need. A two wire connection is nice, it's not going to kill you not to have it. If all you want are lap times and engine speed then a second-hand MyChron is easy enough to come by... or a lap timer and a shift light circuit is even cheaper. There are few other things I'd put on a dash but I'm yet to see them implemented in FSAE.
I'm not too sure about the (functions of the) dash myself, but since it has already been done by Auckland/ JeffreyH and they might want to contribute it is a nice option to have.
Each individual team could decide to use it or not.


I'd suggest the task is a little more involved than what you specify, but not impossible either. Whether you build a logger or not, a good exercise would be to undertake the initial engineering design exercise - to formally go through initial abstraction, generating a PDS, concept generation and selection, FMEA etc, just as you would if you were intent on committing time and resources to designing a proper logger. Done properly in a collaborative environment, it'd give everyone a better idea of what's really required.
Have to agree with you again http://fsae.com/groupee_common/emoticons/icon_smile.gif
It will probably be a lot harder than expected, but isn't that (almost) always the case?

I went ahead and wrote some things down to start the initial/requirements phase of the project, we'll see how far I/we can come.

I've create a google code project here:
http://code.google.com/p/fsae-daq/

If everyone interested can have a look at the Requirements draft in the wiki http://code.google.com/p/fsae-daq/wiki/Requirements and give some feedback/suggestions/etc.
I'd like to use the input and results of this as input for a design brief and a PDS.


It might also give a better insight into the other major expenditure here - sensor selection - an area where much $ can be saved with a little forethought.
I guess it would be smart to take sensor selection into consideration and speccing the requirements around the chosen sensors.

Simon


P.S. For those interested, if you'd like to participate please let me know, so I can add you to the Google Code project so you can edit the wiki (and eventually add code as well)
If there are enough people interested we could use a mailing list to discuss everything.

[aaahaaap]

I've replied on friday, is there a reason my reply doesn't appear/isn't approved (yet)?

[GTS]

Can't see it, sorry.

[aaahaaap]

Seems it has been approved! http://fsae.com/groupee_common/emoticons/icon_smile.gif

[GTS]

Originally posted by aaahaaap:
Not everybody has an ECU that has logging capabilities, and if it can its data has te be imported in the DAQ software (which get's us to the software-issue again http://fsae.com/groupee_common/emoticons/icon_wink.gif)

Deconstructing software formats and spitting out something useable is a good exercise to move your programming abilities up a notch. Give it a shot. It's not impossible/hard to write some code in MATLAB or whatever else to open a file, extract what data you need and spit things out in a relatively simple format (e.g. ASCII) or to use it in whatever code environment you ultimately choose to work in.

The comments with the logger - Auckland having one - I'd suggest that against the rules you need to have an honest look at what it'd cost you to bring a custom dash to market for the 5k run of cars you're essentially prototyping, and to fully appreciate/weigh up the associated design challenges with as much. Whilst I understand there's been changes to the costing rules since I competed a (long) while ago, practically I'd question the validity of building your own dash with minimal functions into a car when so many low-cost options exist that work so well, and give a good degree of flexibility in mounting, serviceability, etc. Remember - no smart engineer reinvents the wheel for the sake of it, and there's no shortage of work on an FSAE/FStudent project enough to allow 'for the sake of it' liberties.


Originally posted by aaahaaap:
It will probably be a lot harder than expected, but isn't that (almost) always the case?

I went ahead and wrote some things down to start the initial/requirements phase of the project, we'll see how far I/we can come.


Specifying the problem - this is precisely where I'd begin to open this up to a wider forum - lots of information, thoughts and experiences to share here. There are many DAQ packages in the competition that are hopelessly overspecified, there is a lot of ambiguity for teams new to or reconsidering the problem, and a very poor understanding of what's useful in a FSAE/FStudent-specific context.


Originally posted by aaahaaap:
I guess it would be smart to take sensor selection into consideration and speccing the requirements around the chosen sensors.


Again, collaboration - what do you need, how can it best be done at acceptable accuracy/repeatability with lowest cost? Work out what data you need. Then examine methods to acquire it and associated cost/compromise issues. If some teams were to assign a weighted 'importance' to what channels they acquire and pie chart that - and then dug out the total cost of those channels and repeated that same pie chart, they might get a good shock! (Let alone before it's compared as a net figure to the cost of their logger...)

Don't even discuss building a logger until you've got this sorted!

This thread would become much longer and a far more heated discussion if you went into what to acquire and how, but it would not be a wasted effort; it would help define a starting point. What you have at the moment ('let's build a logger') is a concept potentially defining a solution/phase of a project ('DAQ for FSAE/FStudent') for which the inputs/dependants are ill defined. This is poor engineering practice, avoid it.

My best regards to beautiful Amsterdam.

[JeffreyH]

Originally posted by GTS:
The comments with the logger - Auckland having one - I'd suggest that against the rules you need to have an honest look at what it'd cost you to bring a custom dash to market for the 5k run of cars you're essentially prototyping, and to fully appreciate/weigh up the associated design challenges with as much. Whilst I understand there's been changes to the costing rules since I competed a (long) while ago, practically I'd question the validity of building your own dash with minimal functions into a car when so many low-cost options exist that work so well, and give a good degree of flexibility in mounting, serviceability, etc. Remember - no smart engineer reinvents the wheel for the sake of it, and there's no shortage of work on an FSAE/FStudent project enough to allow 'for the sake of it' liberties.


I disagree - if you have some EEs on the team. It's not hard to build your own dash, and mounting options are then much easier. Like most embedded electronics, it takes a lot of time and testing, but it's certainly doable. We like it as it means we can mount it in the wheel. I always find it funny to see teams with ADL2s or similar datalogger/dash units with them taped face down somewhere on the car - most aftermarket dash units simply don't work in an FSAE car due to their size and profile. Hence we prefer to run our own custom dash, designed to fit in the wheel, with an EDL2 (no LCD/dash functions). It's probably been one of the most useful things we've added to the car so far. We've also yet to have it fail. It's not reinventing the wheel or adding unnecessary complexity - it's about adding a practical feature to the car which has proved its worth every single time the car goes out testing.

However, I don't really know if doing one as an open source project would work too well as every car is different. Our dash would be terrible if you wanted to mount it somewhere other than inside a wheel. Plus it has a whole lot of stuff on it which is specific to our ECU, DAQ and gear shifting system.

[GTS]

Originally posted by JeffreyH:
I disagree - if you have some EEs on the team. It's not hard to build your own dash, and mounting options are then much easier.

If you have EE's it's easier, sure (not all teams do). Mounting options really depend on what you've bought for a dash. Most are quite flexible whether you build or buy.

Can't stress it enough that it's important to view the project not just in the concept of building one car for a competition, but building one 'properly cost'd' prototype for a limited production run. Would you still build the dash if so? What does the dash need to do (not much, but what, specifically)? Are there other, more cost effective, commercially available options? Are there other more time effective projects your team member should spend their development time on?

I'm not suggesting it's a silly idea. To suggest it's to be done because 'it's not hard' and 'mounting options are then much easier' however puts forward a weak case for it in an engineering context.


Originally posted by JeffreyH:
I always find it funny to see teams with ADL2s or similar datalogger/dash units with them taped face down somewhere on the car - most aftermarket dash units simply don't work in an FSAE car due to their size and profile. Hence we prefer to run our own custom dash, designed to fit in the wheel, with an EDL2 (no LCD/dash functions). It's probably been one of the most useful things we've added to the car so far. We've also yet to have it fail.

Pulling an ADL/ADL2 up as an example of 'why build your own' is a bit of an extreme example - it's not an item particularly suited to FSAE/FStudent use (when there are other items that cost significantly less and work just fine). Bear in mind that some teams have these as they're bought as part of wider university research efforts, and some because MoTeC had the graces to bring out the ADL... then wait a while... then deny the EDL was ever coming... then release it (for which I've a few clients that are still bitter.)


Originally posted by JeffreyH:
It's not reinventing the wheel or adding unnecessary complexity - it's about adding a practical feature to the car which has proved its worth every single time the car goes out testing.

No doubt. The question is - having defined what the feature needs to do - are you using engineering design principles to meet your project specification in a manner best befitting your project intent? In that, does it need to be done indigenously? Are there other, better options? If not, how would you improve yours?

I think your dash is a nice achievement - however I can see a few limitations in your dash, but it's not me that's got to explain/justify it to the judges.


Originally posted by JeffreyH:
However, I don't really know if doing one as an open source project would work too well as every car is different.

'Open source' doesn't imply that every project using a given codebase/basic design should be identical.

It would, at the very least, open a basic design to wider criticism. Which is a good thing.


Originally posted by JeffreyH:
Plus it has a whole lot of stuff on it which is specific to our ECU, DAQ and gear shifting system.

Do you consider this feature/limitation consistent with 'a prototype vehicle for the non-professional, weekend, competition racer market' which 'your design firm will attempt to “sell” the design to a “corporation” that is considering the production of a competition vehicle. The challenge to the design team is to develop a prototype car that... which can be profitably marketed'?

I've got a few clients and colleagues having something to do with your target market that'd disagree.


Originally posted by JeffreyH:
Our dash would be terrible if you wanted to mount it somewhere other than inside a wheel.

What if one of your potential clients had that very intent?

[lozo]

GTS,
Unfortunately, I did not have sufficient time to carry out a full requirements analysis on the dash prior to the implementation stage. Some qualitative research was done, but not a significant amount of extra user studies. I should have done a "Glasgow style" questionaire in retropect, although I fear that that might be a waste of what little time we did have.



Can't stress it enough that it's important to view the project not just in the concept of building one car for a competition, but building one 'properly cost'd' prototype for a limited production run. Would you still build the dash if so? What does the dash need to do (not much, but what, specifically)? Are there other, more cost effective, commercially available options? Are there other more time effective projects your team member should spend their development time on?

I'm not suggesting it's a silly idea. To suggest it's to be done because 'it's not hard' and 'mounting options are then much easier' however puts forward a weak case for it in an engineering context.


The product statement of the dash and its main objective was to remove the laptop out of the equation during a typical race day. This is assuming that the user has done all his tuning, wiring and needs the dash only to troubleshoot issues that may have cropped up whilst driving. Having access to your battery voltage, water coolant temperature, and pretty much everything that can be sent through CANBus is extremely convenient in that manner. As the target market was the autocross racer, the aim was to make it usable, simple to understand and very much modular. The current solutions such as AIM's, PI’s Dash, Stack’s solutions are very much more pricy (even more pricy than what our dash finally cost – assuming a production run of approximately 100-200?) Show me a dash that doesn’t look like throwback to the 90s and costs less than USD$500 and maybe I might be convinced that I have started down the wrong track, however I have yet to find one.



Pulling an ADL/ADL2 up as an example of 'why build your own' is a bit of an extreme example - it's not an item particularly suited to FSAE/FStudent use (when there are other items that cost significantly less and work just fine). Bear in mind that some teams have these as they're bought as part of wider university research efforts, and some because MoTeC had the graces to bring out the ADL... then wait a while... then deny the EDL was ever coming... then release it (for which I've a few clients that are still bitter.)


The justification for the dash was to reduce the amount of effort required to troubleshoot and test the car and in our testing sessions it has served that purpose. Mounting was a non-functional requirement, but still a requirement. Its rather unfortunate that Motec has such as varying and confusing product range, however it is the way it is, and the dash conveniently happens to be on the ADL2.



No doubt. The question is - having defined what the feature needs to do - are you using engineering design principles to meet your project specification in a manner best befitting your project intent? In that, does it need to be done indigenously? Are there other, better options? If not, how would you improve yours?

Every system is bound to have its limitations, however, the functional requirements on which the dash was designed on were achieved, and whilst some of the nonfunctional requirements such as usability and configurability were not complete upon completion of that version of the dash, they were non-critical to the dash’s operation at the time.


'Open source' doesn't imply that every project using a given codebase/basic design should be identical.

It would, at the very least, open a basic design to wider criticism. Which is a good thing.

The project hardware is available on Google Code, and the code has yet to be put up because its not in a state where I’m happy for it to be made public. You are right about open critiquing of the dash though.


Do you consider this feature/limitation consistent with 'a prototype vehicle for the non-professional, weekend, competition racer market' which 'your design firm will attempt to “sell” the design to a “corporation” that is considering the production of a competition vehicle. The challenge to the design team is to develop a prototype car that... which can be profitably marketed'?

It very much depends on your definition of car. Does the prototype car incorporate the car electronics? The ECU/Datalogging package? Currently, whilst Jeffrey states that its vastly proprietary, the basic functions of the dash will work with any team sporting a RS232 data line or CANBus.


What if one of your potential clients had that very intent?

Are we selling the car, or the dash? If the dash was meant to be placed somewhere other than the wheel, a hardware redesign is not beyond the team. The software would essentially remain the same, and a minor redesign of the hardware would be done. But as far as the current dash is concerned, it was designed with the intent for it to be an OEM component of the car from the very start. If it was designed with the intention for it to be a standalone dash from the start then it would be done very differently.

Cheers!

[Moke]

Ah the old double whammy, the 'Build it or Buy it' argument and the 'Whats your market' argument.

Jeffery and Richie will be the first to agree that I give the dash a lot of shit (mostly as I had to make the wheel to fit the damn thing). However it is very useful for the weekend autocross racer as it means they can access all important data at the wheel without having to lug a laptop around and not have to even have a pit crew. And yes it was well justified in design and well received and we got 2nd last year in design between Stuttgart and UWA.

The rules for cost basically say the car costs under $25k, not where it should be spent. If a team wants $15k worth of shocks they must do everything else for $10k, if they want to put money into a dash/datalogger they can, just means less money 'available' elsewhere. And you are free to develop what you think will be the best car, that is why there are no two cars that are the same.

This open source datalogger could be viewed in the same way as the tire testing consortium, it will allow teams to access resources that otherwise might not be able too. Teams can opt to use it or not just as they can with the TTC.

[GTS]

Originally posted by lozo:
Unfortunately, I did not have sufficient time to carry out a full requirements analysis on the dash prior to the implementation stage. Some qualitative research was done, but not a significant amount of extra user studies. I should have done a "Glasgow style" questionaire in retropect, although I fear that that might be a waste of what little time we did have.

I'd shoot any student attempting a 'Glasgow style' questionnaire, though there are many known analytical approaches for design engineering issues, none of which involve opening the floor to fellow students with a broadly identical appreciation of a specification you're attempting to characterise.

Structured design engineering review isn't a waste of time, particularly when it's tight. Longest way is always a short cut.


Originally posted by lozo:
The product statement of the dash and its main objective was to remove the laptop out of the equation during a typical race day. This is assuming that the user has done all his tuning, wiring and needs the dash only to troubleshoot issues that may have cropped up whilst driving. Having access to your battery voltage, water coolant temperature, and pretty much everything that can be sent through CANBus is extremely convenient in that manner. As the target market was the autocross racer, the aim was to make it usable, simple to understand and very much modular. The current solutions such as AIM's, PI’s Dash, Stack’s solutions are very much more pricy (even more pricy than what our dash finally cost – assuming a production run of approximately 100-200?) Show me a dash that doesn’t look like throwback to the 90s and costs less than USD$500 and maybe I might be convinced that I have started down the wrong track, however I have yet to find one.

I'd suggest that you don't need an entire CAN stream though your dash - usual warning lights, RPM/shift light, lap time, that's really it. There are a few other things I've included previously, application dependent, not all of which are amenable to inclusion on your display. I'm a little curious as to the laptop reference; a battery voltage failure means the car won't move (let alone the dash won't work), a coolant system failure should have you out of the car rapidly (and away from a connected steering wheel). Use in debugging a concept is commendable, but I'd contend that the weekend autocrosser probably values his/her laptop and post analysis in that regard.

There's more than just functionality required for a marketable product, e.g. what kind of operating conditions your product can sustain, etc. This kind of engineering contributes to cost.

You'll get no reservation from me on Pi/MoTeC/Stack's efforts being overpriced, nor that there's nothing out there that's perfect. Solutions do exist <$500 though. 'Doesn’t look like throwback to the 90s' shouldn't be a project requirement. Many F1 steering wheel displays still run segmented LED's (as do many high-end motorsport projects) - for good reasons.


Originally posted by lozo:
The justification for the dash was to reduce the amount of effort required to troubleshoot and test the car and in our testing sessions it has served that purpose. Mounting was a non-functional requirement, but still a requirement. Its rather unfortunate that Motec has such as varying and confusing product range, however it is the way it is, and the dash conveniently happens to be on the ADL2.

That's a fair purpose to serve - though does it have a place on a debugged concept in production and intended use? I guess this brings you back to the basic 'what are we building a car for' question.

MoTeC has the MDD; a good concept though too costly for what it is.


Originally posted by lozo:
It very much depends on your definition of car. Does the prototype car incorporate the car electronics? The ECU/Datalogging package? Currently, whilst Jeffrey states that its vastly proprietary, the basic functions of the dash will work with any team sporting a RS232 data line or CANBus.

Glad to hear it's not proprietary. Sounds like this is a key piece of understanding to disseminate amongst your team; the validity of the project in the context of FSAE/FStudent is severely limited if you're constructing a complex piece of equipment with limited added value beyond market offerings, at a small cost saving - on top of which a potential client would have difficulty servicing or replacing with an item of preference. Put in that context, you may have something sellable. It's certainly a key point to communicate to anyone judging your design (or giving the project sh*t within your team).

If you can make a case for engineering your own nuts, bolts and washers, by all means, though appreciate that it's an even harder sell if your clients can't source their own spares by preference or as a backup...


Originally posted by lozo:
Are we selling the car, or the dash?... it was designed with the intent for it to be an OEM component of the car from the very start. If it was designed with the intention for it to be a standalone dash from the start then it would be done very differently.


You're selling a business case for a complete package, for which your design inputs need to stretch beyond personal intuitions and into potential market requirements... hence a structured design engineering review. If you've specified and designed well, and sold well, you're fine... sometimes the latter can compensate for deficiencies in the former! Furthermore there are many ways to skin a cat.

I'm not levelling any particular criticism at your dash, though owing to personal issues surrounding FSAE projects I did anticipate a quick response from your team . I really do quite like it. Design review for any project needs to be impersonal, however. You can have all the effort and good intention in the world and still be outdone by a competing project on a tenth the net expenditure on basis that it's fundamentally, holistically, a better design.

This bit part (Auckland dash) in this thread is however detracting from what the thread's about, and that's making good DAQ more accessible.

Good DAQ is not about troubleshooting debugging critical faults with a car. It's a development tool.

Hardware facilitates an ability to acquire data, but has no direct impact on the ability to develop anything useful with it.

I'd be keen to see teams contribute comment on:

- what needs to be acquired
- what analysis needs to be performed

To a degree, I believe the latter specifies the former. At any rate I'd be keen to see some discussion on it.

-GTS

[Falcon™]

I wanted to share an image of the gcld we had implemented on our dash.... http://upload.wikimedia.org/wikipedia/en/9/9b/God_ka_glcd.jpg

@JeffreyH I saw few pictures of the electronics on your car and just wanted to enquire if you had used the resettable fuses in conjuction with regular fuses.
thanks in advance

[JeffreyH]

Nicely done. Have you tested it in your car? My only concern would be whether that's visible enough for the driver. The big concern for our dash design was visibility - do you need parameter X to be present and/or large? Why not have a second menu of diagnostic info in small text... etc. Our experience is that drivers rarely notice anything on the dash at all - even warning LEDs have been overlooked at times.

Regarding resettable fuses, we've found them to be very reliable and don't use any conventional fuses on the car at all.

[Falcon™]

Yup we had implemented this in our vehicle for fsg09. Worked fine. The visibility was good (major credit to the backlight here). We also had three pages and buttons to scroll through them. A page for button testing was quite useful. As was your case the driver rarely used to have a look at the lcd but it was quite useful during the testing phase and we had long (really long) meetings with the driver to finalise on the display. Another thing that our last year's driver wanted was buttons instead of paddles for the gear changes. But this year we have decided to use paddles.

Originally posted by scott_rfr:
Here at Rutgers we have had our own data system for a while. Student designed boards and firmware on the boards.

As far as software goes we have always used Matlab. Over the years (espically the last two) a couple of us have wrote a ton of m-files to process the data. Our data collection software was written in VB and we just click an export button, select the m-file and its all done. Matlab has a lot of really great easy to use built in functions (fft, filtering, etc).

I would focus more on the hardware development and leave the software to matlab. You can write m-files so quick. Just getting the hardware to run reliably is a lot more work than you might think.

Scott
Thanks you for the post.

__________________
Watch Eclipse Online For Free (http://moviesonlinefree.biz)