IOT Projects

Keyboard Jiggler with Python and Raspberry Pi

So I did a pretty simple but amusing little project recently, a bit on a whim. Let’s say, I have a few games that it would be useful to just, let idle for experience or whatever. The problem is, that these games also have built-in idle deterrence. Your character falls asleep, or you just time out of the game after five or ten minutes.

I initially start off trying to use AutoHotkey, a program that basically does what I wanted here, you program it to press keys at certain intervals, basically just a simple keep-alive movement every couple of minutes.

It turns out, at least one of these games detects Autohotkey as a cheat, and won’t launch when it’s running.

I got to thinking, I could probably program one of my Arduino boards to emulate a keyboard. And sure enough, there are libraries for this very task. Then I discovered that, the keyboard library does not work on my old Uno boards. But I found an alternative route with my Raspberry Pi Pico that I picked up a few years ago. The Pico could probably do what I needed as well.

After some digging online, I found plenty of guides on how to build a full-sized Keyboard using GPIO pins on the Pico, but nothing quite exactly what I needed, but there was enough Python Code available, I could figure it out pretty easily by stripping apart some full keyboard code. Instead, I just started with a simpler macro button keyboard script. Most of the scripts I came across have code to detect and save a button press, then send the command using the Python Keyboard library. I just stripped all that out and put it on a timer loop with some simple, regular input. A set of repeated w presses, follow d by repeat d presses of a, s, and d.

Essentially, “walk in a little square loop.”

Step one was to set up Circuit Pi on the Pi Pico, which is detailed here, though only the initial setup is needed.

The test using Notepad worked perfectly, aside from one annoying issue, I could not easily edit the code while the device was plugged in, because the test loop would spit out wwwaaasssddd every 5 seconds.

After some careful quick timing, I adjusted that out to every 300 seconds (5 minutes).

It was time to test things out. Before work, I set the game running and the keyboard Jiggler working. When I came back later it was working just fine.

But there were some issues, one of which I could mostly address.

Firstly, the thing just runs, forever. It doesn’t really need to, I only need it going for around 3-4 hours. I added a counter variable to the script that would count how many runs through the loop had occured, and if it was more than a set amount, it would break the loop, which would stop the scripted movement and idle out of the game.

The other two issues are less easy to solve.

One, I had a thought that I could remote to my PC and swap games halfway through the day (at lunch). Except when you leave Remote Desktop, it locks the remote PC. Meaning the game loses focus and the keyboard Jiggler stops working. It’s literally a hardware device that pretends to be a keyboard.

The second issue, that could be easy to solve with some habit changes. I, very often, will use Firefox’s Tab Share to send tabs to either my desktop or my laptop. These are articles I want to clip and save, something I may want to buy later, notes for some projects I had done. Basically, it’s a way to send myself a reminder of something I don’t want to deal with on my phone. When I send a tab, on the remote machine, Firefox pops up and takes focus, meaning, once again, the game idle breaker stops working and it idles out.

The solution here is to just, get into the habit of only sending tabs after noon or so.

Another little improvement I added was a bit of randomization. I am not really worried about “detection,” but it’s easy to avoid by simply, adjusting the 5-minute timer to be random movement between 4 and 5 minutes, as well as randomizing what the movement is a bit.  I also added a bit of correction if the player moves too far away from the starting position.

Anyway, the script below is the completed script.

import time
import random

import board
import digitalio
import usb_hid
## Aquired from https://github.com/adafruit/Adafruit\_CircuitPython\_HID
from adafruit_hid.keyboard import Keyboard
from adafruit_hid.keyboard_layout_us import KeyboardLayoutUS
from adafruit_hid.keycode import Keycode

time.sleep(1)
keyboard = Keyboard(usb_hid.devices)
keyboard_layout = KeyboardLayoutUS(keyboard)  # We're in the US :)
led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT
total_runs = 0
running = True
# This is the choices for keys to randomly choose from, this is standard WASD
# This could be changed to be whatever to choose from.
keyOptions = ["w","a","s","d"," "]
# "Starting position" is set to 0,0
position = [0,0]

