cougar controller testing

[dcb]

So, how do you "refactor" code, and be reasonably sure you didn't break something?

Conventional methods utilize automated unit testing, and developers write a bunch of code to analize the core code. Then when you make a change and before you inflict it on everyone else, you run the new code against these automated tests and see if anything strange happens.

Ok, so that's fine for like a desktop or server program, no additional hardware needed, just lots of test code to cover lots of scenarios. But what about an embedded project?

Well, the answer is (IMHO) that the developers need to have at their disposal a complimentary bit of hardware. With the guino I use another atmega168 that generates signals, and validate the on screen displays.

For this project maybe it makes sense to do something similiar, have an atmega that simulates current,throttle,temp,overcurrent signals and monitors the pwm output (and possibly the uart output) to ensure that it still looks right.

But it means we have to build it.

Thoughts?

[dlaing]

Well I agree that unit tests would be ideal. Using a duino would certainly work to run the tests, but that would mean another platform for all testers (who don't have an EV.) Course a duino is much cheaper than an EV.

Does the dev environment have nice simulation features? With only 3 inputs that is probably an easier way of testing things.

[dcb]

avrstudio has some simulation built in, that accepts "stimuli" files and does logging. I like avrstudio but it is windows only It looks like the eclipse folks have a couple simulator options too.

But by the time it is all sorted, a $4 chip with custom testing application on it for testing on real hardware doesn't seem so bad. And it could be independant of the actual development environment (load latest test hex) so arduino might be a good choice actually, just for the test device.

Would the coders be willing to test on some inexpensive hardware before checking in? Would they be willing to write new tests when new code is written or bugs are found?

[slurryguy]

Testing is a VERY appropriate discussion.

However, I had the impression that Paul's efforts are intended for this to be a Do-It-Yourself project. Creating a microprocessor controlled unit tester seems more appropriate for someone looking to start production of the controller.

I personally have no problem with someone starting a controller business. Go for it. Everyone should keep in mind that the project just jumped from DIY to commercial product when that decision is made.


I would be extremely interested in an appropriate testing methodology for a DIY builder. What sections of the controller could be tested seperately and how? It would be nice for someone that does not have Electrical Engineering background to be able to test most of their home built controller long before ever inserting it into a car.

It would also be nice if there were a testing procedure that would help prevent a DIY builder from incinerating a pile of expensive parts simply because they got one connection wrong while building it. An appropriate DIY testing flow chart would test things such that a builder could insert the expensive components last, and with confidence that they were not going to give off smoke signals.


Automated Unit testing sounds interesting, feel free to discuss it, but let's discuss practical DIY testing also.

[dcb]

Originally Posted by slurryguy

Automated Unit testing sounds interesting, feel free to discuss it, but let's discuss practical DIY testing also.

Absolutely. Just FYI, how I handled this was to create a table of ohm measurements at key points so that others could (after they built the device) do some sanity testing that they were in the ballpark and were not going to cause serious harm to the vehicle.
Mpguino tests - EcoModder

[dcb]

Originally Posted by MPaulHolmes

EDIT: dcb, do you mean tested in the car?

Well, I didn't mean that, but ideally ya would. I was just thinking of another atmega that actually generated voltages for throttle/current/etc adc pins and looked at the output (pwm and maybe uart). Maybe it's overkill, I dunno. The development cycle here isn't clear to me either though, and people making changes ideally would have some way of testing those changes as well as checking for unintended side effects.

But since you are using avrstudio, maybe we should try and standardize on that for now and play with the stimulus and log files a bit anyway. So that if you have "refactored" the code, the resulting log file should look pretty much identical before and after the code changes given the same stimulus file.

So are any potential developers allergic to avrstudio?

[wolfraven]

I suppose I should be pouring over all of the coding tutorials I can and learning with every free moment at my disposal, but since my actual time to work on random projects is somewhat limited, I think I'll keep dropping my $0.02 in wherever I feel it may be of use. Early in the development in Paul's motor controller, he actually created his own tester, at least for the control section. I don't remember what page it was on, or how long ago...but the little blinking light tester from back then gave me an idea with the current problem... Basically, since you're only testing the control section, you would be using substantially lower amounts of voltage etc...so you COULD probably hook it up to another controller to test it for variables like that...or do what's already proven to work, like was done with the bike/light motor controller and just scale it back to the point that it drove say...a tiny motor (i have a ton of little dc motors from things...) and you could probably simulate the rest of it through either the inputs and doing things that would otherwise be drastic to accomplish with a whole EV, like making it NOT go...I'm sure everyone involved with this that currently has an EV would have to tie their ride off to a stump, but with a scaled back and essentially free tiny motor, with the parameters appropriately scaled back (tiny motor, remember?) it wouldn't be very difficult to get those things into appropriate troubles. Just my idea, though, and I'm sure there's another way of doing it...isn't there a virtual machine setup that could run this code as if it were the controller? But either a mini-motor controller or another waaay tiny light blinker driver to test that it works sounds like a good idea to me.

[MPaulHolmes]

Originally Posted by dcb

Well, the answer is (IMHO) that the developers need to have at their disposal a complimentary bit of hardware. With the guino I use another atmega168 that generates signals, and validate the on screen displays.

For this project maybe it makes sense to do something similiar, have an atmega that simulates current,throttle,temp,overcurrent signals and monitors the pwm output (and possibly the uart output) to ensure that it still looks right.

That's a really good idea. I've never heard of such a thing. How do you simulate continuously varying signals like throttle, current, and temperature using an ATMega? Does the ATMega168 have D/A converters? I would love something like that. What an awesome idea. You could run a program that tests everything, and then check the output! Why didn't I think of that!? I'd be happy to help with that.

[dcb]

Thanks I just do digital signals currently, here is the first prototype: http://ecomodder.com/forum/showthrea...html#post32055

But converting a duty cycle or a frequency to a voltage isn't real hard. It is basically what a tach/dwell meter does:

[dcb]

So software simulation is a bust in avrstudio, it only does 1s and 0s on the pins and we need analog voltage simulation for testing.

I'm gonna take Motor_Controls suggestion and look at the free version of vmlab next as a possible software test framework:
Download VMLAB