Scripting Setup and the Camera + Serial Port Drivers

[CJO]

I have not had a chance to e-mail Mr. Watson yet, however, trying to integrate the Camera control system into the scripting code is becoming a real nightmare. The difficulty is in the serial port driver. The problem as I see it is thus:

1) There are really three different serial port drivers, they are:

a) usr_SerialDrv.c

b) serial_ports.c

c) PicSerialDrv.c

"a" is the defaut FRC driver, no need to worry about it just delete it. "b" is Mr. Watson's serial port driver, allowing LCD screens and printf functions from the FRC controller. "c" is the serial port driver which comes with the camera. "b" and "c" really do most of the same things, put are not intrinsically compatible. My immediate solution is to call some parts of "b" from within "c," thereby leaving the camera driver intact and just adding certain functionality from the seril ports driver. Problem is, in even limited testing on the controller it has been doing some really weird things.

2) What the is the "Dynamic Debug Tool?" This phrase was included in the camera software. In the PicSerialDrv.c file there was this comment:

This file contains an unsupported serial device driver for the 18F8520 micro. It was designed to be used with the Dynamic Debug Tool (DDT). The DDT is now apart of the IFI Loader (ver 1.8 or later) under the 'Options' menu. The DDT can be used to directly read and modify memory locations and registers of the user processor dynamically.

The camera quick start guide specifies the the PicSerialDrv.c as a required file. Furthermore, the PicSerialDrv.c specifies that :

You can put your own callback routine inside CheckUartInts. This will allow you to parse data from another device in real time.

So, in fact, this is where I called Mr. Watsons code. The problem is, that the two drivers seem to be trying to do different things with the ports.

3) While trying to use interrupts (a switch attached to one of the digital ports) and the camera software at the same time, the controller keeps resetting itself, for no reason which I can identify.

4) Building on #3, the camera has what is esentially a state machine servicer (for lack of a better term) built into it; that is, calling camera_track_update() will tell you whether or not the camera has been successful in updating and tracking to a new position. To my mind, this should be handled almost like an interrupt, that is, when it returns 1, the camera track code is executed, but in the code provided, it sits in user_routines_fast in the sutonomous section, and simply says:

if(camera_track_update()==1)
tracking = 1;
trakcing code
else
tracking = 0;

So, if I understand it correctly, what it is really doing is sitting in the autonomous space and waiting for an update. Is this really the best way to do this?

5) Finally, the camera needs to be calibrated before use. This is done by hooking a PC up to the camera and running a JAVA script program to get exposure values. You then have to send these values to the camera in "User_Initialization()" by including the line

camera_init ( yellow exposure, green exposure, red exposure )

The drawback to this is that it requires re-compiling and loading the code. Is there a way to set it so that you could use onboard switches to change the state of the exposure values without having to re-load the code? My only thouught so far was to have a pair of pushbuttons attached to the operator interface, and after pressing some button combination, the display byte gets set to the currently selected value and then the two buttons increment it up and down.

[Mike Betts]

Originally Posted by CJO

...trying to integrate the Camera control system into the scripting code is becoming a real nightmare. The difficulty is in the serial port driver...

In defense of Kevin, First, Woody, et al, I expected nothing less. Engineering is all about trade offs. You can design yor system to do A, B or C easily. Combining A abd C or A and B or B and C requires some effort. Combining A, B and C should be near impossible.

If you try to use every motor and actuator in the kit, you will be about 60 pounds overwieight.

Set your priorities. What does this robot NEED to do? Now look at options. What will give you a winning design?

To quote an Eagle: Get over it...

[CJO]

No, no . . .

Kevin Watson has basically saved our program for the past two years, I am not trying to imply that he or FIRST has fallen down on the job in any way, rather, I am saying that there is a big challenge for the teams to overcome.

My post was not to complain about what is, but rather to elicit help for the serial driver problem, which frankly, has me stumped.

[Mike Betts]

Likewise, so am I... It is one of the reasons I posted on another thread when people said that they had made the software too easy...

Resolving I/O and interrupts will also be a challenge for the team who wants to do everything...

Let the mayhem begin!

[CJO]

Another question: The rules allow us to have secondary processors. So could you have a second processor which does nothing but service interrupts, and then passes bytes along to the FRC controller in a TTL type format.

[Mike Betts]

Originally Posted by CJO

Another question: The rules allow us to have secondary processors. So could you have a second processor which does nothing but service interrupts, and then passes bytes along to the FRC controller in a TTL type format.

Yes. Although timing and interrupt latency will be issues....

[CJO]

Good Point

[DanDon]

Hey,

Can someone point me to a tutorial regarding interrupts, and their implementation? I would much appreciate it, thanks in advance.

Dan

[CJO]

I think that for the IFI controller, your best bet would be to go to www.kevin.org/frc, download the code, and read through the lengthy explanation at the beginning of the interrupts.c file. Also, just play around with the code a little, it will both give you a sens of interrupts, and show you how they work on the IFI controller.

[DanDon]

Originally Posted by CJO

I think that for the IFI controller, your best bet would be to go to www.kevin.org/frc, download the code, and read through the lengthy explanation at the beginning of the interrupts.c file. Also, just play around with the code a little, it will both give you a sens of interrupts, and show you how they work on the IFI controller.

Thanks CJO, just to supplement that, can you recommend any whitepapers on interrupts in general?

Thank you for your prompt reply,

Dan

[CJO]

I cannot think of anything specific, however, the C tutorial on the FIRST website is quite good, it discusses programming in C for machines (read robots) in some detail. In addition, there is a 900+ page user manual on the PIC18 microprocessor (the one in the IFI controller) I would not reccomed this as recreational reading, however, I have never gone to it with a specific question and come away emptyhanded.

[CJO]

To further that reply, check out the manual on the IFI website (www.ifirobotics.com) and on the Microchip website (www.microchip.com).

I have a mirror of the IFI documents section. If you have trouble finding what you need I can look through my dump.

[DanDon]

Again, thank you for your reply. I will do as you say and read the tutorial on the FIRST site, though I think i might be able to skip chunks of it, and I will reference the PIC Manual as needed.

Again, thanks,

Dan

[prograid]

Check out the programming whitepapers on this site. There's one called Interrupts for Dummies. Excellent

[Kevin Watson]

Originally Posted by CJO

Another question: The rules allow us to have secondary processors. So could you have a second processor which does nothing but service interrupts, and then passes bytes along to the FRC controller in a TTL type format.

Yes! I would love to see a team(s) do this. This is one of the reasons I wrote the serial driver. You should be able to just hook up the TTL serial ports (Rx->Tx, Tx->Rx, Gnd->Gnd) and pass data between the computers. I specifically had the EDU-RC in mind for this.

-Kevin