while running:
    # Turn the LED on while doing things
    led.value = True
    
    # Randomly choose 20-50 as an amount of key presses to do
    howMany = random.randint(20, 50)

    for i in range(howMany):
        # For however many key presses, pick a random one and press it
        nextKey = random.choice(keyOptions)
        keyboard_layout.write(nextKey)
        time.sleep(1)
        # This incriments the position above from 0,0 to track how far from start.
        # This whole section could be omitted if movement can be unconstrained
        if nextKey == "w":
            position[1] +=1
        if nextKey == "s":
            position[1] -=1
        if nextKey == "a":
            position[0] +=1
        if nextKey == "d":
            position[0] -=1
        
        # If we get too far in one direction, correct it by moving back to 0.
        if position[0] >= 10:
            keyboard_layout.write(ssssssssss)
        if position[0] <= -10:
            keyboard_layout.write(aaaaaaaaaa)
        if position[1] >= 10:
            keyboard_layout.write(dddddddddd)
        if position[1] <= -10:
            keyboard_layout.write(aaaaaaaaaa)

    led.value = False
    time.sleep(0.1)
    keyboard.release_all()
    # Sleep a random number of seconds between 200 and 300 seconds
    nextSleep = random.randint(200, 300)
    time.sleep(nextSleep)

    # Incriment how many runs have been done
    total_runs = total_runs+1

    # If the total runs is too many, break the loop and essentially "stop".
    if total_runs > 48:
        running = False

Arduboy FX

I recently picked up a neat little device called an Arduboy FX. It was a bit of an impulse buy after someone posted about getting one on Threads. It turns out it’s not actually particularly new, the community goes back quite a few years, but it’s still pretty cool none the less, and I am happy with my experience with it.

So what is it? It’s a small credit card sized handheld based on the Arduino. On a related note, it’s “credit card sized” in footprint, not so much in thickness. I wouldn’t trust putting this in a wallet at all, because I feel like my fat ass would snap it if I sat on it. The form factor is worth mentioning though. Traditionally for handhelds, I prefer the “larger options”. I had the full sized 2DS, and the XL 3DS and the large wide Retroid, and I just like, more hand real estate. Despite the Arduboy’s pretty small size, it’s still surprisingly comfortable and I don’t have any problem using it.

Also, the platform itself is open source, so one could buy components and just, build their own, if desired.

This specific version, the Arduboy FX, is different from the older original release, simply called the Arduboy. I believe the main (and possibly only) difference is that the FX includes an add on FX chip and has 200+ built in applications and games. When I ordered mine, I noticed that they sell just the FX part as an add on for the original Arduboy. They both play the same games, but the original can only play one game at a time, whatever is loaded onto it from the Arduino software. You can still load custom games to the Arduino FX.

One thing I want to mention, because it was the first question I had. What happens to the default games when you load a custom game. the answer is, they are all still there. When you upload a custom game or code from the Arduino software, the new game will load, unless you select a game from the included games list. If you choose and load another game, it will overwrite the custom game. I believe there ARE ways to overwrite the original 200 games firmware, but the standard method of upload through the Arduino IDE, does not.

As far as I can tell, most of the worthwhile available games are pre loaded on the Arduboy FX. Basically everything about this is open source in nature. I’m not going to cover any real specifics of the games here, I may do that later over on Lameazoid.com though.

The fun part here is developing games. There is a great multipart tutorial available here, though the last two parts to build Dino Smasher are not complete. The Arduboy is based on C and C++ like the Arduino is. It uses a special library to work the Arduboy functions for button presses and graphics. The tutorials are good and could be done by someone who has no programming experience, though I’ve had pretty extensive experience at this point and they were a nice refresher for my C/C++ knowledge, which I have not used in almost 20 years.

I don’t recommend the other tutorial path though, for the platform game. I’ll be blunt, its presented as beginner-ish, but it’s quite a few levels above the first set of tutorials. It introduces a lot of much more abstract coding concepts. It’s probably good information, but it’s kind of beyond a basic level and many of the comments in the community expressed as much. I was a bit worried when right out of the gate it’s starting with various types of int (integer) variables which can be used. I mean, that’s all great to know, but for the purposes of anything made here, just using int, is going to be fine.

