Quote:
Originally Posted by McTimson
In its' current state, the microprocessor stores the data on an SD card, and then you have to plug the SD card into a computer so Matlab can read it, correct? Would it be possible to output the data directly to a PC/laptop via Matlab rather than storing it on an SD card, in order to have real-time display of the data?
|
Absolutely. That's one of the eventual goals in the optimal control problem. With this model, we can estimate parameters online, such as mass changes (passengers getting in/out), air resistance changes (windows open/closed), rolling resistance changes (tire pressure a little low), etc...
What we're missing right now is the time to program the observer. A 17x17 matrix is not chump change for a microcontroller, especially without floating point. Even on my i7 processor, the Matlab calculations only go 10 times faster than real time. There's a lot of optimizing that can be done, though, so I'm guessing that a small DSP (or even FPGA) could do the work. It's certain, though, that the 8MHz AVR can't at that sample rate.
Quote:
Originally Posted by McTimson
What exactly are the torque and efficiency being mapped against in figures 2 and 3 of the pdf?
|
Time. You're the second person to ask that, so clearly I need to do a better job of presenting those graphs. I'll update the caption once I'm back at work.
Quote:
Originally Posted by McTimson
Since the data for the different methods is so consistent, why is it still preferred to keep the GPS in the system? Was the data with GPS and DEM considered more accurate?
Do you have a source for the GPS units? I took a quick look for the FV-M8, but only found one for around $100.
|
Multiple reasons: 1) For the highest precision results, we want to use as much data as possible. 2) With the GPS, we can continually update the estimation of road elevation and grade, improving past and future results as we converge toward the true road parameter values. 3) We need the GPS anyway for optimal control. Of course, that being said, it bears repeating that you don't strictly need the GPS and DEM if you want to apply the observer. In fact, the observer becomes much simpler, and might even become small enough to be practical in real-time on a 8MHz AVR. 4) Most importantly, the GPS gives us a very good time fix. Otherwise, you're kind of guessing in the dark when you try to fuse the various asynchronous data, and that is NOT good.
For the FV-M8, I have a source in Germany for less than 50E, and I remember seeing a few in America for under $60. Anyway, I wouldn't use that particular model anymore. The u-blox line of GPSes are far more interesting. For instance, the Falcom FSA03 is cheap, and has a host of features that are good for these kind of embedded applications (For instance, the FSA03 has very advanced firmware support for energy savings, while the FV-M8 has nothing at all.)