Joystick Input

Okay, and what are you using on the computer side to send out these characters? Are you typing them into a terminal program or did you write something?

-Adam

We are using the Debug terminal that is part of the BASIC Stamp Editor.

Well if you want to keep doing it that way (and avoid computer programming all together) I bet you could get a lot of functionality by pairing any joystick with this program: Joystick Cursor Tool

I haven’t had a chance to play with it yet (but I will, probably later today, if I can get one of my old joysticks working with my system again), but it looks like it would let you create a profile of simulated keyboard key presses triggered by motions of the joystick.

Let us know what you think of it.

-Adam

That looks pretty interesting, and I haven’t looked at it much, but here is a concern I immediately had when looking at that page:

If the joystick simulates keyboard presses, then when I move it one way it would make a certain motor go faster; however, if I wanted to slow that motor down, I would have to move the joystick backwards, not just move it’s position to zero, correct?

Yeah, there are definitely limitations to the no-programming approach, but you can get pretty creative.

That program might let you send a character when the joystick returns to center. Or if the program lets you send characters repeatedly while the joystick is over to one side you could have a timeout on the basic stamp where it will stop the motors if it doesn’t receive a character in enough time.

-Adam

I just purchased a Logitech Dual Action Gamepad, which someone told me I could use with a certain program that he supplied. I’m testing that out now, but I don’t know how it will turn out.

Cool, please let us know how it goes!

-Adam

The program he gave me gave me a runtime error, so I asked him about it. In the meantime, I’m using the Joystick Cursor Tool program you showed me to mess around with different key presses. I’ll do some testing with it tomorrow.

If I want the BASIC Stamp to set a variable to 0 if it doesn’t hear from the computer for a set amount of time, what command would I use?

I don’t know much about Basic Stamp programming actually, but I asked a friend at work who does.

The simplest way to do this would be to use the SERIN function instead of DEBUGIN. SERIN lets you set a timeout, and specify what to do if no new characters are received if that time has passed. Maybe someone else can explain it in a little more detail than that, but you can read about it on page 397 of the Basic Stamp Command Reference document.

It’s a shame the joystick program doesn’t seem to just let you type a character when the joystick is left neutral (or does it?).

-Adam

I looked and I don’t believe it does. That would indeed be nice. I’ll explore that some more.

I asked the same question on the Parallax forum, so they’re helping me out with that.

Thanks

Alright, we got the source code for the Joystick Mouse Tool, and our instructor is going to take a lok at it and hopefully help us adapt that to our purpose. It would indeed be nice to actually have the motors respond to where the joystick is as opposed to if the joystick is pushed in a certain direction.

I’ll update this thread with advances we make.

Thanks guys!

Maybe you guys can help. The people on the Parallax forum aren’t being too helpful.

Here is my code:

' {$STAMP BS2}
' {$PBASIC 2.5}
x VAR Byte
y VAR Byte
z VAR Byte
DO
  DEBUG CR
  SEROUT 0, 84, [z, x]
  SERIN 16, 16468, Continue, 10000, Time_Out, [y]
LOOP
Continue:
  IF (y=97) THEN
  z=$C6
  x=127
  ELSEIF (y=115) THEN
  z=$C5
  x=127
  ENDIF

Time_Out:
  z=$C4
  x=0

I want it to go to “Continue” if it gets a y value and I want it to go to “Time_Out” if it times out.

Thanks

Try this - Continue and Time_out need to be followed with a goto in order to come back to the main loop. There may be a cleaner way to do this with PBasic 2.5, but this should work. (Russ for Adam)

    ' {$STAMP BS2}
    ' {$PBASIC 2.5}
    x VAR Byte
    y VAR Byte
    z VAR Byte
 