I went through the first tutorial set myself, and built the Pong Game. This is the second time I’ve made Pong funny enough, the first being in Python. After finishing the tutorial, I went through and added a bunch of additional features. Most were things done by other commenters, but rather than pick through their code, I just made a list of ideas and added them all in. I’d recommend it for anyone looking to test their ability a bit beyond this Tutorial, especially if you have some coding ability and want to flex yourself a bit. Here is a little list of suggestions.

  • Add a pause option (easiest is when pressing A during a game)
  • Add a more complex Title screen and End Screens
  • Add a “net” line down the middle.
  • Add an ability to adjust the paddle size (this will probably also require adjusting the AI sensitivity to make the game winnable)
  • Add the ability to select how many wins are needed to win
  • Make the game a bit better by offsetting the ball starting location after scoring.
  • Make the game a bit better by starting the paddles in the middle (The AI tends to miss the first 2-3 shots right out of the gate otherwise)
  • These last couple will need to be added to the title screen.

Anyway, My finished code can be found here.

I’m pretty happy with the result. I’m looking a bit into how to embed these games into my website here, or on my Github.io page. Until then you’ll need an Arduboy to actually run the code.

I’m not sure what I want to do next yet. I may make a go at building a simple Tic-Tac-Toe game, from scratch, just to have a simple project to test my coding chops without using a Tutorial as a base. After that, I am thinking of remaking one of the first games I ever made, a simple text based RPG I had made back in High School called Dragon Quest.

Dragon Quest was vaguely based on Dragon Warrior, which at the time, I didn’t know was actually called Dragon Quest in Japan. The game itself wasn’t actually anything LIKE Dragon Warrior though, it just, was fantasy based, and had Dragons, and the name “Dragon Warrior” was taken. (and like I said, I didn’t know at the time Dragon Quest was ALSO taken, by Dragon Warrior). That game, would be well suited to remake for the Arduboy though as it too was for a simple 2 color platform, I had built it on my TI-85 Calculator. Unfortunately, I don’t have any of the code from it. A lot of people in school had gotten copies of it on their own calculators, and Iw ould get copies back after school forced my calculator to be wiped for tests, to prevent cheating. Also, my calculator is 25 years old now, so the memory has more than wiped itself. I did eventually get a TI-85 data cable, but not in time to save my RPG game code. But I still have a basic idea of how the game worked.

I may try to make the “first game”, which was just a loop of battling and healing in town, with two monsters and an end boss. Then expand it to be more like the second game which was similar, but added equipable items, more monsters, and just more complex game play. If that works out, I can try to add in the map system I had planned to use for a 3rd iteration, written in C, that I had never finished. I do have the code for that floating around.

Battery Testing with Raspberry Pi

Recently I purchased a portable phone battery on clearance. I want to use it to modify my defunct Pokemon Go Gotcha band, which no longer holds a charge, to run off the battery pack. I realized that a battery pack could also be useful for powering other small electronics, such as the Raspberry Pi.

The problem is, I wanted to get an idea of how long the battery would last powering the Raspberry Pi. Figuring this out isn’t really all that hard. The tricky part is that I can’t stand over the Pi and watch it until it dies.

So instead I set up a simple cronjob task to do the job for me. I had a spare SD card, so I threw a basic fresh install of Raspbian on the card. I configured SSH and WiFi, then did a quick run of “crontab -e”, then droped the following at the end.

*/5 * * * * date >> /home/pi/date.txt

Simple.

Every 5 minutes, the Pi will now write the Date and Time to the file “date.txt”. It will do this until it can’t which would be after the battery dies, killing the Pi.

After charging the battery pack over night, I stuck the Pi on it and left it.

After checking back periodically, when I found the Pi was dead, I plugged it into a regular power source to retrieve the data. The result were both better than I had hoped, and not as great as I had hoped. The Pi started spitting out Time Stamps again after I plugged it back in, so I ended up having to skim through the file to find the time gap. I went ahead and truncated the data down to hour stamps until I came across the time jump from when the Pi had died and when I had plugged it back in.

So it turns out that the Battery pack will drive power for the Pi for around 12 hours. I also want to test this under a bit of a load and test how long it will power an Arduino writing to a remote database.

A Pile of Used Tech

