Pembelajaran Berbasis Proyek dengan Arduino: Contoh Unit 4 Minggu
Pembelajaran berbasis proyek (PjBL) dengan Arduino: pertanyaan pemantik, rencana unit 4 minggu, 4 masalah sekolah beserta sensornya, peran tim, log uji, dan kriteria presentasi.
Pembelajaran berbasis proyek dengan Arduino (di Indonesia biasa disingkat PjBL) adalah desain unit tempat siswa mempelajari materi bukan setelah ceramah, tetapi sambil mencoba memecahkan masalah nyata. Alurnya punya lima tahap: kamu mengajukan pertanyaan pemantik, tim meneliti masalahnya dan memutuskan apa yang akan diukur, mereka membuat prototipe dengan Arduino, mereka menguji dan memperbaikinya di sekitar sekolah, dan akhirnya mereka mempresentasikan temuannya kepada audiens nyata. Pertanyaan pemantik contoh unit di artikel ini: “Bagaimana kita bisa mengukur masalah energi, air, kebisingan, atau udara kelas di sekolah kita dan memberi peringatan tentangnya?” Selama empat minggu, setiap tim memilih salah satu masalah ini, mengukurnya dengan sensor, membuat perangkat yang berfungsi dan memberi peringatan ketika ambang terlampaui, lalu memakai data yang dikumpulkannya untuk memberi rekomendasi kepada sekolah.
Di bawah ini ada semua yang bisa kamu bawa ke kelas besok: tabel unit per minggu, alur per pertemuan dengan pertanyaan penutup, empat skenario masalah dengan proyek awal di BlueGrays, daftar bahan, kontrak tim dan peran, siklus prototipe dan template log uji, kriteria pemeriksaan tengah dan presentasi akhir, jebakan PjBL yang sering terjadi, serta daftar periksa. Semua contoh memakai asumsi yang sama: anggap kamu punya kelas berisi 24 siswa, dua jam pelajaran seminggu (2 × 40 menit), dan enam tim berisi empat orang. Kalau kamu mencari rencana yang mengajarkan keterampilan secara berurutan, rencana robotika coding blok 8 minggu lebih cocok, dan untuk program singkat yang padat, workshop Arduino 5 hari lebih pas. Unit ini paling berhasil setelah keduanya, ketika siswa sudah pernah menyalakan LED dan membaca sensor.
Apa itu pembelajaran berbasis proyek, dan apa bedanya dengan tugas proyek?
Dalam urutan klasik, materi diajarkan dulu, lalu proyek diberikan sesudahnya agar siswa bisa menunjukkan apa yang sudah dipelajari; proyeknya hanya hidangan penutup, bukan makanan utama. Dalam pembelajaran berbasis proyek urutannya terbalik: proyek itulah pelajarannya. Siswa mempelajari analogRead(), ambang, atau cara menghitung rata-rata tepat ketika mereka membutuhkannya untuk memecahkan masalah. Arduino cocok dengan pendekatan ini karena mengubah dunia nyata menjadi angka: LDR mengukur cahaya di koridor, sensor suara mengukur kebisingan di kantin, DHT11 mengukur suhu di kelas. Prototipe itu murah dan bisa diubah dalam hitungan menit; kalau ambangnya salah, kamu cukup mengubah satu angka di kode dan upload lagi. Dengan begitu siklus “coba, ukur, perbaiki” yang menjadi inti PjBL muat dalam satu jam pelajaran. Tabel ini merangkum perbedaannya:
| Aspek | Tugas proyek klasik | Unit pembelajaran berbasis proyek |
|---|---|---|
| Titik awal | Sebuah topik atau proyek jadi (“buat sensor parkir”) | Masalah nyata (“lampu koridor tetap menyala ketika tidak ada orang”) |
| Kapan materi diajarkan? | Sebelum proyek, ke seluruh kelas sekaligus | Selama proyek, ketika tim membutuhkannya, lewat mini-pelajaran 10 menit |
| Produk | Satu perangkat yang sudah jadi | Perangkat + data pengukuran + rekomendasi yang beralasan |
| Kesalahan | Menurunkan nilai | Dicatat di log uji dan menjadi bahan versi berikutnya |
| Penilaian | Di akhir: berfungsi atau tidak? | Sepanjang proses: definisi masalah, data, iterasi, dan presentasi |
| Audiens | Hanya guru | Orang nyata yang terdampak masalahnya (pimpinan sekolah, staf sekolah, kelas lain) |
Pertanyaan pemantik: satu kalimat yang menopang seluruh unit
Pertanyaan pemantik adalah pertanyaan yang tetap tertempel di dinding kelas selama empat minggu dan menjadi tempat setiap pertemuan kembali terhubung: “Seberapa dekat kita dengan jawabannya hari ini?” Di unit ini pertanyaan bersamanya sengaja dibuat luas agar setiap tim bisa memilih bagiannya sendiri: “Bagaimana kita bisa mengukur masalah energi, air, kebisingan, atau udara kelas di sekolah kita dan memberi peringatan tentangnya?” Tugas minggu pertama adalah mempersempit pertanyaan luas ini menjadi sub-pertanyaan milik tim. “Pemborosan energi di sekolah” bukan sub-pertanyaan; “Berapa menit lampu tetap menyala di kelas 7B yang kosong selama jam istirahat, dan siapa yang perlu kita beri tahu, dan bagaimana caranya?” adalah sub-pertanyaan. Jawaban sub-pertanyaan yang baik dimulai dengan angka dan berakhir dengan perangkat. Sebelum menyetujui sub-pertanyaan sebuah tim, cek dengan enam kriteria ini:
- Nyata: Seseorang di sekolah benar-benar mengalami masalah ini dan tim bisa menyebutkan siapa orangnya: guru piket, staf sekolah, petugas kantin, atau ketua kelas.
- Terukur: Sensor yang kamu punya mengubah masalahnya menjadi angka: cahaya, tingkat suara, kelembapan tanah, suhu, atau jarak.
- Lokal dan sempit: Ada satu tempat dan satu rentang waktu; bukan “sekolah”, tetapi “koridor lantai dua, istirahat siang”.
- Terbuka: Jawabannya bukan ya atau tidak; pertanyaannya menanyakan “bagaimana”, “kapan”, atau “berapa banyak”.
- Muat dalam 4 minggu: Solusinya tidak mengharuskan menyentuh instalasi listrik PLN, bergabung ke jaringan sekolah, atau menunggu persetujuan anggaran.
- Berakhir dengan peringatan: Perangkat tidak hanya mengukur lalu diam; pada suatu ambang, perangkat memberi tahu seseorang lewat LED, buzzer, atau layar.
Unit pembelajaran berbasis proyek 4 minggu
Rencananya disusun untuk 8 pertemuan: dua per minggu, masing-masing 40 menit. Minggu-minggunya mengikuti lima tahap PjBL, tetapi tidak ada tembok tebal antara riset dan pembuatan prototipe; di minggu 2 sebuah tim mungkin masih mempersempit masalahnya, dan di minggu 3 pengukuran baru bisa memunculkan pertanyaan riset baru. Yang penting, keluaran di tabel sudah ada di akhir setiap minggu. Peranmu juga berubah dari minggu ke minggu: di awal kamu yang mengajukan pertanyaan, di tengah kamu menjadi pelatih, dan di akhir kamu menjadi penyelenggara yang mendatangkan audiens ke ruang kelas.
| Minggu | Tahap | Keluaran siswa | Peran guru | Dukungan di aplikasi |
|---|---|---|---|---|
| 1 | Pertanyaan pemantik dan riset | Kartu masalah: sub-pertanyaan, besaran yang diukur, kriteria keberhasilan; kontrak tim yang sudah ditandatangani | Mengajukan pertanyaan, memandu keliling sekolah, membantu mempersempit sub-pertanyaan tanpa memberi jawaban | Proyek awal lewat Pencari proyek; daftar Komponen yang dibutuhkan di proyek |
| 2 | Prototipe | Versi kerja minimum: nilai sensor di Serial Monitor, LED menyala di atas ambang; pemeriksaan tengah | Pelatih rangkaian dan kode; menjalankan pemeriksaan tengah di pertemuan 4 | Skema rangkaian, Langkah demi langkah di dalam Pahami kode; dengan Premium, komponen yang kurang di Labku › Komponen |
| 3 | Uji dan perbaiki | Pengukuran di 3 titik atau lebih di sekolah, minimal 2 versi baru, log uji yang terisi, umpan balik teman sejawat | Membuat siswa mempertanyakan data (“Kenapa angkanya begini?”), memberi mini-pelajaran tentang rata-rata dan ambang | Latihan mengubah kode lewat tugas Coba sendiri, bagian Kalau mentok |
| 4 | Presentasi | Prototipe dalam kotak, poster satu halaman, presentasi 5 menit, dan rekomendasi tertulis untuk sekolah | Mengundang audiens (pimpinan sekolah, staf sekolah, kelas lain) dan menilai | Tim menandai proyek awalnya dengan Sudah buat; guru bisa membagikan rangkaian contoh sebagai postingan Tutorial di Forum |
Tabel di bawah memecah rencana yang sama per pertemuan. 3 menit terakhir setiap pertemuan dipakai untuk pertanyaan penutup; tim menulis jawabannya dalam satu kalimat di bagian bawah log uji. Jawaban ini menjadi pemanasan untuk pertemuan berikutnya sekaligus bukti proses di presentasi akhir. Batasi mini-pelajaran sampai 10 menit; lebih lama dari itu akan memakan waktu kerja tim, dan unitnya diam-diam kembali menjadi pelajaran klasik.
| Pertemuan | Fokus | Apa yang terjadi? | Pertanyaan penutup |
|---|---|---|---|
| 1 | Menemukan masalah | Pertanyaan pemantik ada di poster. Keliling sekolah 15 menit: tim mencatat pengamatan di koridor, kantin, kebun sekolah, dan ruang kelas. Tim dibentuk dan kontraknya dibacakan. | Masalah mana yang kamu lihat yang bisa diukur dengan sensor? |
| 2 | Sub-pertanyaan | Setiap tim memilih skenario, melakukan wawancara singkat 3 pertanyaan dengan 2 orang yang terdampak masalah, dan mengisi kartu masalah. Proyek awal dicari dengan Pencari proyek. | Apa pertanyaan timmu dalam satu kalimat? Angka mana yang akan menunjukkan keberhasilan? |
| 3 | Rangkaian pertama | Rangkaian proyek awal dirakit dari skema, kodenya di-upload dan dibaca bersama lewat Pahami kode. Nilai pertama sensor muncul di Serial Monitor. | Angka dari sensor itu mewakili apa, dan apa yang terjadi ketika angkanya naik? |
| 4 | Versi kerja minimum + pemeriksaan tengah | Ambang dan LED ditambahkan ke kode. Di 15 menit terakhir setiap tim memberi demo 2 menit dan guru mencentang kriteria pemeriksaan tengah. | Bagaimana kamu memilih ambangnya: tebakan atau pengukuran? |
| 5 | Pengukuran lapangan | Prototipe dijalankan di minimal 3 tempat atau waktu yang berbeda di sekolah dan nilainya dicatat di log uji. Mini-pelajaran: mengubah nilai mentah menjadi persentase atau satuan yang bermakna. | Apakah pengukuran membenarkan tebakanmu, dan apa yang membuatmu terkejut? |
| 6 | Perbaikan | Ambang diperbarui berdasarkan data; kalau peringatannya berkedip-kedip, ditambahkan rata-rata atau dua ambang terpisah. Tim berpasangan dan saling memberi dua kekuatan dan satu saran. | Satu hal apa yang kamu ubah di versi ini, dan kenapa? |
| 7 | Versi akhir dan persiapan | Prototipe dimasukkan ke kotak, peringatan mendapat bentuk akhirnya, poster dan presentasi disiapkan. Tidak ada fitur baru, hanya perbaikan. | Tabel atau grafik tunggal mana yang akan kamu tunjukkan di presentasi? |
| 8 | Presentasi akhir | 6 tim × 5 menit (3 menit paparan dan demo, 2 menit tanya jawab). 7 menit terakhir dipakai untuk refleksi unit. | Kalau ada satu minggu lagi, apa yang akan kamu ubah? |
4 skenario masalah dan proyek awalnya di BlueGrays
Jangan berharap tim menulis kode dari nol; di PjBL tujuannya memecahkan masalah, bukan menulis program dari baris pertama. Untuk setiap skenario, BlueGrays punya proyek awal yang siap pakai lengkap dengan skema rangkaian, daftar komponen, dan kode; tim merakitnya, memahaminya, dan menyesuaikannya dengan masalahnya sendiri. Proyek gratis di tabel terbuka untuk semua orang, sedangkan yang Premium membutuhkan Premium. Dengan enam tim, biarkan paling banyak dua tim memilih skenario yang sama. Kalau dua tim dengan skenario yang sama mengukur tempat yang berbeda, kamu juga mendapat perbandingan di presentasi.
| Masalah | Besaran yang diukur | Sensor | Proyek awal | Pengembangan |
|---|---|---|---|---|
| Energi: lampu tetap menyala di kelas kosong selama jam istirahat dan sepulang sekolah | Cahaya sekitar dan ada tidaknya gerakan di ruangan | LDR + resistor 10 kΩ, lalu PIR (HC-SR501) | Lampu Tidur dengan LDR (gratis) | Tambahkan gerakan dengan Pendeteksi Gerakan dengan Sensor Gerak (Premium): beri peringatan kalau lampu menyala dan tidak ada gerakan selama 5 menit. Contoh lengkap dalam satu proyek: Lampu Pintar ESP32 (PIR + LDR + Relay + OLED) (Premium) |
| Air: tanaman di kebun sekolah mendapat air terlalu banyak atau terlalu sedikit | Kelembapan tanah (nilai mentah dulu, lalu persentase) | Sensor kelembapan tanah | Stasiun Penyiraman Pintar (Premium); untuk pemanasan membaca nilai analog, Mengukur Intensitas Cahaya dengan LDR (gratis) | Ukur level air di gembor dari atas dengan Pengukuran Jarak HC-SR04 (Tampilan Serial) (gratis) |
| Kebisingan: tingkat suara di kantin dan koridor mengganggu | Tingkat suara relatif (nilai analog, bukan desibel) | Modul sensor suara KY-038 | Mengukur Intensitas Cahaya dengan LDR (gratis) sebagai pola membaca nilai analog + Lampu Lalu Lintas (gratis) untuk lampu peringatan | Lampu lalu lintas kebisingan: ambang untuk hijau, kuning, dan merah, rata-rata 1 menit, bunyi bip singkat ketika merah dengan Menggunakan Buzzer (gratis) |
| Udara kelas: ruangan terasa panas dan pengap di siang hari | Suhu (°C) dan kelembapan relatif (%) | DHT11 atau DHT22 | Suhu dan Kelembapan dengan DHT11 (gratis) atau Suhu dan Kelembapan DHT22 ESP32 (dengan Layar LCD) (gratis) | Untuk pencatatan sepanjang hari, Pencatat Data Suhu ESP32 (DHT22 + RTC DS1307 + microSD + OLED) (Premium); untuk mengukur pengap yang sebenarnya dibutuhkan sensor CO2 terpisah |
Jujurlah kepada siswa soal dua hal sejak awal. Pertama, KY-038 bukan desibel meter: sensor ini mengubah fluktuasi yang ditangkap mikrofon menjadi angka antara 0 dan 1023. Tim tidak bisa bilang “kantin ada di 85 dB”, tetapi bisa bilang “di jam istirahat siang kantin memberi nilai jauh lebih tinggi daripada kelas kosong” dan menunjukkan perbedaannya dengan angka; data perbandingan sudah cukup untuk PjBL. Cara sensor merespons dan cara menyetelnya ada di artikel sensor suara KY-038. Kedua, DHT11 mengukur suhu dan kelembapan, bukan pengap; di kelas tertutup yang sebenarnya naik adalah karbon dioksida. Tim udara kelas bisa mendasarkan rekomendasi “buka jendela” pada suhu dan kelembapan, lalu menyampaikan di presentasi bahwa langkah berikutnya adalah mengukur CO2. Untuk sensor tim energi dan air, artikel sensor cahaya LDR dan sensor kelembapan tanah membahas kalibrasi secara rinci.
Daftar bahan: 6 tim + 1 set cadangan
| Barang | Per tim | Total kelas | Catatan |
|---|---|---|---|
| Arduino Uno atau board kompatibel + kabel USB | 1 | 7 | Semua skenario |
| Breadboard (830 lubang) | 1 | 7 | Semua skenario |
| Kabel jumper male-to-male | 20 | sekitar 150 | Semua skenario |
| LED 5 mm (merah, kuning, hijau) | 3 | sekitar 30 | Lampu peringatan |
| Resistor 330 Ω | 3 | sekitar 30 | Satu untuk setiap LED |
| Resistor 10 kΩ | 1 | 10 | Untuk LDR dan DHT11 |
| Buzzer | 1 | 7 | Peringatan suara (opsional) |
| LDR + sensor gerak PIR (HC-SR501) | 1 + 1 | 3 + 3 | Tim energi (paling banyak 2 tim + 1 cadangan) |
| Sensor kelembapan tanah + pot tanaman | 1 | 3 | Tim air |
| Sensor jarak HC-SR04 + wadah plastik | 1 | 3 | Tim air, pengukuran level |
| Modul sensor suara KY-038 | 1 | 3 | Tim kebisingan |
| DHT11 (atau DHT22) + LCD I2C 16x2 | 1 + 1 | 3 + 3 | Tim udara kelas; proyek DHT11 memakai LCD |
| Kotak kardus, selotip, label | 1 set | 7 | Pengemasan dalam kotak di minggu 3 dan 4 |
Kontrak tim dan peran
Di tim berisi empat orang, kalau tidak semua orang punya tugas, siswa yang paling cepat yang mengerjakan semuanya dan yang lain menonton. Solusi paling sederhana adalah empat peran dan rotasi mingguan: 4 minggu, 4 peran, setiap orang memegang setiap peran sekali. Peran bukan berarti “aku hanya mengerjakan ini”; artinya “aku yang bertanggung jawab atas ini”. Penanggung jawab kode bukan satu-satunya yang menulis kode, tetapi minggu itu dialah yang menjelaskan kepada kelas apa yang dilakukan kode. Tim menulis kontraknya sendiri di pertemuan pertama; kamu hanya mewajibkan butir-butir di bawah dan menyetujuinya setelah keempat anggota menandatangani.
| Peran | Tanggung jawab | Keluaran mingguan |
|---|---|---|
| Manajer proyek | Memegang daftar tugas dan waktu, mencatat keputusan tim, menjadi orang yang berbicara dengan guru | Daftar tugas 3 butir di awal pertemuan, dicentang di akhir |
| Penanggung jawab rangkaian | Merakit dan mengecek rangkaian sesuai skema, menghitung komponen | Foto rangkaian yang berfungsi, catatan komponen yang kurang |
| Penanggung jawab kode | Meng-upload kode, membuat perubahan, dan menjelaskan setiap perubahan dalam satu baris | Kode terbaru dan catatan “apa yang berubah?” |
| Penanggung jawab data dan dokumentasi | Melakukan pengukuran, mengisi log uji, mengambil foto dan video | Log uji yang terisi, minimal satu tabel untuk presentasi |
- Sub-pertanyaan kami: .................................................. (satu kalimat, satu tempat, satu waktu)
- Kriteria keberhasilan kami: Ketika .................. melewati .................., perangkat kami akan memberi peringatan dengan ...................
- Peran (minggu 1): Manajer proyek ........, rangkaian ........, kode ........, data dan dokumentasi ........ Setiap minggu kami menggeser peran satu orang.
- Aturan keputusan: Kalau kami tidak sepakat, kami mengukur dulu; kalau tidak ada pengukuran, manajer proyek yang memutuskan dan menuliskan keputusannya di log uji.
- Aturan minta bantuan: Sebelum ke guru, kami mengecek skema, bagian Pahami kode di proyek, dan satu teman tim.
- Ketidakhadiran: Anggota yang tidak hadir di satu pertemuan membaca log uji di pertemuan berikutnya dan menyusul dalam 2 menit; orang lain mengambil alih tugasnya minggu itu.
- Tanda tangan: .............. .............. .............. ..............
Siklus prototipe: versi kerja minimum
Unit PjBL paling sering karam ketika tim menghabiskan dua minggu pertama untuk merancang perangkat yang sempurna. Aturannya sederhana: di akhir pertemuan 4 setiap tim harus punya versi kerja minimum. Versi ini melakukan tiga hal: membaca sensor, menampilkan nilainya di Serial Monitor, dan menyalakan satu LED ketika nilainya melewati ambang. Tanpa kotak, tanpa layar, tanpa Wi-Fi; tetapi versi ini menghasilkan data nyata dan bisa diuji. Untuk tim kebisingan, ini berarti menambahkan pernyataan if dan satu LED ke kode Mengukur Intensitas Cahaya dengan LDR. Untuk tim energi, Lampu Tidur dengan LDR hampir sudah menjadi versi ini; hanya logikanya yang dibalik: LED menyala bukan ketika gelap, tetapi ketika lampu menyala, dan pertanyaan “apakah ruangannya kosong?” datang bersama PIR di versi berikutnya. Setiap versi setelah itu membawa tepat satu perubahan dan dicatat di log uji:
- Versi 0, pengukuran: Sensor dibaca dan nilainya dicetak ke Serial Monitor sekali per detik. Tim melihat nilainya berubah karena tangan, cahaya, suara, atau air.
- Versi 1, versi kerja minimum: Ambang perkiraan dan satu LED. Ketika ambang terlampaui, LED menyala. Versi inilah yang ditunjukkan di pemeriksaan tengah pada pertemuan 4.
- Versi 2, kalibrasi: Setelah pengukuran lapangan, ambang dipilih dari data, bukan tebakan; misalnya di tengah-tengah antara nilai kelas kosong dan nilai selama jam istirahat.
- Versi 3, peringatan stabil: Ketika nilainya naik-turun di sekitar ambang, LED berkedip-kedip. Solusinya adalah merata-ratakan 10 pembacaan terakhir atau memakai dua ambang terpisah untuk menyalakan dan mematikan.
- Versi 4, dibuat untuk pengguna: Peringatan dibentuk sesuai orang yang terdampak masalah: lampu tiga warna yang bisa dilihat semua orang di kantin, LCD kecil di meja guru di dalam kelas. Pengemasan dalam kotak dan penempatan dilakukan di versi ini.
| Pertemuan | Versi | Apa yang kami ubah? | Bagaimana pengujiannya? | Harapan | Hasil ukur | Keputusan |
|---|---|---|---|---|---|---|
| 5 | 1 | Menambahkan ambang 600 | Di pintu masuk kantin, istirahat siang, 10 menit | LED merah hanya menyala ketika ada yang berteriak | LED menyala sekitar 8 dari 10 menit | Ambang terlalu rendah, naikkan berdasarkan data |
| 6 | 2 | Ambang dinaikkan ke 780, merata-ratakan 10 pembacaan terakhir | Tempat sama, waktu sama, 10 menit | Merah hanya di momen paling ramai | Merah menyala 2 kali; kuning berkedip-kedip di sekitar ambangnya | Pakai ambang nyala dan ambang mati yang terpisah untuk kuning |
| ... | ... | ... | ... | ... | ... | ... |
Kriteria pemeriksaan tengah dan presentasi akhir
Untuk kriteria umum seperti rangkaian, kode, pemahaman, debugging, dan dokumentasi, kamu bisa memakai rubrik utama dari artikel Rubrik Penilaian Proyek Arduino apa adanya. Di unit PjBL cukup tambahkan tiga kriteria; kriteria ini mengukur hal yang tidak diukur tugas proyek, tetapi justru diajarkan unit ini. Pemeriksaan tengah dilakukan di pertemuan 4 dan hanya melihat definisi masalah dan versi kerja minimum; tujuannya meluruskan arah, bukan memberi nilai. Di presentasi akhir ketiga kriteria dinilai. Prototipe yang menonjol di akhir unit juga bisa dibawa ke pameran sains; untuk ide topik, lihat artikel ide proyek Arduino untuk lomba sains.
| Kriteria PjBL | 1 – Mulai | 2 – Berkembang | 3 – Siap |
|---|---|---|---|
| Definisi masalah | Topiknya luas (“kebisingan di sekolah”), tidak jelas siapa yang terdampak | Tempat dan waktu jelas, besaran yang diukur sudah dipilih | Tempat, waktu, orang yang terdampak, dan kriteria keberhasilan dalam satu kalimat, didukung wawancara |
| Keputusan dari data | Ambang dan keputusan berdasarkan tebakan | Ada pengukuran, tetapi kaitannya dengan keputusan lemah | Setiap keputusan penting (ambang, penempatan, jenis peringatan) dibuktikan dengan pengukuran |
| Iterasi | Satu versi; ketika ada yang gagal, rangkaian dirakit ulang dari nol | Minimal 2 versi, perubahan tercatat | 3 versi atau lebih, masing-masing satu perubahan; alasan dan hasilnya ada di log uji |
- Masalah (30 detik): Sub-pertanyaan dan satu kalimat dari orang yang diwawancarai timmu yang menggambarkan masalahnya.
- Pengukuran (45 detik): Di mana, kapan, dan berapa kali timmu mengukur; satu tabel atau grafik.
- Demo langsung (45 detik): Perangkat melewati ambang di depan audiens dan memberi peringatannya. Siapkan video demo singkat sebagai cadangan.
- Versi (30 detik): Satu keputusan dari log uji: “Kami mengubah ambang karena pengukuran ini.”
- Rekomendasi (30 detik): Rekomendasi konkret untuk sekolah (di mana, berapa perangkat, siapa yang merawatnya) dan apa yang akan timmu lakukan kalau ada satu minggu lagi.
- Tanya jawab (2 menit): Guru atau audiens mengajukan pertanyaan kepada anggota tim pilihannya, jadi setiap orang harus bisa menjelaskan setiap bagian.
Apa peran BlueGrays di unit ini?
- Proyek awal dengan Pencari proyek: Di pertemuan 2 tim menjawab tiga pertanyaan: Ukur dan deteksi untuk “Kamu mau bikin apa?”, Arduino Uno / Nano sebagai board, dan untuk kebanyakan kelas, “Aku sudah bikin beberapa proyek” sebagai pengalaman. Di samping kecocokan terbaik, layar hasil juga bisa menampilkan proyek pemanasan gratis yang bisa dimulai dengan komponen yang sama. Detailnya ada di artikel Pencari proyek.
- Memahami kode dengan Pahami kode: Menyalin kode proyek awal lalu lanjut begitu saja tidak berhasil di PjBL, karena tim akan mengubah kode itu. Tab Pahami kode pertama-tama memberi ringkasan “Kode ini ngapain?”, lalu penjelasan Langkah demi langkah, dan terakhir tugas Coba sendiri yang meminta satu perubahan. Bagian ini terbuka untuk semua orang di proyek gratis dan terbuka dengan Premium di proyek Premium. Cara memakainya kami tunjukkan di artikel Pahami kode.
- Merencanakan komponen dengan Labku › Komponen (Premium): Kalau kamu memasukkan komponen di lemari kelasmu ke Labku › Komponen beserta jumlahnya, daftar Proyek yang bisa kamu buat dan Proyek yang kurang komponen menunjukkan skenario mana yang bisa dimulai hari ini dan mana yang perlu dipesan dulu. Detailnya ada di artikel proyek dengan komponen yang kamu punya.
- Proyek contohmu sendiri: Sebelum unit dimulai, kamu bisa merakit satu skenario sendiri dan membagikannya lewat Belajar > Forum > Postingan Baru di kategori Tutorial: tambahkan foto rangkaian (maksimal 5 gambar), masukkan kodemu dengan Tambah kode, lalu tautkan proyek siap pakai yang terkait. Postingan diterbitkan dalam bahasa yang kamu pakai untuk menulisnya; kirim tautannya ke grup kelas dengan Bagikan. Proyek siap pakai juga bisa kamu teruskan dengan cara yang sama lewat Bagikan di halaman proyek. Langkah-langkahnya ada di artikel mengajar dengan proyekmu sendiri.
- Akses Premium untuk kelas: Untuk proyek awal Premium seperti Stasiun Penyiraman Pintar dan untuk Labku › Komponen, kamu tidak perlu langganan terpisah untuk setiap siswa; paket pendidik sekali bayar tanpa perpanjangan otomatis, yang ditukarkan siswa tanpa menambahkan kartu, kami jelaskan di artikel kode Premium untuk satu kelas.
Ketahui juga apa yang tidak dilakukan aplikasi ini: BlueGrays tidak punya fitur membuat kelas, dasbor yang menunjukkan kemajuan tim kepada guru, atau fitur pemberian tugas. Kartu masalah, kontrak tim, dan log uji tetap di kertas atau di dokumen bersama yang dipakai sekolahmu. Aplikasi menangani sisi “bagaimana cara merakitnya, kodenya ngapain, komponen mana yang kurang?” dari unit ini; sisi “kenapa ambang ini, siapa yang diuntungkan?” adalah tugas tim dan tugasmu. Pembagian itu memang cocok untuk PjBL: proses berpikir tetap ada di tim, bukan di layar.
Jebakan PjBL yang sering terjadi dan cara mengatasinya
| Jebakan | Bagaimana kamu menyadarinya? | Solusi |
|---|---|---|
| Proyek dimulai tanpa masalah (“ayo bikin robot”) | Tim bisa menjelaskan perangkatnya tetapi tidak bisa bilang masalah siapa yang dipecahkannya | Tidak ada kotak komponen sebelum kartu masalah disetujui |
| Pertanyaannya terlalu besar (“ayo kurangi pemakaian energi sekolah”) | Di akhir pertemuan 2 belum ada satu besaran pun yang akan diukur | Satu tempat, satu waktu, satu besaran: “koridor lantai dua, istirahat siang, cahaya” |
| Waktu habis untuk mengejar produk sempurna | Di pertemuan 4 masih belum ada satu nilai pun di Serial Monitor | Versi kerja minimum wajib ada di akhir pertemuan 4; kotak dan layar menyusul |
| Satu orang mengerjakan semuanya | Hanya satu siswa yang bisa menjelaskan kode atau rangkaian | Rotasi peran mingguan; di presentasi kamu yang memilih siapa yang menjawab |
| Perasaan, bukan data (“menurutku berisik banget”) | Tidak ada tabel atau grafik di presentasi, keputusan tanpa alasan | Log uji di setiap pertemuan; ambang tidak diubah tanpa minimal 3 pengukuran |
| Kode disalin tetapi tidak bisa diubah | Tim membeku ketika diminta mengubah ambang | Di setiap versi penanggung jawab kode mengubah satu baris sendiri dan menjelaskannya; tugas Coba sendiri di Pahami kode menjadi pemanasan |
| Pekerjaan menumpuk di minggu terakhir | Di pertemuan 7 kotak, poster, dan kode semuanya setengah jadi | Tidak ada fitur baru setelah pertemuan 7; hanya perbaikan dan persiapan presentasi |
| Guru berubah menjadi mesin penjawab | Tim menunggumu setiap kali mentok dan antreannya makin panjang | Aturan “tiga sebelum aku”: skema, bagian Kalau mentok di Pahami kode, teman tim; baru guru |
Daftar periksa sebelum unit
- Pertanyaan pemantik sudah ditulis di poster dan tertempel di kelas.
- 4 kartu skenario (masalah, kemungkinan sensor, proyek awal) sudah diperbanyak untuk setiap tim.
- Semua 7 set sudah dihitung; setiap sensor sudah dicoba sekali dan memberi nilai di Serial Monitor.
- Arduino IDE dan driver board sudah terinstal di komputer dan kabel USB sudah dites.
- Proyek awal bisa dibuka di ponsel atau tablet siswa; kalau proyek Premium dipakai, kodenya sudah dibagikan.
- Formulir kartu masalah, kontrak tim, dan log uji sudah dicetak untuk setiap tim.
- Pimpinan sekolah sudah menyetujui keliling sekolah dan pengukuran lapangan; waktu pengukuran untuk kantin, koridor, dan kebun sudah ditentukan.
- Audiens presentasi akhir (pimpinan sekolah, staf sekolah, kelas lain) sudah diundang dan sudah mendapat tanggal.
- Tabel kriteria PjBL sudah dicetak untuk pemeriksaan tengah (pertemuan 4) dan presentasi akhir (pertemuan 8).
Produk sesungguhnya dari unit ini bukan perangkatnya, melainkan kebiasaan siswa untuk “mengukur dulu, baru memutuskan”; perangkat di meja hanyalah buktinya. Di percobaan pertamamu, kamu tidak harus membuka keempat skenario; mulai dengan dua skenario dan enam tim juga mengajarkan siklus yang sama. Kalau kamu ingin merakit proyek awalnya sendiri sekali sebelum membawanya ke kelas, cukup unduh aplikasi BlueGrays dan coba Lampu Tidur dengan LDR dengan skema rangkaian, kode, dan langkah-langkah Pahami kode-nya.
Pertanyaan umum
Apa itu pembelajaran berbasis proyek?
Pembelajaran berbasis proyek (PjBL; dalam bahasa Inggris sering disingkat PBL) adalah pendekatan mengajar yang membuat siswa mempelajari materi sambil mencoba memecahkan masalah nyata. Sebuah unit dimulai dengan pertanyaan pemantik, berlanjut melalui riset, pembuatan prototipe, pengujian, dan perbaikan, lalu diakhiri dengan presentasi kepada audiens nyata. Dengan Arduino, artinya perangkat berfungsi yang mengukur dengan sensor dan memberi peringatan, ditambah data yang mendukungnya.
Apa bedanya pembelajaran berbasis proyek dengan sekadar mengerjakan proyek?
Kalau siswa sekadar mengerjakan proyek, materi diajarkan dulu dan proyek di akhir menunjukkan apa yang sudah mereka pelajari. Dalam pembelajaran berbasis proyek, proyek itulah pelajarannya; siswa mempelajari materi sambil memecahkan masalah, tepat ketika mereka membutuhkannya. Penilaiannya juga tidak hanya melihat produk, tetapi juga definisi masalah, keputusan berbasis data, dan perbaikan antarversi.
Berapa lama sebaiknya unit PjBL Arduino?
Untuk kelas dengan dua jam pelajaran seminggu, 4 minggu atau 8 pertemuan adalah awal yang baik: satu minggu untuk masalah dan riset, satu untuk prototipe, satu untuk pengujian dan perbaikan, dan satu untuk presentasi. Unit yang lebih pendek cenderung kehilangan tahap pengujian. Akan sangat membantu kalau siswa sudah pernah menyalakan LED dan membaca sensor sebelum unit dimulai.
Bagaimana cara menulis pertanyaan pemantik?
Pertanyaan pemantik yang baik bersifat terbuka, penting bagi orang nyata di sekolah, dan bisa dipersempit menjadi besaran yang terukur. Buat pertanyaan bersamanya tetap luas, misalnya “Bagaimana kita bisa mengukur masalah energi, air, kebisingan, atau udara kelas di sekolah kita dan memberi peringatan tentangnya?” Setiap tim lalu mempersempitnya menjadi sub-pertanyaan sendiri dengan satu tempat, satu waktu, dan satu besaran.
Masalah sekolah apa saja yang bisa dipecahkan siswa dengan Arduino?
Lampu yang dibiarkan menyala di kelas kosong (LDR dan PIR), penyiraman tanaman di kebun sekolah (sensor kelembapan tanah), kebisingan di kantin dan koridor (sensor suara KY-038), serta suhu dan kelembapan kelas (DHT11 atau DHT22) adalah empat contoh yang muat dalam empat minggu. Semuanya berjalan dengan 5 V dari USB dan tidak ada yang membutuhkan instalasi listrik PLN.
Bagaimana cara menilai pembelajaran berbasis proyek?
Tambahkan tiga kriteria PjBL ke rubrik proyek umum: definisi masalah, keputusan dari data, dan iterasi. Pakai pemeriksaan tengah singkat di pertemuan 4 untuk meluruskan arah, lalu nilai ketiga kriteria bersama presentasi di pertemuan terakhir. Log uji dan jawaban pertanyaan penutup menjadi bukti untuk nilai proses.
Proyek untuk dibuat setelah membaca ini
Lihat semua proyek
Lampu Tidur dengan LDR
Lampu tidur kecil yang menyala sendiri ketika gelap dan mati ketika pagi tiba. Sensor cahaya mengukur seberapa terang ruangan, dan Arduino menyalakan LED ketika cukup gelap lalu mematikannya lagi keti
Mengukur Intensitas Cahaya dengan LDR
Ingin melihat seberapa terang kamarmu dalam bentuk angka? LDR, komponen kecil yang bereaksi terhadap cahaya, mengukur cahaya di sekitarnya, dan Arduino menulis nilainya ke layar komputermu setiap sete
Lampu Lalu Lintas
Tiruan mini lampu lalu lintas yang kamu lihat di jalan setiap hari. Merah menyala dua detik, kuning menyala sebentar, hijau menyala dua detik, lalu kembali ke merah lewat kuning lagi, terus berulang.
Suhu dan Kelembapan dengan DHT11
Seberapa hangat kamarmu, dan apakah udaranya lembap atau kering? Sensor DHT11 mengukur suhu dan kelembapan, dan Arduino menulis nilainya di layar LCD dua baris, diperbarui setiap beberapa detik. Jika
Pengukuran Jarak HC-SR04 (Tampilan Serial)
Sensor HC-SR04 bekerja persis seperti kelelawar yang mencari jalan dalam gelap: ia mengirim suara yang tidak bisa kamu dengar, mendengarkan pantulannya, dan mengukur seberapa jauh benda di depannya. A
Suhu dan Kelembapan DHT22 ESP32 (dengan Layar LCD)
Proyek ini mengukur suhu dan kelembapan sekitar dengan sensor DHT22 dan menampilkan datanya secara real-time di LCD I2C 16x2. Data dibaca dari sensor dengan protokol satu kabel lewat library Adafruit DHT. Proyek ini menjadi dasar untuk stasiun cuaca IoT, otomasi rumah pintar, atau sistem pemantauan lingkungan di rumah kaca. Komunikasi dengan DHT22 dilakukan lewat pin GPIO 4 ESP32.
Stasiun Penyiraman Pintar
Tukang kebun yang menyiram tanamanmu sendiri, supaya tanaman tidak kering ketika kamu berlibur. Sensor kelembapan tanah mengukur seberapa basah tanahnya; ketika kering, Arduino menyalakan pompa air be
Pendeteksi Gerakan dengan Sensor Gerak
Penjaga sederhana yang memberi tahu ketika ada orang masuk ke ruangan. Sensor gerak menangkap panas yang dipancarkan tubuh manusia, dan Arduino menjaga LED tetap menyala selama ada gerakan lalu memati