Stumped!

[jodicalhon]

I have a small robot that I control via a TV remote sending Sony IR code. The robot has an 08M on board receiving commands via INFRAIN2.
0 = left, 1 = forward, 2 = right, 4 = reverse. Any other commands (3 for example) will stop the robot.

I am trying to control it from my computer. The idea is to send commands from the terminal program, contained in the Rev-ed programming software, via the serial cable to another 08M which will then send the command to the robot via INFRAOUT.

Obviously, I'm having problems.

Here's what I tried:

main:

serin 4, N2400, b0 'accepts cmd from terminal
pause 200

for b1 = 1 to 10 'as per reved pdf 2
infraout 1, b0
pause 45
next b1

goto main

My 'bot beeps, as it should to show it has received IR, but no motor movement occurs.

After a few tries, examination of my breadboard etc, I then tried sending just the actual commands, not b0. That is, I changed the infraout line in the above to read:

infraout 1, 1

Whatever it received via serin, it just sent command 1, move forward. And the little bot moved forward as it should. Hmmm.

I tried the original approach again. No joy.

I got rid of the serin entirely, set up a switch on pin4 and coded:

main:

if pin4 = 1 then revTry

for b1 = 1 to 10
infraout 1, 1 'bot goes forward
pause 45
next b1

pause 500
goto main

revTry:
for b1 = 1 to 10
infraout 1, 4 'bot reverses
pause 45
next b1
return

The bot moved forward until I pulled pin4 high, then reversed. So bot is receiving IR and responding to the commands.

I tried the initial code again. No joy.

Maybe infraout doesn't like sending b0; maybe it just likes things like 1, or 4, or 3, etc? More experimentation. Next try was.

main:

for b0 = 0 to 4
gosub irOut
pause 500
next b0

goto main

irOut:
for b1 = 1 to 10
infraout 1, b0
pause 45
next b1
return

(This code is from memory, so the pause 500 may have been in a different place, but the intent is plain I think).

Receiving these signals, the 'bot cycled through 'left, forward, right, stop, reverse', as it should.

Tried the original code. No joy.

Hmmm. Maybe the terminal is sending crap to the transmitting 08M? So I added this to the original code, just after the infraout routine:

serout 1, N2400, (b0)

When I sent a '1' (fwd) from the terminal, my bot beeped (receiving IR), and a '1' popped up on the terminal input window. No movement from bot, however. I tried sending a '4'(rev), again the bot beeped and a '4' popped up on the terminal input window.

So the tranmitting 08M seems to be getting the correct data from the terminal.

I'm totally lost, but having read through the above I think I can say that the bot only fails to respond when the commands are coming <i>from the terminal program </i> to the transmitting 08M. But using serout to loop back those commands to the terminal input window seems to say that the correct code <i>is </i> being sent.

Bet it's something really basic, and you've been sadly shaking your head as you've read the (long) sad tale above!













Edited by - Jo C on 29/09/2006 14:24:06

 

[Technical]

When you send the character 1 from the serial terminal on the computer you are sending an ASCII character '1', not the actual number 1.

Add the line
b0 = b0 - $30

after the serin line to convert ascii characters to real number. Also try making use of a debug line after serin to check the variable value is actually what you want whilst testing!

 

[jodicalhon]

Doh! Thanks Technical, I can keep what's left of my hair. (Hmmm...debug...what a novel idea...)

 

[jodicalhon]

Technical, your code amendment works a treat. Regarding your debug suggestion, I don't seem to be able to have both the terminal window and the debug window open at the same time. But never mind, I'm happily controlling the bot via the pc. Cheers.

 

[hippy]

Debug and Terminal are mutually exclusive. You can see a 'load of junk' which is the debug information in Terminal if you close Debug and switch to that but it won't be meaningful or useful.

I personally think using SERTXD or SEROUT is preferable to DEBUG and you did exactly the right thing in adding the SEROUT to send back what was coming in.

 

[jodicalhon]

Thanks Hippy. Sending a '1', then getting a '1' back on the input screen in response to the SEROUT command had me confused (my normal state).

I've had a closer read of the manual2 pfd, and note this from the SEROUT syntax entry:

&quot;The # symbol allows ascii output. Therefore, #b1, when b1 contains the data 126, will output the ascii characters &quot;1&quot; &quot;2&quot; &quot;6&quot; rather than the raw data 126&quot;

I assume my SEROUT line should have contained the # qualifier:

serout 1, N2400, (#b0)

Presumably, (and I'm not in a position to try it tonight, but I'll try later), this would have sent back '49', thus alerting me to the problem.



Edited by - Jo C on 01/10/2006 14:56:56