Transkrip terperinci dari laporan lain dari pertemuan Yandex.Zhelezo - tentang pengembangan perangkat untuk UAV.
- Halo semuanya, nama saya Vitaly Podkolzin, saya adalah kepala pengembangan sistem tertanam untuk proyek kendaraan tak berawak. Dan hari ini saya ingin berbicara dengan Anda tentang apa itu mobil tak berawak, komponen apa yang termasuk dalam komposisinya, cara membuat mobil bergerak dan bagaimana autopilot dan komponennya bekerja tergantung pada perangkat yang digunakan.
Untuk memahami ke mana harus pergi selanjutnya, seseorang pertama-tama perlu mencari tahu di mana dia berada. Mobil tak berawak juga. Untuk ini, subsistem pelokalan bertanggung jawab atas kami. Maka Anda perlu memahami apa yang terjadi di sekitar kita. Sistem persepsi atau persepsi bertanggung jawab atas visi, persepsi dunia kita. Berdasarkan data lokasi, tentang benda-benda di sekitar kita, kita dapat membuat perkiraan tentang situasi jalan, perkembangannya, pada perilaku pengguna jalan. Dan pilih rute pergerakan, lintasan, optimal yang mengubahnya menjadi aksi kontrol.
Tetapi semua hal di atas, dalam kasus umum, algoritma. Dan Anda dapat menjalankan algoritme ini di komputer Anda, jika cukup kuat. Tentu saja, ini tidak akan membuat mobil tak berawak keluar dari komputer. Dua hal penting hilang.
Yang pertama adalah serangkaian sensor yang cukup kaya, yang utamanya terdaftar pada slide. Dan tentu saja, kita membutuhkan platform yang akan menjalankan perintah kita. Anda perlu berinteraksi dengannya.
Mari kita bahas masalah interaksi dengan mobil. Autopilot, seperti halnya seseorang, perlu melakukan hal-hal sederhana untuk mengendarai mobil: memutar roda, mempercepat, memperlambat. Solusi logis mungkin tampaknya menggunakan aktuator untuk mengendalikan tubuh ini.
Tetapi pendekatan ini memiliki sejumlah kesulitan yang signifikan. Pengembangan kendaraan tak berawak masih menyiratkan keberadaan pengemudi pada tahap tertentu - Anda perlu membawa mobil ke layanan atau memantau autopilot ketika kami menguji berbagai fitur, terutama pada tahap awal. Perangkat ini secara signifikan mempersulit kehidupan pengemudi.
Tentu saja, keseluruhan sistem itu kompleks, dan secara umum mekanika seperti itu dapat menyebabkan penundaan yang tidak menyenangkan pada kontrol. Ini berdampak negatif pada sirkuit kontrol kendaraan.
Ya, kami masih membutuhkan platform sederhana pada awal proyek, tetapi kami membutuhkan beberapa pendekatan lain untuk berinteraksi dengan platform ini. Dan kami mulai menggali jauh ke dalam mobil.
Setelah mempelajari fitur-fitur platform yang berbeda, kami menemukan bahwa banyak mobil modern memiliki kemampuan untuk mengendalikan organ mobil mereka sendiri. Misalnya, seorang asisten mengendalikan setir saat parkir. Kontrol pelayaran memengaruhi akselerasi mobil, kontrol pelayaran adaptif, atau sistem batas kecepatan dapat memengaruhi sistem pengereman.
Semua sistem ini, biasanya, ditutup dengan mobil. Dan untuk berinteraksi dengan mereka, butuh pengembangan sejumlah perangkat khusus. Selain berinteraksi dengan mobil, sistem ini diperlukan untuk menyediakan antarmuka yang nyaman dan ramah pengguna untuk mengendarai mobil. Dan tentu saja, sistem seharusnya sederhana, mudah, dan sangat fleksibel.
Kami datang ke platform di mana, tergantung pada mobil, papan kontrol kecil dikembangkan yang berinteraksi dengan node tertentu. Komposisi dan fungsionalitas papan ini berbeda dari platform ke platform, tetapi mereka semua datang bersama dalam satu jaringan, di mana ada unit kepala, yang secara konvensional kami sebut sebagai gateway. Ini memonitor perangkat ini. Selain itu, gateway menyediakan antarmuka untuk autopilot pada perangkat yang nyaman. Di sini kita melihat Ethernet, nyaman untuk infrastruktur kami, dan CAN, antarmuka otomotif paling populer. Selain itu, unit kepala kami terus berinteraksi dengan mobil, memantau status komponen dan rakitan. Jika ada penyimpangan yang terdeteksi, maka, tergantung pada sifatnya, bersama dengan autopilot, keputusan dibuat pada langkah selanjutnya.
Kami memutuskan untuk menerapkan papan pada mikrokontroler yang cukup populer dan terbukti. Kami membawa mereka dengan margin kinerja dan memilih mereka yang mendukung antarmuka yang diperlukan untuk bekerja: CAN / Ethernet dan input / output digital analog.
Kami mendapat solusi yang benar-benar fleksibel untuk kami dan yang memungkinkan kami beralih dari platform ke platform dengan lebih sedikit masalah.
Mari kita bicara tentang sensor. Setiap kendaraan tak berawak memiliki serangkaian sensor yang kaya. Setiap kendaraan tak berawak Yandex memiliki empat penutup di atap dan tiga di depan, enam kamera yang diletakkan di atap, dan enam radar: dua di belakang dan empat di depan, dua di antaranya terletak di samping.
Kami mengambil radar, kamera, kamera, terhubung, drive ke komputer. Tapi tidak sesederhana itu. Sangat penting untuk memastikan bahwa data sensor memadai dan berkualitas tinggi. Kami melakukan sejumlah besar percobaan untuk memahami di mana menempatkan sensor, sehingga kami dapat melihat dunia lebih baik dan lebih jelas.
Selain itu, desainer kami harus bekerja keras untuk memastikan bahwa semua perubahan pada mobil yang terkait dengan sensor memenuhi persyaratan lembaga sertifikasi.
Inilah yang terjadi. Enam kamera di atap memberikan tampilan 360 derajat yang baik dengan tumpang tindih yang signifikan - area gelap ditandai pada slide. Kamera-kamera ini juga memberikan tampilan vertikal yang bagus. Kamera adalah satu-satunya sensor yang melihat lampu lalu lintas, karena mereka dapat ditempatkan di berbagai bagian, tergantung pada persimpangan dan hal-hal lain.
Radar adalah sensor penting lainnya untuk setiap mobil. Mereka menarik karena memiliki sudut pandang yang tidak terlalu lebar, tetapi rentang yang baik. Dua radar frontal melakukan fungsi pemantauan apa yang terjadi di depan, radar belakang dalam algoritme kami digunakan, sebagai aturan, dalam membangun kembali, menyalip, dan manuver serupa. Radar yang terlihat menyamping diperlukan untuk mengemudi melalui persimpangan yang cukup rumit di mana informasi dari sensor mungkin tidak cukup.
Mungkin sensor yang paling menarik adalah LIDAR. Dia tertarik pada informasi yang datang darinya. Ini adalah cloud point, point cloud, ini adalah data dari lidars. Mereka menunjukkan pejalan kaki, mobil, jalan, bahkan tepi jalan dan benda lainnya. Kotak sudah merupakan hasil kerja dari algoritma pengenalan kami.
Secara total, semua sensor memberikan kira-kira gambar yang sama. Seperti yang Anda lihat, tidak mungkin untuk tidak melihat apa pun di sekitar mobil dengan set sensor seperti itu.
Saya ingin membahas dua contoh yang kami temui ketika kami perlu mengembangkan perangkat keras. Saya akan mulai dengan kasus lokalisasi.
Sumber utama adalah kartu definisi tinggi. Pada setiap titik waktu, kendaraan tak berawak membandingkan data dari lidar dengan kartu-kartu ini. Berdasarkan perbandingan seperti itu, ia mendapatkan lokasinya dengan akurasi sentimeter. GPS, Glonass atau navigasi satelit lainnya sama sekali tidak cocok untuk bekerja dengan kendaraan tak berawak karena stabilitasnya yang rendah, ketergantungan yang tinggi pada kondisi eksternal, cuaca, kebisingan, gangguan. Di kota, semua ini sangat rumit oleh tumpang tindih sinyal, pantulan dari gedung, dll. Tapi dari mana kita mendapatkan kartu-kartu ini? Kami membuat peta sendiri, menggunakan kendaraan tak berawak kami dengan satu set sensor.
Untuk membangun peta-peta ini, kita membutuhkan sitar dan semacam referensi di lapangan. Anda perlu entah bagaimana mendapatkan koordinat Anda. GPS awalnya bisa memberikan koordinat, tetapi akurasinya tidak terlalu tinggi. Seperti yang saya katakan, keakuratan GPS dipengaruhi oleh kondisi atmosfer, gangguan, dan di kota juga ada pantulan.
Teknologi kinematik waktu-nyata datang untuk menyelamatkan. Intinya adalah: di suatu tempat di tanah sebuah stasiun pangkalan tetap dipasang dengan perangkat penerima yang sama seperti pada mobil. Jika jarak antara mobil dan stasiun pangkalan tidak melebihi 30 km (dalam beberapa kasus 50 km), maka data satelit yang diterima oleh mobil dan stasiun pangkalan akan kira-kira sama. Tetapi stasiun pangkalan, mengetahui koordinat yang tepat (itu adalah stasioner) dan menghitung koordinat sesuai dengan data satelit, menerima, secara kondisional, kesalahan perhitungan. Berdasarkan kesalahan ini, dikembangkan amandemen yang dikirim melalui mobil ke mobil melalui Internet. Mobil, dengan mempertimbangkan koreksi yang diterima ketika menghitung koordinat oleh satelit, mendapatkan koordinatnya dengan akurasi sentimeter. Tentu saja, untuk bekerja dengan sistem ini, Anda memerlukan saluran internet yang baik dan cuaca yang baik sehingga sinyal GPS stabil.
Untuk mendapatkan perangkat yang berfungsi dengan dukungan RTK di mobil atau stasiun pangkalan, Anda memerlukan perangkat lunak. Perpustakaan yang menyediakan fitur RTK RTKLib tersedia untuk umum. Ada variasi yang berbeda dengan fitur yang berbeda. Perpustakaan biasanya memerlukan lingkungan Linux dan modul navigasi satelit yang menyediakan data mentah.
Setelah melakukan beberapa percobaan, membuat prototip beberapa hal, kami mendapat diagram blok dari blok pelokalan, yang kami sebut GeoHub.
Selain modul navigasi satelit yang ditentukan, ada juga modul pengukuran inersia, yang kami gunakan dalam sistem pelokalan. Internet sekarang datang melalui antarmuka Ethernet yang nyaman untuk infrastruktur kami.
Ini adalah perangkat kedua, generasi keduanya dan karakteristik teknis utama.
Kami mengganti modul pengukuran inersia dan modul sinyal satelit. Sebagai hasilnya, ini memungkinkan kami untuk melakukan serangkaian percobaan pada mobil dan memilih modul pengukuran inersia yang optimal dari sudut pandang berbagai parameter, dan untuk modul sinyal satelit, kami dapat beralih ke penerima dual-band dalam proses tersebut, yang secara signifikan meningkatkan kualitas penentuan lokasi.
Mengapa mengembangkan perangkat Anda ketika Anda pasti bisa pergi ke pasar dan membeli sesuatu yang serupa? Jawabannya adalah bagi kami, salah satu parameter terpenting adalah fleksibilitas perangkat. Karena persyaratan yang berubah dengan cepat dalam proyek ini, muncul fungsionalitas baru, kami harus dapat merespons dengan sangat cepat. Hanya dengan memiliki dalam proyek, in-house, pengembangan perangkat keras dan perangkat lunak, kami mendapatkan kecepatan perkembangan yang sangat tinggi dari perubahan ini.
Sensor lain yang menarik dari sudut pandang kendaraan tak berawak adalah kamera. Oke, ada kamera di setiap ponsel dan laptop. Apa yang bisa rumit di sini? Tapi mari kita lihat masalah apa yang mungkin Anda temui saat menggunakan kamera dalam drone.
Masalah pertama adalah kelap-kelip sumber cahaya LED. Sebagian besar lampu lalu lintas hanyalah sumber seperti itu. Video berhenti pada saat ketika, karena berkedip, sinyal merah hampir menghilang.
Untuk masalah ini, ada solusi perangkat keras yang tertanam dalam sensor, tetapi agar dapat bekerja dengan baik dan dengan kualitas tinggi, Anda harus dapat berinteraksi secara aktif dengan sensor.
Persyaratan kedua untuk kamera adalah rentang dinamis yang tinggi, yaitu kemampuan untuk bekerja dalam kondisi cahaya apa pun, baik di malam hari maupun di bawah sinar matahari yang cerah. Kehadiran HDR juga penting, yaitu kemungkinan menggabungkan frame dengan pencahayaan berbeda menjadi satu untuk mendapatkan gambar yang lebih baik.
Di sebelah kiri adalah contoh gambar di mana fungsi HDR digunakan, dan di sebelah kanan - di mana ia dinonaktifkan.
Selain itu, kita tentu saja harus mendapatkan gambar dengan resolusi yang cukup dan frame rate yang cukup. Pada slide, beberapa poin lagi disorot, melekat pada kendaraan tak berawak, termasuk. Kamera harus menghasilkan aliran video yang tidak terkompresi, lebih disukai dari format RGB888, karena jaringan kami, algoritma bekerja dengan format ini, mereka ingin menerima bingkai dalam format ini.
Sebagian besar kamera, solusi siap pakai di pasar, menyediakan data terkompresi - H264, MPEG. Masalahnya di sini sederhana: kita kehilangan kualitas selama kompresi dan memperkenalkan penundaan dalam kompresi dan dekompresi. Keterlambatan dapat bersifat non-deterministik, terutama pada beban sistem yang tinggi. Kamera dengan resolusi Full HD dan frekuensi 30 frame per detik dengan bit rate 16 bit per pixel menghasilkan aliran sekitar gigabit per detik dari data video murni.
Selain itu, kamera biasanya terletak pada jarak tertentu dari perangkat penerima, dan di dalam mobil, terutama selama beberapa percobaan, mereka dapat ditempatkan secara umum di ujung lain dari mobil. Kami membutuhkan kamera yang memungkinkan seluruh aliran video terkompresi ditransmisikan pada jarak 6-8 meter, dengan mempertimbangkan pemasangan kabel. Untuk kamera Full HD dengan 16 bit per piksel, aliran video adalah 1 gigabit, yang tidak lagi memungkinkan penggunaan gigabit Ethernet, karena berbagai data layanan dan sebagainya terlibat dalam transfer. Sepuluh gigabit Ethernet tidak sepenuhnya sesuai. Itu mahal, konsumsi daya tinggi, disipasi panas tinggi, peningkatan kompleksitas infrastruktur jaringan.
Ya, ada antarmuka menarik lainnya. Saya ingin berbicara tentang mereka berdua yang telah bekerja sama dengan kami. Mereka disediakan oleh Maxim Integrated dan Texas Instruments. Kekhasannya adalah bahwa aliran video diserialkan menjadi data yang berjalan pada tingkat fisik yang sederhana, dalam hal ini melalui kabel koaksial, pada kecepatan 3-4, kadang-kadang 6 gigabit per detik. Selain itu, antarmuka ini memungkinkan Anda menggunakan saluran balik untuk mengontrol kamera pada kabel koaksial yang sama. Dan di atasnya daya kamera bisa pergi. Semua hal di atas membuat antarmuka ini sangat menarik.
Ketika kami mulai, kami menemukan solusi di pasar yang pada dasarnya memenuhi sebagian besar persyaratan. Kami menggunakannya untuk beberapa waktu pada awal proyek.
Diagram blok solusi ada di depan Anda. Ini adalah sensor dari mana data diserialisasi ke antarmuka GMSL / FPD-Link. Pada bagian penerima, yang dapat dihilangkan hingga 15 meter, data tersebut di-deserialisasi dan dikirim ke penerima. Dalam solusi kami, receiver ini kemudian menyediakan data melalui antarmuka USB 3.0.
Tetapi mulai menggunakan solusi ini, kami menemukan sejumlah masalah yang tidak menyenangkan. Masalah utama - solusinya bekerja sangat tidak stabil, "jatuh" dalam proses, kamera tidak memulai dengan baik ketika autopilot dimulai. Selain itu, solusinya tidak memungkinkan untuk menyesuaikan parameter sensor itu sendiri untuk meningkatkan kualitas gambar. Ada juga sejumlah masalah. Misalnya, sulit untuk mendapatkan stempel waktu yang tepat dari kamera, waktu pemotretan, yang cukup penting, karena pada kecepatan 15 m / s dengan penundaan 100 md, mobil sudah menempuh jarak satu setengah meter, dan ini dapat sangat negatif mempengaruhi algoritma persepsi.
Ada hal menarik lainnya. Antarmuka output dari solusi yang dipilih adalah USB 3.0, dan kami menemukan bahwa itu sangat bising. Bagaimana kita memahami ini? Kami punya dua mobil yang tidak terhubung dengan apa pun. Pada satu, mereka meluncurkan kamera, pada keduanya, sinyal navigasi satelit tenggelam sangat banyak. Kemudian kami mulai mempelajari apa yang sedang terjadi.
Setelah menganalisis semua kekurangan ini secara umum, setelah mempelajari diagram struktural di depan Anda dan seterusnya, kami sampai pada kesimpulan bahwa masalahnya ada di bagian penerima. Kemudian mereka mulai berpikir apa yang harus dilakukan dengannya. Kami melihat apa yang ada di pasaran, solusi dari tim lain, dan sampai pada kesimpulan bahwa kami perlu membuat perangkat penerima kami sendiri yang akan bekerja dengan kamera melalui antarmuka GMSL atau FPD-Link.
Kami mengambil deserializers, yang, sebagai suatu peraturan, memiliki output antarmuka MIPI CSI2, dan mulai mencari modul atau prosesor yang dapat mendukung antarmuka ini. Dan kami menemukan solusi yang menarik dengan enam antarmuka MIPI CSI2, serta perangkat berperforma tinggi dan kaya. Ini memungkinkan kami untuk akhirnya menggunakan antarmuka Ethernet 10 gigabit yang nyaman untuk infrastruktur jaringan kami sebagai antarmuka keluaran perangkat ini. Setelah menerima data GMSL / FPD-Link dari 6 kamera (atau, dalam beberapa kasus, dari 12 kamera), setelah memprosesnya, perangkat mentransfer aliran video yang sudah diproses lebih jauh ke komputer melalui Ethernet 10-gigabit.
Inilah solusi itu sendiri dan karakteristik utamanya. Setelah mengembangkan hal seperti itu, kami belajar tidak hanya bagaimana bekerja dengan 6 atau 12 kamera secara andal, tetapi juga mendapat kesempatan untuk menyempurnakan kamera. Ini memungkinkan untuk meningkatkan kualitas gambar, yang secara positif mempengaruhi operasi algoritma persepsi. Kami juga mendapat pemahaman yang jelas tentang waktu yang dibutuhkan untuk memotret bingkai, dan belajar cara mengelola waktu ini. Dan CPU berkinerja tinggi, daya komputasi modul memungkinkan kami untuk melakukan pemrosesan video awal dengan penundaan minimal langsung pada modul.
Codec perangkat keras dari modul ini juga memungkinkan untuk mengompresi data video untuk penyimpanan selanjutnya dalam log.
Kami harus bekerja tidak hanya dengan sensor lokalisasi dan kamera. Kami harus mengembangkan solusi perangkat keras untuk hampir semua sensor yang kami gunakan. Semua ini dilakukan untuk mengatasi peningkatan keandalan dan kualitas data yang menjadi dasar algoritma deteksi dan persepsi. Dan itu tergantung pada mereka seberapa optimal solusi yang dikeluarkan oleh autopilot.
Oke, kami belajar cara mengendarai mobil, mengerjakan sensor, memposisikannya dengan baik, mengajari mereka untuk memberi kami gambar berkualitas tinggi. Apa pekerjaan lain yang dilakukan para insinyur sistem embedded, pekerja perangkat keras pada proyek kami? Kami memantau tidak hanya pengembangan sensor yang telah menjadi rutin, tetapi juga sumber informasi alternatif. Kami terus mengeksplorasi akselerator alternatif jaringan saraf dan algoritma lainnya, termasuk yang menggunakan FPGA. Dan sulit membayangkan perkembangan proyek tanpa interaksi dengan pembuat mobil berpengalaman.
— , , .
. , . , , , . , .