So iron and so nameless

    Hello, Habr! Autumn has come, the birds are stretching south, normal people are on the couch, and we, the “iron nameless direction” of the GoTo design research school, angrily murmur and bristle with soldering irons clasped in steel arms-wings, we stray into an armored wedge to fly on October 28 at Peter at the autumn school at ITMO .

    image

    Why iron, why nameless, and what will happen at school - about everything in order.

    About naming problems


    The word “robotics” is convenient: without clarifying the term, they can call a very, very wide class of devices and activities associated with these devices. This word contains futurism, progress, retro-futurism, nostalgia, a liberated person, a skynet, a enslaved person, nanotechnology and, probably, taking into account current trends, blockchain. In general, the word about everything and about nothing is a well-trodden common place.

    Bores with definitions are usually not held in high esteem, including when it comes to the so-called “educational robotics”. Being on the other side of the barricades, which is inconvenient to specify, we at GoTo, nevertheless, were puzzled by the question of a suitable name for that area, which was historically called the “robotics line”.


    The growth in the number of courses that are offered from each iron under this name has become so rapid that with the word "robotics" the average, normal person first of all imagines an article from Lego that travels along the line. “And you, therefore, are higher than this?”, The average, normal reader will ask. We will answer: “No, we are doing a little different (we will talk about this below) and we suffer from the fact that there is no such short name for this set of activities.”

    The phrase “Internet of things” is convenient: without clarifying the term, they can call a very, very wide class of devices and activities associated with these devices. We will not repeat ourselves, the thesis is clear: a common place and a contemptually protruding Bazarovskaya lip.

    The problem is complicated by the fact that the simple (without bells and cap) name of our activity in an extremely clear and peeled form will look recognizable, but extremely gloomy and very angular - like an APC in a parking lot in front of a supermarket. “The direction of applied radiophysics and electronics”, “The direction of digital signal processing” - do you feel how grimacing faces are in the sinister grimace of consumerism and marketing? You see how the fashionable young people jumping on the scooters and with spinners in their hands jumped out of the windows, looking at the light?

    Between this Scylla-Charybdis, we need to rake in the breaststroke: so that the name is recognizable, trendy (forgive me, Lord!) And bright, but at the same time, at least it should lie next to the area to be occupied.


    How we got out: we tried to be clever (“ferrum studium”) and joke (“digital-analog big top”). The manual says: they don’t understand this at all. And we answered: there, among the clear bioinformatics and data analysis we got a “black lambda”, you won’t even figure it out without footnotes, maybe it’s something venereal at all ... Well, okay, the leadership knows better.

    GoTo, autumn 2017, St. Petersburg. Robotics and the Internet of Things *


    * Before deciphering what is hidden behind this common place, I want to talk about an ideal spherical school in a vacuum. GoTo was originally a design school. That is, as a result of the participants' work, a product (software or hardware-software) is obtained that can be used. Often time is enough only for a hint, a certain outline of a product tucked up with a haze, but the story of how we extend the work on the project beyond the framework of the field school will be separate.

    The first thing the project needs is a task. In the ideal case, this is someone's real need. Not necessarily a “product for startup”, which should be released in a billion copies, the main thing is the presence of at least one future user with a need. It is not easy to get a real user whose task we can solve even in theory: 50% of such tasks will be cut off at the start by time and money restrictions, another 30% are boring for a teenager, they are most often not interested in heating greenhouses.

    The remaining 20% ​​are ours, with examples in the form of children's prostheses with Motility, box filling tracking systems for CharityShop, packaging machines, smart dumbbells for Intel and other projects based on participants' ideas.


    As if a paradox: the key moment of an ideal project is its reality (here Plato would howl, yes). If we, teachers or participants, begin to play an imaginary customer with an imaginary project, we have imaginary requirements, assumptions and concessions. The ultimate option is “a project based on four metal rulers and six wheels.” This is a tragic incident in recent history for which we are ashamed; we try to avoid such cases by all means.

    Another significant aspect is the input skill set of participants. There can be two extremes: we, teachers and curators, are practically not needed by the participant (this happened, you could proudly call yourself mentors rather than plow for both shoulder blades) or vice versa, the participant only heard somewhere about programming and tried a little ( the more people come to us, the more often this option occurs, which is natural, and absentee selection, alas, is not effective enough).

    An ideal case is a participant who is able to follow a jointly drawn up work plan, eagerly writes advice on checkpoints and asks for additional consultations.


    Due to the normality of the second extreme mentioned, at some point in our schools a stream appeared parallel to the project stream: the course of a young soldier.

    Since we are also bored, we implement practices aimed at minimizing downtime: we come up with ways to more accurately determine the level of the participant, we try to make combined KMB flows + project.

    This time, in the fall in St. Petersburg, we will act a little cruelly: no projects with imaginary customers and no KMB. To learn the basics, there are both online courses and a young fighter's course in the direction of applied programming, where you can learn about loops and branching without burdening with pull-up resistors and interrupts.

    At the autumn school there will be at least two projects covering the specific needs of specific companies. Of course, we will consider the proposals of the participants and take them to work. What will the rest of the time be devoted to?

    We decided to single out several (six) heterogeneous tasks that are not projects on their own (due to the fact that they do not solve anyone's problems), but can give either subsequently applicable knowledge in a fairly narrow area, or some kind of approach that can be apply to self-extraction skills. Looking ahead, we note that most of them involve combining with another task, so that the pangs of choice are less painful, and the activity becomes more diverse.

    Before moving on to the examples, let us leave a small remark-answer-clarification on the legitimate question “Why”? The fact is that any complex device is, in fact, an abstraction. An interface that conceals within itself complex and mysterious offal. C ++ is an abstraction that allows you not to access registers directly and not worry about stack integrity. An ultrasonic sensor is an abstraction that hides extremely difficult details of the propagation and reflection of sound. A car is an abstraction from the weather that makes it easy to conceal the space between two points.

    The problem is that there is a "law of holey abstractions", formulated at one time by the programmer Joel Spolsky: any non-trivial abstraction of a hole is leaking sooner or later.

    If you do not know how the sensor works, you can get an absolute mess instead of distance data. If you do not know how the car works (an abstraction that protects from the weather), then you can fly into a ditch, forgetting about aquaplaning on a slippery road.

    We want to slightly open the curtain of abstractions and slightly dig deeper into giblets.

    First, a little atmosphere.
















    Examples

    • Meticulous study of the sensor. Take, for example, an ultrasonic rangefinder. Standard practice: here are four wires, here is "Ultrasonic.h", at the output centimeters to an obstacle. Well, okay, we usually get more boring: we initiate the wave there with a strobe, the wave returns here, measure the pulse duration at the input, divide by a constant, centimeters at the output and go further.

      This time we will reach the limit of tediousness: correctly set up an experiment, reflection of a wave in various media from various obstacles located in different ways, studying a number of obtained values, filtering it.

      We believe that not everyone will be lucky only to use black boxes, someone will need to create and maintain them, and this is a step in this direction. In addition, victims of this task will have a significantly better understanding of distance measurements by ultrasound.
    • Another example: in a neighboring audience, where applied programmers are engaged, the computer that drives the code seems to be a given. We traditionally have to count bytes. The experiment showed that some of the teenagers want to penetrate the computer device, so this time we will apply logic to the transistors, assemble the gates from them, and then we will make different multiplexers and adders from the gates. This is equally far from the practically applicable project and the traditional course of the young fighter “about everything in the world”, but it is a rather narrow plot - we will try to discover a taste for this or at least to pull the curtain of magic.
    • Now it’s hard to find developers who do not use “cubes”. Neighbors in application programming take the web as whole frameworks. We will offer to learn how to study technology, taking for example BLE. It will not be “this is how bluetooth low energy works”, but “this is how we go to find out how bluetooth low energy works”. The output is knowledge of how it works, and how to go to learn another technology.

    If our colleagues have “closed the laptop - the workplace has been removed”, then we have the third wall, which limits the flight of project fantasy — iron, which costs money, takes up space and cannot be guessed in advance, if we focus on projects invented by children in the process brainstorming in the tavern "Matryoshka" .

    In our new format, we will do the opposite. Take, for example, Particle Photon as the starting point and consider everything that it can give us, take a walk on the platform along and across the manual.
    However, we will not disclose all the blanks.

    A meticulous reader will ask: “Well, inept participants have no place at the autumn school?” We will answer: "Some of our preparations do not imply any special requirements, but you should not expect that we will hug the immense for a week, conducting a full introductory course."

    If you have:

    • “Iron” needs that you have no time to solve - write to us, if the stars converge, we will need several hours of attention from you at the stage of torturing the user;
    • adolescents who do not yet know what they will do in the coming holidays - write to them to fill out an application for schools .


    Also popular now: