+3 -3

_posts/2019-05-18-geoproject.md

reviewed

··· 4 4 --- 5 5 6 6 In February, our teacher for geography assigned a project in which every student had to ask his relatives where they have been in the Czech Republic and put it into a table (and also draw a map). I found that a bit boring, so I thought of a better idea: a fully interactive map made into a web application. First I wanted to use the lazy approach to do the project: [MapFling](https://mapfling.com/). Unfortunately, the website was down on the day I wanted to start on. So I opened my browser and searched for some good maps APIs. I didn't want to use the Google Maps API, because it's too expensive just for a simple project. Then I found an API from [OpenLayers](https://openlayers.org/) which looked ok for the job. The only drawback with this solution is that the design is not as modern as eg. [LeafletJS](https://leafletjs.com/). So I got to work and on April 11, I published the code on [GitHub](https://github.com/filiptronicek/Geo_cze) 7 7 - <img src="https://cdn-std.dprcdn.net/files/acc_754429/32jOsf" width="100%"> 7 7 + <img src="https://flpsawsmcdn.imfast.io/image_1_.webp" width="100%"> 8 8 9 9 I had to have the table with my datasets somewhere, but I found just letting the visitor download an Excell spreadsheet not suitable for my UX. So I had an idea: what if I made the table in HTML with ``<a> `` tags pointing to a function in JavaScript, which will generate an ``<iframe>`` with a Google Map showing the selected place? So instead of having the table manually written in I put the names of the places to JavaScript arrays (I was lazy making the arrays myself so I made a short Python script to sort it out: link [here](https://gist.github.com/filiptronicek/08301660a0a0be48ac67739240e9679e)). Then I grabbed every item from each array and added [this function](https://gist.github.com/filiptronicek/a1b0ac9444f63fe15264163aefaaa263). Then I just created the [about]() page and the project was done. You can check it out [here](https://geocze.netlify.com/) 10 10 11 11 - <img src="https://cdn-std.dprcdn.net/files/acc_754429/MOHvkL" width="100%"> 11 11 + <img src="https://flpsawsmcdn.imfast.io/Screenshot_2019-05-18-Zem%C4%9Bpis-projekt.webp" width="100%"> 12 12 13 13 - <img src="https://cdn-std.dprcdn.net/files/acc_754429/d4Jp4l" width="100%"> 13 13 + <img src="https://flpsawsmcdn.imfast.io/Annotation-2019-05-18-210453.webp" width="100%">

+3 -3

_posts/2019-09-14-roboschool_2019.md

reviewed

··· 7 7 last week, I was in Germany for a week at the Technical University of Chemnitz, where I was attending the project RoboSchool for the week. The goal for the week was to build a working robot from scratch. With that in mind, we started with soldering the parts onto the mainboard, which we then connected to an Arduino Uno. 8 8 9 9 10 10 -  11 11 -  12 12 -  10 10 +  11 11 +  12 12 +  13 13 14 14 15 15 Thanks to the [UNObot library](https://github.com/tuc-roboschool/UNObot) for the robot written by Florian Zylla, we were able to keep the code very easily readable. After a couple of hours developing and testing, we had to start all over again, because our code structure was just too sophisticated. We made a sketch and all the if statements were now far easier to understand. There was a parkour course, which we had to guide our robot trough. It was easy at first because we only needed to check if the robot is on a line and that was it. But then came the dashed lines. Most teams solved it with just letting the robot go straight when the sensors didn't see a line, but that was too bad for you know.... us, so we developed an Easy Exploring Algorithm (EEA). The point was to let the robot look around and if he doesn't see anything just go a little bit forward and repeat the process.