cougar controller automated unit testing
 

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?

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.

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?

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.

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

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?

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.

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.

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:
http://www.4qdtec.com/Automob/diags/TachDwell.png

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

Update, VMLAB refued to even start on my XP box. I'm about ready to say screw this software emulation testing stuff I think. Unless someone else wants to look at simulavr or something and has a glowing report, I'm not putting any faith in the software only simulators.

I've just finished building a basic test board (uC, rs232, a couple of pots, buttons, leds ...).
For now I'm going to test the serial communication part for the controller on this one. Simple interrupt based transmit only, sending 16bit integers for temperature, pwm and pedal values. There will be no bcd conversion on the controller, I'll just write a dedicated client to receive, convert display and log this data.

Ok, can of worms but ok. Adam was messing around with client stuff here: http://ecomodder.com/forum/showthrea...tml#post106367 , I was rooting for java so anyone could use it, have used rxtx a lot Deploying JAVA with RXTX - Rxtx


just for example, here is a sample java prog that sends a character version of the serial bits to stdout and a hex converted version to stderr (9600, com2)

And here is the result: Trevor has written an awt java app, I modified it a bit to work on my linux (with rxtxcomm), and we have a simple java client for the controller. The nice graphic representation of data to follow ...

L.E.: the current value is fake since my setup has the input pin for the current sensor not connected ... The PWM follows very nicely the change in Throttle :)

Awesome! But I think 1701 for current might be a bit optimistic? :p

well ... It looks like my idea of padding the transmissions with a pair of 0xFF is not going to work in all cases: when i slowly increase the throttle I confuse the algorithm at the moment the throttle value is exactly 0xFF and for a brief moment I get really funny values on my screen :)


l.e.: solution was simple using 0xFD 0xFF sync sequence should be safe. Actually any non identical 2 values above 0x02 each would work for our values (max 511 for all that we read)

Fixed the bug. Attached is the client program running on windows this time.

I've uploaded the sources, the ready-to-run java ".jar" file and the binary drivers for windows, linux and mac to a subdirectory in svn for other people to use.

Jar file here: /trunk/javaclient/MotorClient.jar - Open ReVolt - Trac

Drivers: /trunk/javaclient/MotorClient/lib - Open ReVolt - Trac

... and the relevant code from the avr:

Trevor is making good progress ... He sent me the version with graphic representation of the loged values and it works really nice!

Java client
 

Charlie pointed out a few other things to clean this up a little.

my task list
-adjustable scaling on the chart (or fixed from 0 - 512)
-writing to csv
-change the end of packet suffix to FF F0 ( your code above looks like F0FF?)

the graphing is working pretty well, glitches every once in a while....not sure why, if its because of my pic or a software bug.

Correct! 0xF0 0xFF. Already changed that in the java code in the svn.

You guys are awesome! Keep it up!

Is the PWM duty going to be returned with a value of 0 to 100 ......percent duty cycle

no point having the scale go to 512 if its only ever going to go to 100...

Cheers,

Trevor

Right now the pwm duty has a resolution of 512, but the accuracy is only maybe 7 or 8 bits. I'm planning on increasing the accuracy (since there's now time because there are no while(); stuff during A/D conversions. So, if the resolution is greater than 8 bits, will that be a problem with the software that's assuming 8 bits? Or will there be a conversion to 8 bit, or should I cut it out with the 9 bit resolution stuff?

The software now is sending/receiving 16 bit values. Values up to 15 bit will work since we need a sync bit. With the sync values we are using now (0xF0) you can go up to 12bit before we need to change that :)

ah, ok, I understand.

ya the client is just the slave......it can do anything you need.

that being said do we want to translate that into a % duty cycle on the client side?

Awesome work guys! Keep it up.
I will be watching this with interest, could be very interesting to have this running on board.

Writing to CSV
 

I think I have a few more things nailed down.

-write to file is done.....writes to csv (Comma delimited)
-Auto Scale or fixed 0-512
-Cleaned some things up a little
-add some more comments.
-Changed suffix to match Charlies change...


Write to File, eg. Graph in Excel

Cheers,

Trevor