Questions on timers/simulator

[sscanf]

Hi,

My name is Dan Rasmussen and I'm one of the new programmers for team 61 (Corey Schalck, an associate of mine, is the oter programmer for team 61 but in the same boat I am). I was an FLL coach and was asked a loaded question the Blackstone Valley FLL tournament in November (do you know how to program in C?). So here I am.

I have years of experience in writing C code (I wrote C exclusively from 1988 to 1993, lots of C++ after that, now using java) but I'm fairly new to PIC programming. I have dabbled in PIC assembler using MPLAB and GPASM as well as JAL and OOPIC. I have downloaded and compiled the default code for the full sized robot in MPLAB/C18 (note: I had to add a #define _FRC_BOARD to user_routines.c to get it to compile).

I seem to be finding my way around the default code (full robot controller) which is well commented but would like to hear about best practices for dead reckoning using timed operations. For example, I see that Process_Data_From_Master_uP is called every 26.2 ms. I could put a static counter in there and use it for timed operations or are polled/interrupt driven timers the only way to go?

Finally, I spoke to Mike Norton, the coach, last night and he told me that in previous years he was able to use a robot simulator against the compiled code that would give him a visual indication of the robot movement and pin state. I haven't tried the MPLAB sim but I have a feeling that it will fall short. Maybe there is something in the FIRST kit that I need (I only have the MPLAB/C18 downloaded from Microchip). Am I missing something if I only have the downloads from Microchip?

Thanks for any help.

Dan

[Jeremy_Mc]

We did dead reckoning last year, and as much as I advise against it, it IS the easiest (and typically fastest moving) way to go...

We had to run actual simulations As in, we test it with the robot and if it goes psycho we have to jump on top of it and cut the power. I'm sure there are more effective methods of testing it, but to be sure that it will work in the real world I would suggest your main testing tool be a piece of a field (you just need a space that's marked off with tape to signify field structures) and your robot.

(Side note: They DID give us the code for the IR beacon/sensors this year so I would really advise you take advantage of what's there...)

[Edit: The program he's referring to was RoboEmu by Rob Bayer. It ran PBASIC code, but I'm not sure he'll be making one for the C controller this year...]

[Mike Betts]

Dan,

Your team should have received a CD with their EduBot last fall. It has a slightly modified MPLAB and C18 that we are using.

The timing of given in the default code is dynamic and not good for precise timing. Use a timer interrupt (see http://www.chiefdelphi.com/forums/sh...ad.php?t=22879 and associated references for more information) for best results.

[WizardOfAz]

Timers: I haven't done it yet, but there is information about how to use the timers (see prior post). I think it's the way to go, and we will probably create an autonomous mode environment that allows time driven elements by using one of the on-chip timers.

Simulation: look at the RoboEmu work that Rob Bayer did for the stamp RCs, and he is working on a version for the current RC. I don't know when it will be ready, but RoboEmu was extremely useful last year. There was a graphical input system for pushing the joystick and buttons, and graphical output showing drive levels on PWMs.

MPLAP SIM: I find it tedious and difficult to use. It knows nothing about RC i/o and the master/user processor setup, so getting inputs into it is a challenge (somebody who's figured it out please tell me I'm wrong). And I couldn't find any way to get it to display outputs other than it's variable watch feature. No printf display window or anthing like that. It's somewhat useful for testing/debugging functions in isolation, but not for simulating high level robot stimulus/response.

EDURC - perhaps the best way to test and debug code is to use a real RC. The EDURC is reasonably cheap, so your team could maybe afford to have a couple of them for programmer use. At least you can get a printf window that way, though no breakpoints or single step.

An alternative: we constructed an environment using another C IDE. In our case we used lcc but any good C IDE would work as well. The attraction to lcc is that it's free for non-commercial use and reasonably small and simple to install (compared to gcc). Comes from Univ of Virginia. The debugger is pretty good, breakpoints, single step, step into/over functions, watch variables, and so on. Anyway, we built a top level C program that reads an input file of a time sequence of joystick values and switch settings, runs the C code that will eventually be in the FRC, and writes the inputs and resulting outputs to another file. You can then read the output file to see if the behavior is as expected. Our environment is very specific to a prototype we built in the fall, so wouldn't directly meet the needs of any other robot. It is also incomplete - there are many things it does not simulate and we add to it almost daily to meet changing needs. But it could serve as a starting point if anybody's interested.

Bill

[sscanf]

Hmmm... I'm not aware if we have the edu robot kit. I had assumed that it was for an alternate competition but I now realize it is for learning/prototyping/debug. I'll have to check with my team.

Because I am working remotely, I'm concerned about the long code/test/fix cycle. The RoboEmu would be nice as would be the edu kit. It seems that we will have to make due with the test driver appoach mentioned by Bill.

Are there many programmers in the same boat as us (i.e. for the programmers not to be local to the team)?

Dan

[Mark McLeod]

Originally Posted by sscanf

Hmmm... I'm not aware if we have the edu robot kit. I had assumed that it was for an alternate competition but I now realize it is for learning/prototyping/debug. I'll have to check with my team.

Dan

The EDU controller is also necessary to drive the IR beacon for your test field.
If you can get it to develop the basic code the team will need it back if they use the IR sensors. Of course, if you don't get it then they won't be using the IR sensors I suppose.

I found it very useful in developing and testing a training series of various autonomous styles, filters, and sensor examples. I can email them if you think they'd help you.

[Steven Carmain]

Originally Posted by WizardOfAz

EDURC - perhaps the best way to test and debug code is to use a real RC. The EDURC is reasonably cheap, so your team could maybe afford to have a couple of them for programmer use. At least you can get a printf window that way, though no breakpoints or single step.

The EDURC is not compatible with the full controller, though. They are configured different including different pinouts for switches and no OI to play with either.