Scripting Setup and the Camera + Serial Port Drivers
 

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: The camera quick start guide specifies the the PicSerialDrv.c as a required file. Furthermore, the PicSerialDrv.c specifies that : 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: 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 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.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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...

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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!

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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

Re: Scripting Setup and the Camera + Serial Port Drivers
 

Good Point

Re: Scripting Setup and the Camera + Serial Port Drivers
 

Hey,

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

Dan

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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

Thank you for your prompt reply,

Dan

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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

Re: Scripting Setup and the Camera + Serial Port Drivers
 

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

Re: Scripting Setup and the Camera + Serial Port Drivers
 

Wow, I never even thought to daisy chain processors using the serial port.

*achieves the "aha!" moment*

Re: Scripting Setup and the Camera + Serial Port Drivers
 

Yes, this a bit of a pain. I hope to work this out with IFI in the near future.

-Kevin

Re: Scripting Setup and the Camera + Serial Port Drivers
 

These multiprocessor systems sound very familar, a la 2003. In 2003, the Basic Stamp 2SX which we used was ill-suited to working with complex feedback systems and autonomous mode, so hundreds of various kludges were put together to all increased speed and advanced features.

A few notes of advice with regard to multiprocessor configurations.

First, debugging a system with one microcontroller is hard. Debugging one with two processors is 4 times as hard. Three is 9 times as hard and so on and on. Unless you have very very good reasons for using them, do not bother. You need a lot more electrical and electronic skill than is the norm to make such things work.

If you are interfacing a Basic Stamp to the PIC in the IFI blackbox, the BS has 2 ports which can be used for serial communication very easily, the two data pins of the programming port. These can be linked to the serial port of PIC and Mr.Watson's serial driver (and PBASIC serin/serout) can be used for data transfer. Remember, the Stamp is not capable of working at high serial baud rates!

If you want to go way overboard in terms of power (ie you have at least ten electronics and programming experts on the team), you could look into the line of Rabbit microcontrollers. They feature Ethernet connectivity and are very easy to use, if you can convince the manufacturers to donate the programming software ($395). I once used a Rabbit, 2002 FIRST controller, a relay, and a car battery to make a toaster with a webserver on board. Truly useful tools, those Rabbits.

If you add a second processor to just service interrupts, an older PIC16 should be able to do just fine, with the serial code from Mr.Watson.

But if you want to use some more sophisticated electronics to add features, one more option is available. Connect the IFI controller and the aux microcontroller to 74LS138 decoder chips. Then connect the output lines of the decoders to 8 AND gates (8 gates per decoder line). This system allows you to build a rudimentary bus between the processors, on which peripherals (sensors, etc) can be connected. We used this arrangement in 2003 (with tristate gates rather than AND gates) and it worked great.

And lastly, Good luck!

Re: Scripting Setup and the Camera + Serial Port Drivers
 

Thank you,

The third option, this would be using another PIC 16 or 18?

Re: Scripting Setup and the Camera + Serial Port Drivers
 

If one really looks into the code, you can see that usr_SerialDrv.c and PicSerialDrv.c are nearly identical (IFI alludes to this in their FAQ). The PicSerialDrv.c was used for the DDT and later changed for the “user_” naming convention (according to IFI’s tech support). These are just driver templates and give the user the ability to handle his own read buffering if need be. The callback function (located in the CheckUartInts routine) is primarily used for building your own state machines based on a unique device protocol (like the Breaker Panel Board or the CMU2 camera).

Serial_ports.c provides read buffering on either port. It will require you to use a parser to parse incoming data and sometimes this takes more resources than just using a simple state machine to record the incoming data and set a flag indicating that the data is available.

Each driver has it’s own trade offs and that’s were the fun begins.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

Just sit in a loop and while data is in the buffer, send the data to your state machine a byte at a time.

-Kevin

Re: Scripting Setup and the Camera + Serial Port Drivers
 

To obtain RS232 Signal levels from the TTL port, what do you guys think of the MAX232 IC? I have never used it, but have heard good things about it.

Re: Scripting Setup and the Camera + Serial Port Drivers
 

white on interrutps.
http://www.ifirobotics.com/docs/time...004-jan-14.pdf

gc