Main:
   DO
      DEBUG CR
      SEROUT 0, 84, [z, x]
      SERIN 16, 16468, Continue, 10000, Time_Out, [y]
    LOOP
    Continue:
      IF (y=97) THEN
      z=$C6
      x=127
      ELSEIF (y=115) THEN
      z=$C5
      x=127
      ENDIF
   Goto Main   

    Time_Out:
      z=$C4
      x=0
  Goto Main

Aha! I used the changes you made then made one more change.

The SEROUT command looked like this: SEROUT 0, 16468, Continue, 2000, Time_Out, [y]

The Continue is a space called PLabel which tells it to go to “Continue” in the event of a parity error. I don’t have that happening, so I had to tweak it to this:

' {$STAMP BS2}
' {$PBASIC 2.5}
x VAR Byte
y VAR Byte
z VAR Byte
Main:
DO
  DEBUG CR
  SEROUT 0, 84, [z, x]
  SERIN 16, 16468, 150, Time_Out, [y]
  DEBUG "test"
  DEBUG CR
  DEBUG ? y
  DEBUG CR
  IF (y=97) THEN
  z=$C2
  x=127
  ELSEIF (y=115) THEN
  z=$C1
  x=127
  ENDIF
  GOTO Main
  LOOP
Time_Out:
  z=$C4
  x=0
  GOTO Main

Something is wrong, I’m not sure what.

When y=111 or y =105, it sends b and n out of pin 0, and I don’t want it to. I don’t understand why it’s doing than. Here’s the new code:

' {$STAMP BS2}
' {$PBASIC 2.5}
x VAR Byte
y VAR Byte
z VAR Byte
c VAR Byte
b VAR Byte
n VAR Byte
Main:
DO
  DEBUG CR
  SEROUT 0, 84, [z, x]
  SEROUT 0, 84, [c, x]
  SEROUT 8, 84, [b, x]
  SEROUT 8, 84, [n, x]
  SERIN 16, 16468, 150, Time_Out, [y]
  DEBUG ? y
  DEBUG CR
  IF (y=97) THEN
  z=$C2
  c=$CA
  x=127
  ELSEIF (y=115) THEN
  z=$C1
  c=$C9
  x=127
  ELSEIF (y=100) THEN
  z=$C2
  c=$C9
  x=127
  ELSEIF (y=102) THEN
  z=$C1
  c=$CA
  x=127
  ELSEIF (y=113) THEN
  b=$C2
  n=$CA
  x=127
  ELSEIF (y=119) THEN
  b=$C1
  n=$C9
  x=127
  ELSEIF (y=111) THEN
  b=$C2
  n=$C9
  x=127
  ELSEIF (y=105) THEN
  b=$C1
  n=$CA
  x=127
  ENDIF
  GOTO Main
  LOOP
Time_Out:
  z=$C4
  x=0
  GOTO Main

Any ideas?

Are you sure it’s sending out the B and N variables? When you send a 111 or a 105 (or a 113 or a 119 for that matter) it looks like your loop will transmit the old values of Z and C on pin 0.

For example, if you sent your stamp a 100 byte, your code would set: z=$C2, c=$C9
When the loop returns to the top of main, it will send these values of z and c out on pin 0.
Then if you sent a 111 byte, your code would set: b=$C2, n=$C9
When the loop returns to the top of main, it will send the old values of z and c out on pin 0 again, which happen to be equal to the new values of b and n you just set. Could this be what you’re seeing?

-Adam

Hm, that makes sense…

I tried setting the variables to 0 at the beginning of “Main”, but nothing happened then, so I think it kept them at 0 throughout the entire program. So I’m not sure how to get around that.

Wait, I just read your response and I don’t think that’s what’s happening.

I have it so that the motors pulse. There is nothing happening unless I press a button, and then the motor(s) go on and turn off after 150 ms. When I set b and/or n to something, it sends out commands that should be going out through pin 8 through pin 0.

So I changed the x variable to t on the SEROUT 8 commands, and it fixed the problem.

I just needed to look at it a little longer.

Thanks :slight_smile: