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
4.14. The longest sketch so far
Loading...
Destrezas que aprenderás
Electronics, Computer Programming, Arduino, Robotics
Revisiones
4.4 (216 calificaciones)
- 5 stars137 ratings
- 4 stars46 ratings
- 3 stars19 ratings
- 2 stars4 ratings
- 1 star10 ratings
CH
Nov 12, 2017
A very complete and helpful course, covering many options you have with Arduino. I really enjoyed it. Thank you very much!
AC
Jan 22, 2019
Is an admired course. I can't wait to have my fingers wrapped around it. I am really excited to be on this program.
De la lección
Week 4
After going through Week 4, you will be able to connect your device to a network, plan its creation beforehand , control heavy loads, and power your device correctly.
Impartido por:
Алексей Перепелкин
Руководитель направления развития цифрового творчества
Дмитрий Савицкий
Научный сотрудник
I already have a sketch, the so-called skeleton,
onto which I’m going to add the programs – our muscles.
Firstly, I have connected all the necessary libraries:
SPI and Ethernet libraries to work with the Ethernet shield and
QuadDisplay library
to work with the display.
I have determined all the pins,
to which I am going to connect our device following the diagram: the
pump,
the buzzer and the display.
Two other pins are for the water detection sensor, which
we made ourselves.
In fact, these are just two wires which the water will close.
Next we need to connect the sensors.
For soil humidity, we need to write out SOIL_PIN,
for temperature — TEMP_PIN, and for lightness this’ll
be LIGHT_PIN.
Then we have these macrodefinitions
with the names of different states, which we also used to have in the
skeleton of our sketch.
Next, I have named all the possible replies to the Web Request function.
If we don’t receive any request, we will have the “No client”
reply or WEB_NO_CLIENT.
If we get a request to water the plant automatically, then the reply will be
WEB_FORCED_WATERING.
Finally, if this is a request to send data, we shall have this WEB_CLIMATE_REQUEST.
I have also created a macrodefinition, which will store the number of
milliseconds,
during which the system will be watering the plant.
Thus, you can configure this information right here.
I shall set a 1 sec value.
There are three more settings that are responsible for threshold values,
which climate parameters need to reach and exceed
to create all the necessary conditions for watering.
We already had this line, where we
create a global variable named
STATE and initialize it with STATE_STANDBY value.
Finally, apart from gotWater, we have three new global
variables to store climate parameters.
I have made them global to simplify data transmission to the Internet.
Thus, one function will be taking these readings to save them here,
whereas the other function will be
taking whatever has been saved in the global variable to transmit it following
the received request.
Next come the lines that we saw when we were studying the process of data
transmission.
This is the database with the MAC address of the Ethernet shield,
IP object with our IP address, and
the port number.
Next we create an EthernetClient object right here.
A line is created, which will store the requests.
All the pins have been configured in setup.
Let me mention that I have given the name INPUT_PULLUP to the pin,
which will read off information about whether or not there is water left.
This means that the pin is drawn to the power source.
Thus, when we check for water,
we will change the state of the second pin, from which we are sending the signal,
to the “low” state.
Respectively, when the second pin, this WATER_OUT_PIN,
is in the “low” state and it’s closed with pin WATER_IN_PIN,
WATER_IN_PIN will change from the “high” to the “low” state.
So here I am going to start WATER_OUT_PIN in the “high”
state
and I will then switch it to “low”.
Then, the Ethernet shield starts working
when its server is started.
We have the same things in the loop
that we’ve just examined in the program skeleton.
One thing I’ve done is I’ve made the display output pins’ current state.
This switch structure looks exactly the same, except for 1 and 2, which
I have substituted with these macrodefinitions to make the
code more comprehensible.
When we reread the code in several days, it’ll be hard for us to understand
what’s 1 and what’s 2.
But with the help of macrodefinitions, we understand what it’s all about.
Other sections have stayed unchanged.
Next, we need to determine all the above-mentioned functions.
The “alarm” function doesn’t return any value, and we can just call the “tone”
function in it.
In other words, we could call the “tone” function in the same section where we
call the
“alarm” function, but, say,
we want to make our alarm more sophisticated, so our code will
be extended.
Instead of extending our automate,
we’d better extend the “alarm”, and everything will stay as
it is.
Thus, we know that we need to call the “alarm” function and we don’t
need to know what’s inside it.
The “alarm” function itself will get extended if necessary.
Next comes another simple function – the “watering” function.
It won’t return any values, but it has a pin inside, which
has the “Power key” module connected to it, into which the pump is
plugged.
Let’s turn it on.
Then we need to wait for some time, the duration of which is mentioned
in the WATERING_MILLIS
macrodefinition.
In our case, this is 1 sec.
Now let’s turn off the “Watering” function.
Next, we have the CHECK_CLIMATE function definition,
which checks climate parameters and returns a boolean value:
true if the conditions are favorable for watering and
false if they are still unfavorable.
First, we need to save current readings of the analog inputs
into the three global variables we mentioned before. The inputs have climate sensors
connected to them: the soil humidity sensor, the temperature sensor and the light sensor.
Afterwards, the system checks if
these values exceed the threshold values.
And if all the three parameters are true,
i.d. it’s not dark, so it’s not night,
it’s quite warm, so it’s not cold,
and the soil is not watered enough, so it’s dry,
the system will return the “true” value, which will mean that it’s time to water
the plant.
Alternatively, the system will return the “false” value.
It’s obvious that this is the most primitive way of taking care of
your plant.
You can make this CHECK_CLIMATE function more complex if you aim to
create an automated greenhouse, a vegetable plot, and so on.
That is if you want to make the function more complex in order to consider various
combinations of different conditions.
For example, the system will water the plant at night, but not in cold weather.
Or if the soil is wet and if it’s light, the system won’t water the plant in
daylight hours.
Well, all can I say is that there may be various sorts of combinations.
Besides, you may have even more sensors connected, so the
number of combinations will only increase.
And in these combinations, you can do many various things.
In the end, it’ll return a “true” value if it’s time to water the plant, and
the “false” value if it’s not yet time for it.
Next comes the checkWater function, which
checks for water, and this function will also return a boolean value.
It’ll be true if there is water and false if there is no water.
We shall put “low” at the beginning of WATER_OUT_PIN, and then we shall read
off WATER_IN_PIN.
In case there is contact between them,
we will get a low value on WATER_IN_PIN.
Alternatively, if there is no contact, we will get a high value.
Consequently, digitalWrite will return the “true” value if there is no contact.
This’ll mean that the wires are not plunged in water.
In this case, we simply say that there is no water.
By saying this, we assign a value to the gotWater global value.
Otherwise, if the wires are plunged in water and there is contact,
the system will return the “true” value.
Afterwards, we shall turn off
WATER_OUT_PIN, i.e. bring it to the “high” state.
We will then return gotWater, regardless of its being a global value.
Naturally, this is not a perfect solution, but in this case, it
is the simplest one.
Besides, we’ve had the chance to remind ourselves how global variable are
different from all the other ones.
WebRequest function begins next.
It’ll be returning data of the
integer type, since it may have several possible answers.
Here we have basically copied the
lines which we already had when we examined the example with the page
output.
If you want, you can scroll back and take a look again at what this means.
We’ve only changed one thing: now, if there is ?water substring in
the request,
i.e. the incoming command to water the plant automatically,
we will be returning this value
hidden behind this macrodefinition.
In other words, webRequest tells the system that it should start watering
automatically.
Alternatively, when we’ve received the end of the line and this line turns
out to be empty,
we will be returning the value hidden behind the WEB_CLIMATE_REQUEST
macrodefinition.
I don’t even remember what digit it is now.
Frankly speaking, I don’t really need to know it.
What I know is that in the automate we are going to
get a request to output data in the network.
[SCROLLS DOWN] In case we don’t receive a request,
but the function has already been called, we will consider that
there is no client.
[SCROLLS DOWN] Last but not least, We have the sendPage function,
which does not return any values either.
We have copied some fragments from the example with the page output in
it,
which appear in the “Send Page” function.
Everything written here we’ve already seen before.
I have included some minor changes down here.
Firstly, I have removed the loop, which we had in the standard sample,
and in which we had the sequential output of all the values read off
at our analog inputs.
Now we shall write the names of the measured parameter and the value
itself,
which is stored in the corresponding global variable,
concerning soil humidity, temperature and lightness.
Let me remind you that this <br /> tag is a line break.
There is a certain established condition at the end.
If the gotWater global variable
stores the “true” value, i.e. there is water in the container, we shall
write
that everything is OK with the water and we shall output this link,
which will allow us to start watering automatically.
Conversely, if there is no water left, we shall just write that there is no
water. In this case, we won’t even be able to click on the
link, as there is no water to water the plant with.
This is it.
Thus, we have studied the whole code.
It probably is the longest code so far in our course with almost 200 lines.
We might have even longer codes in the future, but we haven’t written such
long sketches yet.
Now let’s look how our watering system works.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2019 Coursera Inc. Todos los derechos reservados.
