The libraries

Here are the contents of library.properties file of both libraries. I omitted the e-mail addresses of the authors to prevent spammers from getting hold of them. You can find the addresses in the actual library.properties files when you download the libraries.

name=WebServer
version=2.0.0
author=Ivan Grokhotkov
maintainer=Ivan Grokhtkov <(...)>
sentence=Simple web server library
paragraph=The library supports HTTP GET and POST requests, provides argument parsing, handles one client at a time.
category=Communication
url=
architectures=esp32

name=ArduinoHttpServer
version=0.10.0
author=Sander van Woensel <(...)>
maintainer=Sander van Woensel <(...)>
sentence=Server side minimalistic HTTP protocol implementation.
paragraph=Just the raw HTTP server protocol for the Arduino platform, the rest is left to your imagination.
category=Communication
url=https://github.com/QuickSander/ArduinoHttpServer
architectures=*
repository=https://github.com/QuickSander/ArduinoHttpServer.git
depends=Base64

Methodology

I created a very simple web application for the ESP-32, which has a testing endpoint that simply replies “OK” to every request, and also serves an index page with some JavaScript to generate a large number of requests for that endpoint. The script uses one of the two libraries depending on how you compile it. HTTPS was not used for testing.

The script was uploaded from a PC to my ESP-32-S2 Devkit, which was connected to my home WiFi. I ran the benchmark by navigating to the index page in Firefox on the PC. Both devices are about 25m away from the router, and the network environment is very much congested, which definitely impacted the results (this is not exact science).

I performed the benchmark by first compiling the script to use WebServer, and uploading it to the devkit module, then making two measurements: about 200 requests with interval 100ms, and then about 600 requests with interval 50ms. I later repeated the same steps with ArduinoHttpServer version of the script. I did not restart the module between 50ms and 100ms tests, but it was restarted between WebServer and ArduinoHttpServer due to a new script being flashed.

Results

Here is the combined screenshot of all the tests. It has one extra case, when I accidentally uploaded the WebServer version of the script with debug logging set to “Verbose”. I decided to include it just to show how much writing to the serial port can slow down the application. The benchmark script collected the following data (all time values are in milliseconds):

1. Requests: the total number of requests made during the test.
2. Errors: how many errors (!response.ok) were recorded during the test.
3. Time min: the shortest response time recorded during the test.
4. Time max: the longest response time recorded during the test.
5. Time avg: the average response time from the last 1000ms of the test.
6. Reqs/s: how many requests were handled in the last 1000ms of the test.

Conclusion

It looks like WebServer is a bit faster for this one specific use case that I tested. However, this was just a quick and dirty test, and I did not account for basically anything. The results I got may be distorted by WiFi congestion, devkit firmware quirks, me using the ArduinoHttpServer library in a suboptimal way, or many other factors.

The script

Click the link below to download:

Thank you for reading.

Consequently, this version only includes the station defense scenario, previously known as “demo 1”, albeit in two different variants. The remaining demos will come back as scenarios in subsequent releases.

Download links

1. 🠯 for Windows 
2. 🠯 for Linux

Download size: ~350MB

What comes next?

The current scope is to do a quality pass on the capital ship scenario (previously known as demo 3). I’d like to redesign this scenario to have more strategic depth, a bigger playing area, and some allied ships that can be commanded from the map screen. As always, I make no promises for the release date, but hopefully less than three years

What if I want to play the other scenarios?

The previous version from 2019 has all three scenarios, and can be downloaded here:
( 🠯 for Windows | 🠯 for Linux | 🠯 for Mac ) [~120MB]

Where’s the Mac version?

The Mac version is no longer being actively released due to lack of interest. If you’d like to play ATW on a Mac, please let me know and I’ll build it for you.

Why no release?

The latest version of ATW was released in May 2019. That’s really a long time ago. The year 2019 saw a lot of major new features, like for example the new AI, sensor & comms systems re-work, introduction of the map view, and many graphical upgrades. In contrast, 2020 and 2021 were very difficult years for me personally, so little work was done. What’s worse, all those major new features brought new bugs, broke existing missions, and the new “command demo” turned out to be no fun after all. To be honest, I believe that all of the missions are pretty underwhelming. They were good content placeholders while the game was new, but they need major re-work to be actually engaging. So, even though I started 2022 with some good progress on stabilizing the game, as of today it still remains un-releasable.

When release?

I intend to move forward with the following plan:

1. Finish up the work on the “missiles” milestone,
2. re-work all 3 missions,
3. stabilize and release.

This is a lot of work, so no promises on when that happens.

What’s wrong with the missions?

For starters, the AI improvements made the missions much more difficult, as the computer opponent can do much more damage even with the pitiful ships it’s given. It doesn’t help that many of the game features are still in placeholder state, and that some of them are poorly written, make incorrect assumptions, or are just really old.

The fighter demo simply spawns new foes until either the player’s ship or the space station is destroyed. It gets pretty boring after a minute or so. I’d like to have more types of enemies, and for them to come in increasingly stronger waves, and for the player to be able to repair and upgrade their ship between the waves.

The exploration demo is just plain boring, and that’s a huge disappointment given the amount of time and work that went into making it. The exploration ship should be made much faster, and the solar system more lively, with more clues for finding things, and the pirates should also be more pro-active in preventing the player from finding their base.

The capital ship combat demo needs a lot of re-balancing. While the mission itself is pretty fun, the uphill battle against the pirate cruiser is still not quite living up to my original vision. The bigger ships and their turrets should have more health, and I’d like to increase the scale of the battle too.

That’s it. Thanks for reading.

This game wasn’t my idea

So, a while ago (9 years to be exact) I wrote a browser game to teach myself JavaScript. It was a remake/re-interpretation of a text mode game “ATC” written by Ed James in 1987. It was about controlling air traffic in a given area. Planes would enter the game board through exits or spawn at airports. Each plane had to be carefully guided to its destination, which could be either an airport or an exit. The player command the planes, so that they would reach their destinations, without crashing into each other. The game was remarkably fun, and can still be played today. If you happen to be on a Debian-like operating system, you can get it by installing the bsdgames package.

The 2011 remake

My 2011 remake was a browser game written in JavaScript, and I based it around the Canvas element, which was a very new thing back then. It followed the original gameplay very closely, while introducing very simple graphics and small quality-of-life improvements. The game was controlled exclusively with keyboard, just like the original.

While I did learn a lot about writing JavaScript while making the game, I was never truly happy with how it turned out. The graphics was plain ugly, with small hard-to-read labels. When two or more planes got on top of each other, it was impossible to know which ones they were and where they were headed. The keyboard input system was very confusing to modern players, who were used to clicking everything with mouse. There was also no visual indication of which plane you were commanding, and if the command was actually accepted. Combine this with lack of tutorial, and the only way to learn this game was to have someone standing over your shoulder explaining the game as you played it. The code itself wasn’t that horrible for someone self-taught, but it didn’t escape from some anti-patterns, which made it difficult to find and fix bugs. Two major bugs remain up to this day: it’s possible for a plane to leave the game area through its southern edge and keep flying until it runs out of gas; it’s also possible for planes named “I” and “l” (capital “i” and lowercase “L” respectively) to both appear on the board at the same time, confusing the players. I attempted to fix the problem twice, both times without success. The game can still be played here.

The 2020 remake

My motivation for re-making this game again was mostly because I really liked the idea (which by the way is attributed entirely to Ed James), and I thought the game deserved a remake that was actually good. Therefore, I decided to spend a couple of days recreating the game from scratch, using modern technology.

The 2020 version features improved graphics with animations, a mouse-controlled interface that’s hopefully easy to understand, and several tutorial scenarios that gradually introduce all gameplay aspects and rules. One very big change is that airplanes actually fly across the board in real-time, rather than making chess-like movements that were characteristic to the original game. As a consequence of this, it’s possible to have many different kinds of airplanes that cruise at different speeds. The game is still based on a square grid, though unlike the original, planes travelling diagonally will take more time to reach the next square than those travelling horizontally or vertically.

Another big thing is a white line that predicts the path that an airplane will take. It’s only displayed for the currently selected airplane and goes through all squares the plane will travel through in the future. It’s also used for issuing delayed commands for planes passing over radio beacons and airfields. The line makes it easy to see whether a diagonally-travelling plane is actually lined up with its exit or not. The line is so useful in fact, that it made me realize some things about the default map from the original game that I hadn’t known about, like for example that airport A0 is located diagonally from beacon B0. Its most important advantage however, is that it shows you immediately how your commands affect a plane’s path.

I realize of course, that to make it a true product of 2020, I should’ve made it into a mobile game with touchscreen controls. I chose not to do so because a) I’m not very fond of mobile games, and b) real-time strategy games such as this one work very poorly on small screens with touch controls. Therefore, I envisioned this game to be played exclusively on a computer with mouse. Of course it’s theoretically possible to load it on a mobile browser, but I imagine the experience would be nothing but frustrating.

The game is written in TypeScript, which is compiled and packed to a minified JavaScript file with webpack. Other than some webpack loaders for development, I did not use any libraries or frameworks, so the game is very light-weight. The minified .js file currently sits at 127KiB, and can likely be reduced further by cleaning up the SVG assets.

Enjoy playing.

Progress is slow but steady.

A map with RTS-like controls for allied ships is the main new feature. Making sure that various things work well with map (for example the nebula from Exploration Demo) is taking more time than anticipated.

I made a new “Command Demo” to showcase the map feature. It has the player use a small fleet to protect several unarmed ships that explore a star system. I’m not happy with how it turned out gameplay-wise, and now I’m considering extending the Starship Battle Demo with tactical elements instead.

Another big thing going on is integration with a graphics toolkit for greatly improved visuals of planets and the outer space. Also, some better music.

I’d like to make a new gameplay video soon, as the 2019 one is becoming quite outdated.

Missiles are next in the queue. I’m looking forward to making some highly destructive warp-capable torpedoes. These should be effective against very heavy and cumbersome ships, and maybe also some of the lighter ships that are caught with their warp power recharging.

That’s it for now. I’ll try to go for a less-than-one-year interval for future updates.

“…but then I noticed a stack of smoke coming up from behind the screen. I stood up and looked at the mill. The probe cable was melting before my eyes. I rushed screaming to the power switch…”

While playing around with mine, I managed to damage it by accidentally applying high voltage to the “probe” terminal of the module. This caused the module’s microcontroller chip, an ATmega 328P to malfunction, and no longer respond to GRBL commands, effectively turning the machine into quite an expensive paperweight. Thankfully, I was able to replace the broken chip, and even program the replacement with a more recent version of GRBL firmware.

The trouble started when I first attempted to use a probe to generate a height-map of a copper laminate board. When making circuit boards, we want the mill to remove the ultra-thin layer of copper in certain places, while leaving intact as much of the underlying laminate as possible. Moreover, the board is never laid exactly level on the machine’s working area because of clamps holding it down. The difference in height sometimes can’t be seen with naked eye, but is guaranteed to be much larger than the thickness of the layer of copper that we want to remove.

The height-map approach solves this problem by having the machine take very exact height measurements at multiple points across the board. During a single measurement, the machine’s head is descending very slowly until it touches the board. Then the software saves the exact height at which contact took place, and then the machine makes another such measurement in another place.

How does the machine tell that its tool is touching the board? The most common way is to attach electrodes to the tool and to the board itself. If the tool is touching the board, an electrical connection is made between the electrodes. This can be used to tell the machine that it’s reached the board. The woodpecker control module supports probing in a very simple way: one electrode is attached to the ground terminal, and the other one to the A5 pin on the module.

There’s a terrible catch however, and if unlike me you take the time to actually read the instructions, you’ll notice they want you to disconnect the spindle motor before attaching the probe electrodes. Why? Well, the spindle motor is connected in such a way that the positive terminal of its power line is connected to the motor’s casing. This means that the motor, its shaft, and the tool itself (!) has a potential difference of some +12V with respect to the module’s ground.

Now, what happens if you attach the probe in such conditions? The first thing that I noticed was that the spindle motor started spinning as soon as the alligator clip touched the tool. Thinking it was some software problem, I walked over to the computer intending to stop the spindle. I thought it was odd that bCNC claimed that the spindle was stationary, but then I noticed a stack of smoke coming up from behind the screen. I stood up and looked at the mill. The probe cable was melting before my eyes. I rushed screaming to the power switch. After ventilating the room, I ended up with melted isolation on the probe wires, and a non-responding control module.

What happened electrically was that the high voltage from the tool found its way to the ground through the alligator clip and the cable leading to the A5 pin on the control module, and finally through the microcontoller. The flow of current caused the motor to spin, even though it was not commanded to. Poor ATmega was not designed to have such high currents passing through it, so it must’ve broken down almost instantly. The current was also too high for the probe cable, which ran so hot the isolation was melting.

Lesson learned: Always check the voltage before making an arbitrary connection in a circuit you don’t know very well.

The good news was that the stepper motors, the spindle, and other parts of the control module appeared to be undamaged. So, I thought, perhaps the module could be saved by just replacing the ATmega? I’d have to program it though, but the Woodpecker is running GRBL, which is free software, and I found a discussion on the Internet (a gold mine of information, BTW) where people reported they were able to flash a more recent version of GRBL to the very same Woodpecker variant that I broke, so the plan didn’t seem impossible.

Since I didn’t have a spare ATmega on hand, I tried playing around with the broken chip first. I discovered that it was running very hot as a soon as power was switched on, suggesting a short-circuit. I guessed it was the pin that was connected to the probe when the accident happened, but I was too lazy to verify it with a meter. I extracted the ATmega from the module with the help of some hot air, and then managed to bend the offending pin slightly. Then I connected the power while pressing the chip to its footprint on the module. It became hot in an instant, so I decided to give up and wait for a replacement microcontroller.

When the replacement ATmega arrived, I promptly soldered it to the board, first with hot air and then touching every pin with soldering iron. I connected my Arduino Uno to act as a programmer, with connections just as shown in the blog post. I loaded the Adafruit In-system programming sketch, and tried to connect to the Atmega with avrdude. Unfortunately, avrdude could not read the device signature correctly: it was reading different gibberish for each attempt. I checked the connections with the meter and found a 100Ω resistor between the MISO pin and the connector. I wondered if it was messing up the timing.

I reloaded the Adafruit sketch with “slow mode” switched on and my suspicion proved to be correct – this time avrdude was able to read the device signature and even the fuse bits correctly. Unfortunately, the sketch did not support programming the flash memory with this speed, so I had to find something else. A brief search on GitHub turned up DEPlayground fork of ArduinoISP, which supports variable programming speed. Even its default setting was enough for the ATmega to catch up, and I was able to flash GRBL version 1.1 (an improvement over the board’s default v. 0.9) successfully. Now, what about the fuse bits?

Someone in the gold mine thread managed to read the fuses from an undamaged board, and the value was zero for both high and low fuses. This seems highly improbable, as such configuration would disable in-system programming, and also the reset pin. The presence of a reset button on the Woodpecker board strongly suggest a non-zero value for the high fuse at least. Perhaps some lock bit was making it impossible to read the fuses? I tried flashing various fuse bit combinations with various clock settings, but ATmega was showing no signs of life.

In desperation, I flashed the Arduino bootloader to the ATmega, followed by a sketch that would constantly output noise on the serial port, with various baud rates. None of it had any effect and the serial monitor remained stubbornly silent. In the end, I flashed the following values: 0xE2 for the L-fuse, and 0xDA for the H-fuse. This configuration used the microcontroller’s internal RC oscillator as the clock source, so it should “just work”. Then I flashed the GRBL again, disconnected the programmer and went to sleep.

The following day, when I got around to messing with the Woodpecker board again, I started with simply opening the serial port. Lo and behold, I was greeted with GRBL prompt! Perhaps severing all connections to the programmer board did the trick, I thought that just disconnecting the “slave reset” signal would’ve been enough.

Anyway, I reconnected the stepper motors and the spindle (gulp!), and ran some basic tests with bCNC. Everything turned out to be working fine, except for the x-axis motor – it was making noise, but not actually moving in either direction. Suspecting a cold solder, I’ve decided to reflow the ATmega. I applied generous amount of solder paste, and then proceeded to re-solder every single pin on the microcontroller with fresh tin. I made several short-circuits, and even partially melted the x-axis driver socket in the process. Oops. After fixing collecting the solder blobs and making sure the socket was still conductive, I reconnected the motors once again. This time everything was working correctly. What remained was the GRBL settings.

Someone posted the defaults for CNC1610, my model exactly, in the gold mine thread. I took the opportunity to modify them a bit: my machine is still new and not oiled very well, so the motors tend to skip during acceleration and deceleration. The problem was fixed by applying more conservative top speed and acceleration limits.

So, in the end I was able to not only recover my Woodpecker module, but also improve it with a more recent version of GRBL as well. In the process I learned a lot about using an Arduino for programming another board. I also managed to get the probe working, and I won’t be forgetting to disconnect the spindle before attaching the probe any time soon!

Resources

1. [INFO] The gold mine thread
2. [INFO] Connecting Arduino to Woodpecker CNC
3. [LISTING] My GRBL settings
4. [LISTING] DEPlayground’s Arduino in-system programming sketch
5. [TOOL] Atmel AVR fuse calculator
6. [DOCS] ATmega 328P datasheet
7. [DOCS] Arduino Uno pinout
8. [INFO] Upgrade your CNC
9. [INFO] AVR Programming with Arduino
10. [INFO] About Arduino ISP and bootloaders

Download:
All These Worlds Tech Demo collection (for Windows | for Linux | for Mac ) [~120MB]