IR_Sensor Programming

[Speaker47]

Hi we are second year team, in Canada, we got stuck in programming the IR_Sensor, and we like to know if there is any hints or guides to programming the sensor with any default code available if you have programmed an IR Sensor, and have valid code that really works we would be glad to recieve help on this programming issue.
We already have a code attached with is message, if you could please look in the fast loop and verify what's wrong and inform us about our recent problems with the IR we will be grateful. Thanks again fro your time

[Alan Anderson]

I see some things I'd code differently, but it's hard to find anything "wrong" until you define two things. First, what is it supposed to do? Second, what does it do instead? Try to give as much detail as you can.

If I were to guess at the problem, I'd say that you're trying to control pwms 13 and 15 in two different places.

[Speaker47]

Ok we have a major issue with the IR_Sensor

In the fast loop, in user_routines_fast.c, the program of the IR_sensor is not working ven though we tried to use digital inputs, there is no signal on the rc_dig_in17, Does anone have a possible code of the IR_Sensor that our team can try on our bot>> Thanks Again

[Mark McLeod]

The default code has digital input 17 as an output rather than an input.
Change this in user_routines.c, User_Initialization().

[Speaker47]

I tried switching it too input, when we do it,

Even after we print the value on rcdig_in17 after using the remote there is no response.

[Mark McLeod]

Here's an example of a working IR program built on the default code.
http://team358.org/files/programming...or_example.zip

Everything is contained within user_routines.c, Default_Routine().

It expects the four IR digital inputs to be connected to digital inputs 15,16,17,18. If any are not connected properly it will not do anything (for safety reasons).

The user byte display on the OI will show 1, 2, 4, or 8 for the different IR commands received.
If you see anything else, then the digital pins are not connected properly.

P.S.
This code is set to work with a common ground (both the Robot Controller and the IR sensor powered from the same battery). If you are using a separate battery the code will need additional checks in two places for "15"

[Speaker47]

We have tried, it with loading this code to the main microprocessor, and there is no response...

Anyway, is it possible for you to elaborate on what you mean by:

The user byte display on the OI will show 1, 2, 4, or 8

I thought each port in the digital input ports should get a value of either 1 or 0 like a binary system?????

[wt200999]

On the Operator interface if you hit mode (middle button under the team number)one of the things that comes up is like "u015". You set the user byte to what you want that to display. The default code sets that to the backup battery voltage.

[Mark McLeod]

What Will said.

That code plays a little trick with the digital inputs and combines the four (0 or 1) inputs into a single four-digit binary number, where each digit represents one of the four digital inputs.
So the numbers you get are:

binary  decimal
0000      0
0001      1
0010      2
0100      4
1000      8

If you get any other number it means the digital inputs aren't connected correctly. For instance, if the IR board isn't connected at all you will get

binary  digital
1111     15

So that can help you to debug bad connections and see it on your OI display.

P.S. When you first use the OI Select button to switch to User Mode you'll see "u015" or something similar displayed for a couple of seconds. This is the Master Code version loaded on the Robot Controller.

[Red Mage]

Hi, this isn't about your code but Mark McCleod mentioned at his workshop a mysterious port j. We found where it is in the code but cannot understand how to use it. Any help?

[Speaker47]

Hi,

We got the code to work, the only problem was that after each case segment the pwms needed to be generated, which is why it wasn't working. The code only works in PORTJ for us, and all the digital inputs need to be read at one time, for the IR to work. We are working on a few modifications, to the code...Finally, the code can be put anywhere....

However, we are running into further issues, if anyone one could help us find a way in MPLAB to time how long motors need to be on (Milliseconds)... So, basically, the equivalent of the "wait" function in EasyC. We need to know this for our autonomous code, that we want to run in our bot.

Thank You For All Your Help

[Mark McLeod]

Originally Posted by Red Mage

...a mysterious port j. We found where it is in the code but cannot understand how to use it.

Here's the background on the mysterious PORTJ.

The robot system variables we use (e.g., rc_dig_in18) are just aliases for connections or "windows" into the real PIC hardware. In the hardware, 8-bit registers are wired to hold the constantly sampled state from the pins (or the output state we want) and our aliases are just simpler ways to look at individual bits within these registers, one bit per digital I/O pin.

If you look in the file ifi_aliases.h you'll see these aliases defined for our 18 digital inputs:

#define rc_dig_in01 PORTBbits.RB2 
#define rc_dig_in02 PORTBbits.RB3 
#define rc_dig_in03 PORTBbits.RB4 
#define rc_dig_in04 PORTBbits.RB5 
#define rc_dig_in05 PORTBbits.RB6 
#define rc_dig_in06 PORTBbits.RB7 
#define rc_dig_in07 PORTHbits.RH0
#define rc_dig_in08 PORTHbits.RH1
#define rc_dig_in09 PORTHbits.RH2
#define rc_dig_in10 PORTHbits.RH3
#define rc_dig_in11 PORTJbits.RJ1
#define rc_dig_in12 PORTJbits.RJ2
#define rc_dig_in13 PORTJbits.RJ3
#define rc_dig_in14 PORTCbits.RC0
#define rc_dig_in15 PORTJbits.RJ4
#define rc_dig_in16 PORTJbits.RJ5
#define rc_dig_in17 PORTJbits.RJ6
#define rc_dig_in18 PORTJbits.RJ7

You'll notice all the values we use come through some register, such as:
-- PORTB for the interrupts on digital inputs 1-6
-- PORTH for inputs 7-10
-- PORTJ for inputs 11-13 and 15-18
-- PORTC for input 14

We can use any of these registers we wish or just use the aliases everyone's accustomed to. PORTH also has four pins grouped together that we could easily use by masking out (using the "&" operator) the other upper four bits in that register.

The demo code wants only the last four bits of PORTJ (15-18), so a simple way to eliminate the other unwanted values is to just truncate them by shifting the four bits we want to the right thereby pushing the four bits we don't want out of the variable altogether, e.g., 10001111 >> 4 becomes 00001000

The trick demonstrated with PORTJ allows the code to capture all the pin values at once in an instant of time. It just illustrates the potential window of error that could occur if the IR sensor changed the signals while we were testing them one at a time.

P.S. The excrutiating detail on PORTJ is described in the PIC18F8722_data_sheet.pdf that came on the CBOT compact disk in the KOP.

[Speaker47]

Great the PortJ problem is fixed Thanks Alot....

But We have other difficulties,


1. We need to find a way to time how long the motors will run in autonomous, something like the "wait" function in Easy C..

2. Also, can anyone tell me how to turn on and off relay motors that I might use in autonomous??????

[wt200999]

1. Add a counter or something similar:

if(x<100)
     pwm01=pwm02=150;
if(x>100
     pwm01=pwm02=127;

x++

2. Take a look at how they have the relays in the default code under the default_Routine() function

[Red Mage]

Originally Posted by Mark McLeod

Here's the background on the mysterious PORTJ.

The robot system variables we use (e.g., rc_dig_in18) are just aliases for connections or "windows" into the real PIC hardware. In the hardware, 8-bit registers are wired to hold the constantly sampled state from the pins (or the output state we want) and our aliases are just simpler ways to look at individual bits within these registers, one bit per digital I/O pin.

If you look in the file ifi_aliases.h you'll see these aliases defined for our 18 digital inputs:

#define rc_dig_in01 PORTBbits.RB2 
#define rc_dig_in02 PORTBbits.RB3 
#define rc_dig_in03 PORTBbits.RB4 
#define rc_dig_in04 PORTBbits.RB5 
#define rc_dig_in05 PORTBbits.RB6 
#define rc_dig_in06 PORTBbits.RB7 
#define rc_dig_in07 PORTHbits.RH0
#define rc_dig_in08 PORTHbits.RH1
#define rc_dig_in09 PORTHbits.RH2
#define rc_dig_in10 PORTHbits.RH3
#define rc_dig_in11 PORTJbits.RJ1
#define rc_dig_in12 PORTJbits.RJ2
#define rc_dig_in13 PORTJbits.RJ3
#define rc_dig_in14 PORTCbits.RC0
#define rc_dig_in15 PORTJbits.RJ4
#define rc_dig_in16 PORTJbits.RJ5
#define rc_dig_in17 PORTJbits.RJ6
#define rc_dig_in18 PORTJbits.RJ7

You'll notice all the values we use come through some register, such as:
-- PORTB for the interrupts on digital inputs 1-6
-- PORTH for inputs 7-10
-- PORTJ for inputs 11-13 and 15-18
-- PORTC for input 14

We can use any of these registers we wish or just use the aliases everyone's accustomed to. PORTH also has four pins grouped together that we could easily use by masking out (using the "&" operator) the other upper four bits in that register.

The demo code wants only the last four bits of PORTJ (15-18), so a simple way to eliminate the other unwanted values is to just truncate them by shifting the four bits we want to the right thereby pushing the four bits we don't want out of the variable altogether, e.g., 10001111 >> 4 becomes 00001000

The trick demonstrated with PORTJ allows the code to capture all the pin values at once in an instant of time. It just illustrates the potential window of error that could occur if the IR sensor changed the signals while we were testing them one at a time.

P.S. The excrutiating detail on PORTJ is described in the PIC18F8722_data_sheet.pdf that came on the CBOT compact disk in the KOP.

Thanks, unfortunately by this time Miss Reiss told us to focus on the pneumatics since we haven't done that yet.