If anyone's interested: latest robot program
Here is my new-and-improved Lego robotic forklift program. Special thanks this time to Paul Hagstrom for his helpful suggestion that I detect all the joystick direction options, save the active one to a variable, and then POKE once as needed vs. trying to detect/POKE after each possible case. ---------- 10 GOSUB 1000: REM INIT LEGO 20 POKE L,0: REM ALL OFF 30 GOSUB 2000: REM NAVIGATION 40 GOSUB 3000: REM BUTTONS 50 GOTO 30 60 END 1000 S = 7:L = 49280 + S * 16 1010 POKE L + 3,1 1020 POKE L + 2,63 1030 POKE L + 1,0 1040 POKE L,0 1050 RETURN 2000 REM NAVIGATION 2010 FB = PDL (1):LR = PDL (0) 2020 M = 0 2030 IF FB < 75 THEN M = 5 2040 IF FB > 180 THEN M = 10 2050 IF LR < 75 THEN M = 9 2060 IF LR > 180 THEN M = 6 2070 POKE L,M 2080 IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W 2090 RETURN 3000 REM FORLIFT 3010 IF PEEK (49249) > 127 THEN POKE L,16: GOTO 3010 3020 IF PEEK (49250) > 127 THEN POKE L,32: GOTO 3020 3030 RETURN Real simple: Lines 10-60 are the main program, 1000-1050 are the required Lego initialization, 2000-2090 are the robot control (front - back - left - right), and 3000-3030 make the forklift go up/down. Hey Jeff and Dan, I think I've graduated from spaghetti code. :) As I told Dan already, the next thing I'll add is a Lego sensor to prevent the forklift from trying to continue going up/down when it reaches its mechanical limit. This did not work on my previous robot (to detect the limits of rack-and-pinion steering and disable the relevant motor) because the motor moved too fast. Not a problem with the forklift: it intentionally moves veeeeeeeeeery slow. I also ordered mini banana plugs so I can make new connecting wires between the Lego interface box and the motors, lights, and sensors. The 30-year-old wires from Lego are badly worn out. The difference when I connected a motor using these old wires vs. using modern alligator clips was palpable. Jeff B., all I have to do to dominate your Capsella robot is corner it, get the forklift under its drive wheels, and press the up button before you escape. :) Then your robot will be (ahem) forked. ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
Yeah! No more spaghetti code! And using GOSUBs instead of GOTO. Well I will have to work on ways to defeat your Lego robot in a future robot war! ;) On Sun, Feb 19, 2017 at 8:41 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Here is my new-and-improved Lego robotic forklift program. Special thanks this time to Paul Hagstrom for his helpful suggestion that I detect all the joystick direction options, save the active one to a variable, and then POKE once as needed vs. trying to detect/POKE after each possible case.
----------
10 GOSUB 1000: REM INIT LEGO 20 POKE L,0: REM ALL OFF 30 GOSUB 2000: REM NAVIGATION 40 GOSUB 3000: REM BUTTONS 50 GOTO 30 60 END 1000 S = 7:L = 49280 + S * 16 1010 POKE L + 3,1 1020 POKE L + 2,63 1030 POKE L + 1,0 1040 POKE L,0 1050 RETURN 2000 REM NAVIGATION 2010 FB = PDL (1):LR = PDL (0) 2020 M = 0 2030 IF FB < 75 THEN M = 5 2040 IF FB > 180 THEN M = 10 2050 IF LR < 75 THEN M = 9 2060 IF LR > 180 THEN M = 6 2070 POKE L,M 2080 IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W 2090 RETURN 3000 REM FORLIFT 3010 IF PEEK (49249) > 127 THEN POKE L,16: GOTO 3010 3020 IF PEEK (49250) > 127 THEN POKE L,32: GOTO 3020 3030 RETURN
Real simple: Lines 10-60 are the main program, 1000-1050 are the required Lego initialization, 2000-2090 are the robot control (front - back - left - right), and 3000-3030 make the forklift go up/down.
Hey Jeff and Dan, I think I've graduated from spaghetti code. :)
As I told Dan already, the next thing I'll add is a Lego sensor to prevent the forklift from trying to continue going up/down when it reaches its mechanical limit. This did not work on my previous robot (to detect the limits of rack-and-pinion steering and disable the relevant motor) because the motor moved too fast. Not a problem with the forklift: it intentionally moves veeeeeeeeeery slow.
I also ordered mini banana plugs so I can make new connecting wires between the Lego interface box and the motors, lights, and sensors. The 30-year-old wires from Lego are badly worn out. The difference when I connected a motor using these old wires vs. using modern alligator clips was palpable.
Jeff B., all I have to do to dominate your Capsella robot is corner it, get the forklift under its drive wheels, and press the up button before you escape. :)
Then your robot will be (ahem) forked.
________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit
evan@vcfed.org (646) 546-9999
www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
-- Jeff Brace - ark72axow@gmail.com Sent from my Commodore 64
On Mon, Feb 20, 2017 at 2:47 AM, Jeffrey Brace via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Yeah! No more spaghetti code! And using GOSUBs instead of GOTO.
Well I will have to work on ways to defeat your Lego robot in a future robot war! ;)
Jeff, FYI, if you want, pretty soon you can use the Lego robot kits on the C64 too, getting the adapter cable made here to run it on mine all you need is just need a 9750 box, the software is basically the same Evan, FYI, this is what I mentioned last time, this will let you operate the forklift at the same time, just like a real one Because it speeds up your reaction time during a robot contest Even when the forklift motor is slow which is best reason to use this "multi-motor" option Also, this removes the *redundant* subroutine 3000 for the Forklift motor All motors can be controlled in *one* subroutine at 2000 As you can see, the Poke value is the sum of M and F, So one setting doesn't disturb the other The new Input subroutine at 3000 takes care of *all* inputs and they're saved into their respective variables This allow non-blocking operation Dan 10 GOSUB 1000: REM INIT LEGO 15 M=0:F=0 20 POKE L,0: REM ALL OFF 25 GOSUB 3000: REM CHECK INPUT 30 GOSUB 2000: REM MOTORS 40 GOTO 25 50 END 1000 S = 7:L = 49280 + S * 16 1010 POKE L + 3,1 1020 POKE L + 2,63 1030 POKE L + 1,0 1040 POKE L,0 1050 RETURN 2000 REM MOTORS, BOTH DRIVE AND FORKLIFT SETTINGS 2070 POKE L,M+F 2080 IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W 2090 RETURN 3000 REM CHECK INPUT, JOYSTICK FIRST 3010 FB = PDL (1):LR = PDL (0) 3015 IF FB < 75 THEN M = 5:GOTO 3040 3020 IF FB > 180 THEN M = 10:GOTO 3040 3025 IF LR < 75 THEN M = 9:GOTO 3040 3030 IF LR > 180 THEN M = 6:GOTO 3040 3035 M = 0:REM IF NO DIR, KEEP OFF 3040 REM CHECK BUTTONS 3045 IF PEEK (49249) > 127 THEN F=16:GOTO 3060 3050 IF PEEK (49250) > 127 THEN F=32:GOTO 3060 3055 F=0:REM IF NO BUTTON, KEEP OFF 3060 RETURN
Also, this removes the *redundant* subroutine 3000 for the Forklift motor All motors can be controlled in *one* subroutine at 2000 As you can see, the Poke value is the sum of M and F, So one setting doesn't disturb the other The new Input subroutine at 3000 takes care of *all* inputs and they're saved into their respective variables This allow non-blocking operation
Why do you have the POKEing routine (2000 series) transpire before it checks what the operate wants POKEd (3000 series)?
On Mon, Feb 20, 2017 at 3:43 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Also, this removes the *redundant* subroutine 3000 for the Forklift motor
All motors can be controlled in *one* subroutine at 2000 As you can see, the Poke value is the sum of M and F, So one setting doesn't disturb the other The new Input subroutine at 3000 takes care of *all* inputs and they're saved into their respective variables This allow non-blocking operation
Why do you have the POKEing routine (2000 series) transpire before it checks what the operate wants POKEd (3000 series)?
subroutines can be arranged in any order as long as you Call them at the appropriate time Line 25 Calls Sub 3000 to check for any Input Line 30 Calls Sub 2000 to executes the commands given by the Input data Line 40 go do it again
Why do you have the POKEing routine (2000 series) transpire before it checks what the operate wants POKEd (3000 series)?
subroutines can be arranged in any order as long as you Call them at the appropriate time Line 25 Calls Sub 3000 to check for any Input Line 30 Calls Sub 2000 to executes the commands given by the Input data
Right. You have it backward and inside-out. :) That would drive me crazy. I'll enter it in the right order and change the line numbers as needed.
On Mon, Feb 20, 2017 at 4:36 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Why do you have the POKEing routine (2000 series) transpire before
it checks what the operate wants POKEd (3000 series)?
subroutines can be arranged in any order as long as you Call them at the appropriate time Line 25 Calls Sub 3000 to check for any Input Line 30 Calls Sub 2000 to executes the commands given by the Input data
Right. You have it backward and inside-out. :) That would drive me crazy.
I'll enter it in the right order and change the line numbers as needed.
it's relative :)
this will let you operate the forklift at the same time, just like a real one Because it speeds up your reaction time during a robot contest
Decided to keep the operation as I had it (drive motors stop when forklift is in use). It's fun to joke about battlebots :) but remember I made this robot to teach children in the museum.
Also, this removes the *redundant* subroutine 3000 for the Forklift motor All motors can be controlled in *one* subroutine at 2000
I certainly could combine the navigation/forklift routines. But just as you and Jeff "reminded" me that writing the whole program straight-through without any routines at all would work but would be inelegant, I'm again reminding you that this is "you know, for kids!" ... keeping the navigation and forklift control in separate routines makes it more educationy. :) ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
On Mon, Feb 20, 2017 at 5:30 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I'm again reminding you that this is "you know, for kids!" ... keeping the navigation and forklift control in separate routines makes it more educationy. :)
I'll remind you about that "educationy" thing when the first kid that fixes your code ;) haha
This is a learning process for Evan too. He will have all the spaghetti code all dried up and straightened out before he demos it! On Mon, Feb 20, 2017 at 8:39 PM, Dan Roganti via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Mon, Feb 20, 2017 at 5:30 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I'm again reminding you that this is "you know, for kids!" ... keeping the navigation and forklift control in separate routines makes it more educationy. :)
I'll remind you about that "educationy" thing when the first kid that fixes your code ;) haha
-- Jeff Brace - ark72axow@gmail.com Sent from my Commodore 64
This is a learning process for Evan too. He will have all the spaghetti code all dried up and straightened out before he demos it!
The main thing I learned is to be careful who I ask for help. :) Me: "What's a simple way to code this one little part in BASIC for kids?" Other people: "Change to COBOL and add 90 more lines."
I could make my own suggestions, but there are basic books on BASIC as well as those designed for kids. There are instructional books for learning BASIC as well. Look for books written back in the day or design your own. On Mon, Feb 20, 2017 at 10:58 PM Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
This is a learning process for Evan too. He will have all the spaghetti code all dried up and straightened out before he demos it!
The main thing I learned is to be careful who I ask for help. :)
Me: "What's a simple way to code this one little part in BASIC for kids?"
Other people: "Change to COBOL and add 90 more lines."
-- Jeff Brace - ark72axow@gmail.com Sent from my Commodore 64
I could make my own suggestions, but there are basic books on BASIC as well as those designed for kids. There are instructional books for learning BASIC as well. Look for books written back in the day or design your own.
Still have the book that I got when I was 12. Maybe it's time for something more advanced...
participants (4)
-
Dan Roganti -
Douglas Crawford -
Evan Koblentz -
Jeffrey Brace