Ant-ology

Following up on cellular automata after my previous Game of Life project, I sort of rediscovered Langton’s Ant. It’s another example of extremely simple rules, leading to some intriguing arm wrestling between order, complexity and chaos.

Langton’s ant lives on an infinite grid of squares. Every next move it makes is determined by these simple rules:

  • If it’s on a black square, it turns left and moves to the next square in that direction
  • If it’s on a white square, it turns right and moves to the next square in that direction
  • The square it moves from reverses color

The grid size needed for properly simulating the process made me use a Wemos D1 R2 board instead of my faithful Arduino Uno. This first sketch is as simple as the ant’s rules. It maps a 106×160 cell grid on a 320×480 pixel display (3×3 pixel cells).

Infinity of the grid is simulated by ‘folding’ it in both dimensions (toroid shape), so the famous ‘highway’ will lead the ant back to its self created chaos, from where it will try to build new highways.

Meanwhile, I’ve developed some multi-ant ideas, so more sketches may follow.

 

(For this video, I started with an all black grid and removed the delay at the end of the loop() function in order to turbo-boost the ant)

 

 

Real Virtuality (RV)

Just a thought that crossed my mind: in today’s Virtual Reality, computers are used to simulate reality in a virtual setting, but when the first computers became available in the 1940’s, they were used by mathematicians for exactly the opposite.

For centuries, they had been creating all kinds of virtual worlds inside their minds, supported by little more than paper or a blackboard. Mind games, where everything was allowed, as long as you could prove it from self-postulated axioms. The principle of fractals or the concept behind cellular automata, for instance, had already been developed long before their fascinating complexity could be visualized.

[Kurt Gödel*, wearing 2D glasses]

The arrival of computers offered previously unthinkable possibilities to visualize these virtual worlds ‘for real’ (Real Virtuality…?). By studying the results, scientists developed many new insights and ideas. Nevertheless, true geniuses obviously don’t need VR or RV. Kurt didn’t even use his blackboard…

 

* Kurt Gödel was an Austrian mathematician, most famous for his Incompleteness Theorem.

 

 

 

 

 

 

What’s up?

Sitting on my balcony on a cloudless day, I can see airplanes passing by almost every single minute. Where do they all come from and what’s their destination? Sites like fligthradar24.com can tell, but wouldn’t it be great if real time air traffic information would be freely available on the Internet. It was after discovering global.adsbexchange.com that I realized that, in this respect, the sky is not the limit!

Sending a request to their REST API will return a JSON-formatted response, containing flight data on all planes within the scope of your request. Here you can find a full explanation of the request parameters, as well as the returned data.

[Text-based prototype; see also the graphical prototype and the final touch screen version]

Reading JSON on-the-fly

Because the JSON response string will contain full information on all planes within the requested scope, it’s likely to be too large to be stored in memory. That means that  information of interest has to be extracted on-the-fly (how appropriate!). This requires a parser that processes the JSON response as a stream.

First I tried this generic JSON streaming parser, ported from php to esp8266 by Daniel Eichhorn, who uses it for his far more ambitious PlaneSpotter project. Although that parser worked great, I ended up writing my own “ultralight” adsbexchange parser, basically just for fun. It uses an array to store the names of keys that you want to extract, making it easy to configure your sketch according to your needs.

 

Displaying values from the JSON response using the Adafruit_GFX library (not trivial…)

In order to properly display special characters in the names of airfields, airplane models or operators, you must first realize that the JSON response is utf-8 encoded, whereas the GFX library expects extended ascii compliant with “Code page 850” (aka Latin-1).

A commonly used solution, proposed in the Arduino Playground, still produced lots of wrong characters because it was written for a different code page, so I had to write my own print_utf8 function for translating utf-8 encoded characters to the correct extended ascii equivalents, if they exist.

Secondly, many characters can appear in the JSON response that don’t have an extended ascii equivalent (mostly Cyrillics). My function will ‘romanize’ them (i.e. remove their accents, preserving their case). A two dimensional translation table transtables is used, stored in PROGMEM (see sketch).

The image below shows the correct codes for all characters that can be displayed by the Adafruit_GFX library (Code page 850 – Latin-1 ).

[code table for the Adafruit_GFX library]

 

The sketch

The example sketch below is for esp8266 based boards (I used a Wemos D1 R2). It monitors up to ten airplanes within 35 km distance from a given location, showing up to five of those on a 480×320 TFT display. Flight information is updated every 5 seconds.

Just for this post, I’ve put everything in one long sketch that shouldn’t be too difficult to grasp though, due to the section layout and many comments. Don’t forget to change WiFi credentials and parameters of the url in the WiFi Stuff section of the sketch, as well as display specific lines.

Note: As a next step, I made a graphical version, showing planes moving over a map. Then I finished this nice project with a touch screen version.