New Infrared Remote Control Software

[Kevin Watson]

If you're using my 2008 code and are in need of a new solution for IR remote control, I've created add on code that will do all the waveform processing on your robot controller. The only external component needed is a $2 Vishay IR sensor, which can be purchased at many distributors like Digikey, Newark, etc. As always, please post here if you find a bug in the code or documentation, or just find a fun use for the code outside of the 2008 game. Here's the link: http://kevin.org/frc/ifi_ir_sensor.zip.

-Kevin

[billbo911]

This is an example of what Kevin's IR code can do. This code was originally written for Kevin's 2008 IFI alternative code. With a little reading and understanding of how it was written, I have munched it into my Vex code. If I can munch this into Vex code, you can easily munch it into the default IFI code. As you can see from the picture I am using a Sony DVD controller. If you look closely at the laptop screen, you can see that the address and command number are those for the number four key when using the Sony SIRC protocol.
The process of munching this code into Vex took me approximately one half hour. Therefore I'm assuming that the process of munching this code into the IFI default code would take approximately the same time. If you attempt to put this code into cabins 2008 code, it should only take you about 10 minutes. Please look at the picture below for a visual representation of how the code works. As you can see, it is a complete replacement for the IR board, and thus, is way more stable. Basically this becomes a single component replacement for the entire IR board. The component is a simple Vishay IR receiver, similar to those in the 2004 kit of parts.

[Joohoo]

Ok thank you for putting this out there.
Now a quick yet important question, I see that in your documentation you are refering to teleop.c and other files that are in the new code for the 3.0 compiler. I know where those locations translate to, but do you know or anyone know if this works with the code for the 2.4 compiler?

[billbo911]

Originally Posted by Joohoo

I know where those locations translate to, but do you know or anyone know if this works with the code for the 2.4 compiler?

I believe I can answer this. The Vex uses the 2.4 compiler and MPLAB version 7.4, exactly the same as the code versions in the kit of parts.
To get this to work properly, you will also need to integrate Kevin's "encoder" code from his website. This will allow the IR sensor to be sampled properly. If you are already using encoders on your robot you may have done this.

The next thing you'll have to do is to slightly modify Kevin's instructions as to how to integrate the IR code. When his instructions tell you to modify the line in encoder.c where it calls the IR's interrupt channel ISR, you will have to do this in user_routines_fast.c. You will also have to comment out the call to "#include ifi_frc.c" and add in the "#include ifi.aliases.h" and "#include ifi_default.h".

I'm certain I have forgotten one or two minor points, but I think the most essential parts have been covered.

Kevin if you have any additional comments, please add them.

[marccenter]

Can you post the VEX code? Does this new proposal eliminate "jamming" associated with two IR's being active at the same time?

[billbo911]

Originally Posted by marccenter

Can you post the VEX code? Does this new proposal eliminate "jamming" associated with two IR's being active at the same time?

I can not post my code because it tightly integrates Kevin's ADC, ENCODER, GYRO and IR functions. I do not have permission to repost Kevin's work. If I strip out Kevin's files, the code would not make any sense. If Kevin releases me to post it, I will get it up as quickly as possible.

As for the elimination of jamming, no. Some form of shielding may help. The best thing you can do to prevent that is to work with your Alliance partners to come up with a strategy that will prevent it.

[Kevin Watson]

Originally Posted by billbo911

I can not post my code because it tightly integrates Kevin's ADC, ENCODER, GYRO and IR functions. I do not have permission to repost Kevin's work. If I strip out Kevin's files, the code would not make any sense. If Kevin releases me to post it, I will get it up as quickly as possible.

Yes, I realize it may seem strange to give away software, but ask people to not make it available publicly on the 'net. My reasoning is that I want one public source of my code so that I don't end up burning up a lot of time helping teams fix bugs intoduced by third parties. It would also weaken my copyright if I allowed others to publicly post my code elsewhere. With that said, I have no problems with people occasionally e-mailing code to one another as long as it's done for educational purposes.

-Kevin

[Tom Bottiglieri]

