For many years now, people have been improving their tools, studying the forces of nature and bringing them under control, using the energy of the nature to operate their machines. Last century is noted for the creation of machines which can operate other machines. Nowadays the creation of devices that interact with the physical world is available to anyone.
Our course consists of a series of practical problems on making things that work independently: they make their own decisions, act, move, communicate with each other and people around, and control other devices. We will demonstrate how to assemble such devices and programme them using the Arduino platform as a basis.
After this course, you will be able to create devices that read the data about the external world with a variety of sensors, receive and forward this data to a PC, the Internet and mobile devices, and control indexing and the movement. The creation of such devices will involve design, the study of their components, the assemblage of circuit boards, coding and diagnostics. Along with the creation of the devices themselves, you will perform visualization on a PC, create a web page that will demonstrate one of your devices, and figure out how an FDM 3D-printer is configured and how it functions.
Besides those keen on robotics or looking to broaden their horizons and develop their skills, the course will also be useful to anyone facing the task of home and industrial automation, as well as to anyone engaged in industrial design, advertising and art.
The course does not require any special knowledge from the participants and is open even to students of upper secondary school. Programming skills and the level of English allowing to read technical documentation would be an advantage, but this is not obligatory.
The entire course is dedicated to practice, so the best way for you would be to get hold of some electronics, follow the illustrated examples and experiment on your own.
The kits can be purchased here: kits.cyberphysica.ru.
Taught by: Alexey Perepelkin, head of Robotics department in the Laboratory of innovative educational technologies at MIPT
Taught by: Dmitry Savitsky, researcher in the Laboratory of innovative educational technologies at MIPT

Taught By

Алексей Перепелкин

Руководитель направления развития цифрового творчества

Дмитрий Савицкий

Научный сотрудник

Transcript

In the sketch, where we are implementing our automate, I have created a macrodefinition, in which I gave names to all
the states. From the controller’s perspective, these are just digits. However, in order to make it easier for us to write the program, I have named every digit in its own way: the “Standby” state, the
“Watering” state, the “No water” state and the “Send page” state, where we transmit the
information from our web page. I have then created a global variable called STATE, which will store the current state of the system. For starters, I have placed STATE_STANDBY in it, aka 0 – the “Standby” state, which will be the system’s initial state before
it begins operating. I have also created a global variable, which will store information on whether
or not there is water left. That’ll be the true value if there is water, and false if there’s none. I’m not touching upon setup yet, since it doesn’t contain anything which has to do with the operation of the
automaton. Let’s see at once what happens in the main loop. The main loop consists of verifying the current state and the transition from one state to another one. For this purpose, I am using this new control structure called switch. Let’s see how it works. You can communicate an expression to it, which in our case will be a
variable, and examine its various options, which will depend on the value
of this variable. Every case is examined once we’ve looked at what comes after the
“case” key word. Thus, if the STATE variable equals this expression, and in our situation, this is STATE_STANDBY, (meaning that there is 0 value there), we will be performing all the actions listed here. We will look closer at
these actions later. The key word “break” is mentioned at the end, which closes the switch structure. You shouldn’t forget about it, as you might experience some situations when some extra actions happen if you don’t exit the switch structure. So what will be happening in the “Standby” state? For starters, we shall check if there is any water in the container. We don’t have the checkWater function yet, but we will need to define it, for we will need to check whether there is water or not. If there is none, we won’t be able to enter the “Watering” state, as it won’t be available to us. Then, if we receive a request from the network and we have water, the system is going to enter the “Watering” state. Therefore, we will need one more function called webRequest, which will display different options depending on the type of the received request. We were expecting the request of the 1 type, which is a request to start
watering automatically. In the “else if” branch, we can check for requests of other types, i.e. the request to display the data from the web page. If we get the request, we can enter the “Send page” state or
STATE_SENDPAGE regardless of the fact whether there is water or not. Then apart from checking the requests from the network, we are going to
check the state of all sensors. if the checkClimate function displays the true value, i.e. all the conditions for watering are met, and we have water in the container, the system will enter the “Watering”
state. This is our other possibility to enter the “Watering” state. However, if the gotWater variable stores the false value, aka there is no water left, the system will enter the “No water”
state. Where does the gotWater variable take its value from? Let’s imagine that our checkWater function is working with the global variable that we created, and the value will be assigned to all these expressions at the beginning of this “case”. Let’s look further. The case with the “Watering” state is described next. We are simply going to call a function for watering, which we are going to describe later. Its details are not important for us now. After the system has finished watering, the “Finish watering" event takes place, and the system reenters the “Standby”
state. Break again means here that we are exiting the switch structure. Let’s move on. Let’s consider the case when the system is in the “No water” state. In this case, we will need to set off the alarm. This will be described in the “alarm” function. We will also need to check just in case if any user would like to check the weather conditions at this exact moment. Thus, we need to check again if we have a corresponding request. We are going to code digits 1 and 2, which signify different types of replies received from webRequest, in a macrodefinition. Like these ones. These are the webRequest function replies, which, like I said, are equivalent
to digits 1 and 2. You would agree that this looks more comprehensible. If the Internet request asks for weather conditions, the system enters the “Send page” state. If we get no request, we shall check for water again, while the system is in the “No water” state. If water has appeared, i.e. the checkWater function gives us
the true value, the system enters the “Standby” state. The last state called case STATE_SENDPAGE, which is the state of data transmission, will activate the data transmission
function. After this, the system will again enter the “Standby” state. And again we have break at the end. Besides all this, I have written and added a comment to one more key word – default. Since we’ve already got acquainted with the switch structure, we can’t leave this key word behind. It can be used to describe actions which need to be taken if the system has entered none of the intended states. In other words, if all “case” functions did not work. We should not experience this, because we can switch easily between the states and we won’t find ourselves
somewhere in between them. That’s why I’ve added a comment to this “default” function. If this were not the case, we could describe the default behavior of the
system, let’s put it this way. We are now going to extend this code by adding all the functions that we mentioned in the automate sketch. Moreover, it’s easier for us to understand which one should be
returning some values, and which values should be returned in order for the system to function
correctly. Let’s also look at our main diagram, to which I suggest we add a display. This means that we are going to connect one more device, a display, which will be outputting the current state of the watering system. It may come in useful at the debugging stage, since we will be able to see what values the device is processing and in which state it currently is.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.