I recently had an idea occur to me that I might be able to pick up used Raspberry Pis off of eBay more affordably than buying them new. I didn’t really find a ton of savings, but I did pick up an auction for a lot of various parts for fairly cheap.

I am not sure what I’m going to do with all of this, but it seemed like a deal for around $50. I was worried that it wouldn’t all be included, but it was. Not everything is what I had hoped though. Two of the three Raspberry Pi 2s seem to be dead. I’ve tried several trouble shooting methods so far. They turn on, but don’t seem to real SD cards at all.

The arduino is a genuine Arduino, which is nice, but its a fairly older model. Not a huge issue, but it is what it is. The screens were a nice bonus. I’ve been looking into getting a screen of some sort of my Pis, possibly for a RetroPi handheld build. I have not tested the larger screen yet, it seems to work off of a funky daisy chain of an extra board and some cables. I did get the smaller screen working… ish.

It’s a nice little touch screen that fits nicely on top of the Pi. I have not had a chance to properly troubleshoot it, but the touch works kind of funky on it. For one, it seems to function more like a track pad than a straight touch. Two, the mouse cursor only wants to move along a diagonal axis across the screen.

This all kind of feels like a configuration issue however, so there is some hope. Plus I am not sure I really need a touch interface for a RetroPi handheld build.

There’s some other fun stuff that I have not had a chance to mess with yet. There were a ton of ultra sonic sensors. I’m not sure what exactly these could be useful for, but I am wondering if they would be able to do 3D imaging of an object or a space.

There’s some funky board with a digital display on it that seems to be some sort of power board. I am not sure I’m going to have a use for this at all.

Lastly, there is a Raspberry Pi camera module. I have not had a chance to test it out yet, but like the screen, this was something I’ve been wanting to try out.

Saving a Slice of Raspberry Pi

Raspberry_Pi_LogoSo of all the things on the network, the DNS and DHCP server are pretty important.  Especially because my experience has been the router the ISP provided is kind of mediocre at doing the DHCP job.  So when the Raspberry Pi I’ve tasked with doing the work started flaking out I was a little worried.

After some investigation, it seems the SD card had lost a sector, or whatever the equivalent thing is to a sector on flash memory.  These things do have a bit of a limited life and this particular one was a small 4GB card that was a little older.  Four gigabytes isn’t even above the recommended size for the Pi, but I knew I wasn’t planning on putting a lot on it.  Problems arose when it started dying though.  There actually isn’t much using the PiHole, some of the things my wife does with coupons and such I suspect might get blocked and I don’t want the headache of dealing with trying to manually whitelist things and complaints that this and that isn’t working.  The DHCP is another issue.  When the DHCP server disappears, it seems anything using it simply can’t connect to the internet.  I have a lot of static assignments but there’s quite a few assigned by the server.

I may have to look into setting up a secondary backup server, maybe on one of the CHIPs even.

I started out simply re-imaged Raspbian onto a fresh card and setting things up again following the tutorial I had posted.  Everything went pretty smoothly except that I was now out my old config file and would have to go through the hassle of recreating all of the changes I’d made adding and removing devices.

So I went with a new strategy, why not just clone the old card to a new one.  Unfortunately, Win32 Disk Imager, the recommended tool for imaging these SD cards, couldn’t read the whole card, it got hung up and failed partway in.  So I turned to my laptop and Linux hoping for something more robust, which I found in ‘dd’.  It probably stands for “Disk Duplicator”, but don’t quote me on that.

I started running dd to make an image of the old card to put onto a new card, unfortunately, it also failed, like Win32DiskImager.

Back to Square One…

After some searching, I found this post suggesting something called ddrescue.  Most of it wasn’t anything I needed aside from the following.

sudo apt-get install gddrescue
sudo ddrescue -v /dev/sdb /dev/sdc

A few things of note.  My laptop, like many, has a build in SD slot, I added a second using my USB card reader.  I opened the disk manager to get the path to each card, /dev/sdb and/dev/sdc.

This command also hit an error at the same point as both Win32DiskImager and the “dd” command, but it pushed on through, recovering everything else.  At this point it’s a matter of hoping that one bad spot wasn’t int he middle of an important file.