Keyboard library

Support CodeSpace
1

I think it would be fun to have keyboard controlled virtual robot. Would it be possible to incude keyboard or pynput library to code space environment?

from keyboard import *

from pynput import *

2

We don’t have full keyboard input available… BUT the virtual CodeBot has buttons 0 and 1. And in addition to clicking them with the mouse you CAN use keyboard buttons 0 and 1 to press those buttons. So driving with the keyboard using buttons 0 and 1 is indeed possible :slight_smile:

3

Hi,

I experimented with the buttons, but unfortunately I get the buttons.is_pressed True only when I click with the mouse on them. Do you have any suggestions how to bind keyboard to the buttons?

P.S. I play with virtual robot in codeSpace.

4

Are you in the Haunted Code Chronicles?

For that one, the keyboard navigation is disabled.

The reason is, that mission pack is used for contests where fully autonomous control from your python code is required. Or some people theorize that the evil spirits sever the astral connection that enables keyboard control…

1 Like
5

Thanks, it worked (finally). The focus of the input should be on the simulation (needs to be clicked on it to get focus).

6

Awesome! Thanks for the extra bit of information - sorry I neglected to mention the focus thing, it just didn’t occur to me since I’ve done it too many times… Good to have the information here in case it trips someone else up!

7

Hi! @lceponis @dewing Something I’m doing with my students is using the built in command terminal for keyboard I/O. For example:

def go(label=""):
    """Minimal press-enter prompt."""
    if label:
        input(f"  {label} — press Enter...")
    else:
        input("  Press Enter to continue...")
    print("")

This can be used to accept input commands to go forward, turn left, turn right, and stop. Let me know if you’d like sample code to make this happen!

8

Hi, @abaskaran

Yes, I found how to wait for input in the terminal. My wish was to wait for input while in camera mode and without “enter”. Buttons 1 and 0 is great option to add some on the flight remote control (speed, turn, stop).

But I noticed strange behavior: the focus on the simulation might be lost and it drops to the terminal and zeros appears there. More like that in the Brave browser, than Chrome.

I’ll play with that more. Maybe terminal MUST be closed?

9

That focus-shuffle makes sense given how the keyboard shortcut works — the simulation only picks up the 0/1 keypresses while it has keyboard focus, so anything that steals focus (clicking into the terminal, another panel grabbing focus, etc.) will route those keys straight into the terminal instead. That’s why you see the zeros piling up there.

A few things that might help:

  • Click the simulation once right before you start driving, and try not to click elsewhere during the run
  • If you don’t need the terminal for the activity, collapsing/closing that panel cuts out the most common place for stray keys to land
  • Avoid interacting with other panels (file tree, objective pane) mid-drive — those can pull focus too

On the Brave vs. Chrome difference — Brave’s Shields and extra privacy tweaks sometimes interfere with iframe focus/keyboard handling, so it’s plausible. A quick test would be trying the same code in Chrome, or dropping Shields for codespace.firialabs.com in Brave, and seeing if the behavior changes. If you do that experiment I’d be curious what you find.

For a richer “remote control” feel on the virtual CodeBot, buttons 0 and 1 are what’s available keyboard-wise — so folks typically combine them (tap sequences, hold one, press both) to encode speed/turn/stop. Not a full keyboard library, but it works well once focus stays put.

cc @Kathy @dewing

10

I think @Sam covered it pretty well regarding “stolen focus” - not much we can do about browser behavior - but thanks for sharing any workarounds you find!
A bit more information on keyboard events - the Python code on your virtual CodeBot is actually running in its own separate thread in the browser, a webworker. That means the code doesn’t have direct access to “window” stuff like keyboard events, etc. It really IS just “running inside CodeBot!” - so it gets the button-press and other simulated hardware events we send it from simulation-land, but doesn’t have access to anything we don’t provide to it explicitly. We were kinda strict about not giving the CodeBot python code access to anything a real bot wouldn’t have - alas, the keyboard is one of those things!

11

Thanks. It explains things.

PS Browser is extremly complex stuff. I’m amazed how well you did it.