When I start a Retrochallenge project, I always expect that it’s going to be something I work on steadily throughout the month, making gradual progress the whole time. This time, I got 75% of the real work done in one night of beer-, caffeine-, and prog-rock-fueled coding. Reminds me of being in college.
The video above shows the final results, so I’m just going to quickly explain the process here. Once I was able to send characters back and forth between the C64 and the robot, it was mostly a matter of deciding what to send and how to interpret it. I had three basic rules:
- The C64 joystick would be used to enter commands which would be sent to the robot. The C64 display would not be updated directly by the joystick input.
- The robot would send signals back about its direction of movement and its left and right bumper contacts. That data would be used to update the C64 display.
- As a defense against occasional glitches in communication, each signal would consist of three characters. I settled on a ‘$’, followed by a control character, followed by a ‘!’. For example, the C64 sent commands “$1!” through “$8!” to tell the robot which of 8 directions to move in, and the robot used the same commands to tell the C64 which direction it actually was going in.
While I didn’t have time to do something fancier where the C64 would actually expect an ACK from the robot and resend if needed, this way I still had feedback on screen that indicated what the robot was actually doing – instead of what I thought it was doing.
In practice, glitches have been few and far between. The exception is that the first character received by the C64 after the control program starts is always incorrect. You can actually see that when I’m demonstrating the bumpers in the video – the first time I touch the bumper nothing happens. I usually turn on the robot after starting the control program, in which case the first bad character is part of an initial status string the robot sends. This time I had it the wrong way around.
The C64 joystick is a digital joystick capable of registering 8 directions – at least in theory. With the Epyx 500XJ I’m using, I found that the diagonals were kind of tricky. You had to position the stick just right, and even then it tended to bounce between directions a bit. In practice, I found it was easiest to stick with the four cardinal directions: Forward and back motion, with left and right rotating the robot in place.
I also noticed that the switch for the bottom position of my joystick was not giving a very steady response. You can see some of the jerkiness that results in the video. Retro hardware is retro, but I do wonder if there’s a way to fix that. The 500XJ is my favorite joystick, and I’d hate to lose it.
After getting the robot to actually move around under joystick control, I tried to get a good night’s sleep, but something was bothering me. I still hadn’t done anything with the joystick’s fire button! One of the tutorials for the BOE-Bot is a free-roaming mode where it goes forward until the bumpers hit something. It then backs off a few inches, turns away from the obstruction, and sets off in a new direction. I adapted that code to my project, and used the fire button to send a command to toggle between joystick mode and free roam mode.
When it’s in free roam mode, the Arduino in the robot is in charge of making decisions, but it still sends out status updates. That way the C64 display shows the bumper activations and direction changes when the robot hits things, even when it’s wandered off out of my workroom and down the hall. The only problem is that the wire bumpers are several inches off the ground, so it can still get hung up on low-rising obstructions on the floor, like books or piles of laundry.
That problem makes me wonder if it’d be possible to add a camera to the robot. You couldn’t do video at 1200 baud, but maybe you could treat it like a Mars rover, stopping every few feet to take a picture of its surroundings. Well, maybe that’ll be a project for next year!