Apparently I cannot access kevin.org as it is a "personal" site.

Can anyone tell me what this code is doing in terms of processor tax (interrupts, timers, heavy code)? It seems like something that I would like to integrate to take out the IR middle man, but we are already pushing the RC pretty far. (I chose readability and re-usability over a clean stack.. oh well)

[Kevin Watson]

Originally Posted by Tom Bottiglieri

Apparently I cannot access kevin.org as it is a "personal" site.

Can anyone tell me what this code is doing in terms of processor tax (interrupts, timers, heavy code)? It seems like something that I would like to integrate to take out the IR middle man, but we are already pushing the RC pretty far. (I chose readability and re-usability over a clean stack.. oh well)

The tax is pretty light. The ISR uses a timer to calculate the pulse width then uses a simple algorithm to build the 12-bit command word. Send me an e-mail and I'll reply with the code.

-Kevin

[chaoticprout]

Tested ir_sensor with the 3.0 code last weekend, worked perfectly. Thanks for the solution Kevin.

[SL8]

Kevin,
Is there some way that we can implement your code for IR without using your code?

I only modified the default code in MPLab and the created the same effects in easyC.

If need be, I may end up using your code, but I was wondering if we would only have to implement Specific parts?
-Jesus

[neoshaakti]

Originally Posted by billbo911

This is an example of what Kevin's IR code can do. This code was originally written for Kevin's 2008 IFI alternative code. With a little reading and understanding of how it was written, I have munched it into my Vex code. If I can munch this into Vex code, you can easily munch it into the default IFI code. As you can see from the picture I am using a Sony DVD controller. If you look closely at the laptop screen, you can see that the address and command number are those for the number four key when using the Sony SIRC protocol.
The process of munching this code into Vex took me approximately one half hour. Therefore I'm assuming that the process of munching this code into the IFI default code would take approximately the same time. If you attempt to put this code into cabins 2008 code, it should only take you about 10 minutes. Please look at the picture below for a visual representation of how the code works. As you can see, it is a complete replacement for the IR board, and thus, is way more stable. Basically this becomes a single component replacement for the entire IR board. The component is a simple Vishay IR receiver, similar to those in the 2004 kit of parts.

correct me if I am wrong, but isnt that IR receiver the same kind that is locating in any computer mouse?
I know that if you are using a mouse with a ball in it, when the ball turns and moves it spins a shaft. On the end of the shaft there is a disk with usually 36 slits so that an IR beam can be picked up by an IR receiver to determine the movement of the mouse.
I have a rough understanding...
yea

-Neel

[billbo911]

Originally Posted by neoshaakti

correct me if I am wrong, but isnt that IR receiver the same kind that is locating in any computer mouse?
I know that if you are using a mouse with a ball in it, when the ball turns and moves it spins a shaft. On the end of the shaft there is a disk with usually 36 slits so that an IR beam can be picked up by an IR receiver to determine the movement of the mouse.
I have a rough understanding...
yea

-Neel

Good question!

Honestly Neel, I haven't looked closely enough at the inside of a mouse to answer that question. I think your concept is correct. As for the details, I can not say.
(This would be true for a "ball" mouse, not an "optical" mouse.)

[gauntletguy]

would it be possible to wire multiple sensors together?

[writchie]

Originally Posted by gauntletguy

would it be possible to wire multiple sensors together?

Short answer is yes. The output is a transistor with a 30K pullup. It should
remain well within spec with 3 additional identical devices plus the current
sourced from the Robot Controller. So you should be able to have a total
of 4 sensors on one input. (You could probably have several more but then
you will be outside the 250mV max output low voltage specification.

Beware, however, that you be subject to interference from any sensor
which may prevent your desired signal from getting through. An interfering
signal on the same carrier frequency being received from any of the sensors
will interface will all sensors.

A more robust approach would be to use separate interrupts for multiple sensors
f you have the available interrupts (from 3 to 6). This way, an interfering signal being received from one sensor will not mess up the signal
being received at the other sensor. You will need to modify the code to
share a timer.