Wie wir einen Prototyp eines Roboter-Merchandisers erstellt haben und wie es weitergeht



Coronavirus verbreitet sich weiterhin tödlich in der ganzen Welt und in unserem Land. Wir arbeiten seit fast zwei Monaten von zu Hause aus, wie alle IT-Mitarbeiter auf der ganzen Welt, und einerseits sind wir immer trauriger ĂŒber unseren guten alten Freiraum und die Möglichkeit, alle Aufgaben und Probleme lebhaft und nicht verrĂŒckt zu diskutieren nĂŒtzlicher, aber immer noch seelenloser Zoom (wir hatten leider keine Zeit, ein kalifornisches Lama fĂŒr alle unsere Treffen zu mieten :)). Andererseits denken wir immer mehr ĂŒber die Automatisierung und Robotisierung aller Prozesse nach, einschließlich der Prozesse zur Erstellung der Analysedaten, mit denen wir und unser System arbeiten.

Im Detail erinnern wir uns an unseren ersten Roboter-Merchandiser, den wir vor 2 Jahren als Prototyp hergestellt haben und der immer mehr ĂŒber die zweite Version nachdenkt (und nicht nur nachdenkt!), Die in die kommerzielle Produktion und den kommerziellen Betrieb gebracht werden kann.

In diesem Artikel möchte ich Ihnen sagen, was aus dieser Idee herausgekommen ist, was sich als schlecht herausgestellt hat oder ĂŒberhaupt nicht funktioniert hat und was wir jetzt tun werden, um diese Idee in realen LĂ€den in die Praxis umzusetzen. FĂŒr diejenigen, die interessiert sind, willkommen bei Katze.

Ein kleiner Hintergrund: Unser Unternehmen (ShelfMatch Robotics) begann vor etwa 5 Jahren mit der Automatisierung des Merchandising. Automatisierung bedeutet in diesem Fall, dass wir auf die eine oder andere Weise Fotos von Warenregalen in GeschÀften (in Apotheken, Tankstellen usw.) erhalten, die von HÀndlern hergestellt wurden, alle darauf befindlichen Waren erkennen und den Kunden die erforderlichen Analysen ausstellen.

Sobald wir etwas tiefer in das Thema eintauchten, standen wir sofort vor einem der wichtigsten und komplexesten Probleme - die meisten Merchandiser machen schlechte oder sehr schlechte Fotos. Es ist klar, dass dieses Problem auf verschiedene traditionelle Arten gelöst werden kann, z. B. durch Schulung des Personals, Ausgabe guter GerĂ€te usw., aber aus vielen GrĂŒnden (ich werde sie beiseite lassen, unwichtig) funktionieren diese Methoden nicht immer oder vielmehr nicht immer gut.

Der zweite, nicht weniger wichtige Grund, warum die Automatisierung von Analysen innerhalb des GeschĂ€fts sinnvoll ist, besteht darin, dass GeschĂ€fte jede Sekunde Geld verlieren, weil verschiedene Anzeigefehler auftreten, z. B. nicht vorrĂ€tig oder das Planogramm nicht eingehalten wird. Laut Analysten von Bossa Nova Robotics verlieren sie viel Geld, was zu einem Umsatzverlust von 0,5 Billionen fĂŒhrt. Dollar pro Jahr auf der ganzen Welt. Im Allgemeinen ist fĂŒr das GeschĂ€ft die EinfĂŒhrung von „zusĂ€tzlichen Augen“, die den gesamten Raum des Handelsraums und des Lagers scannen, Ă€ußerst wichtig und wird derzeit nur unzureichend umgesetzt.

In diesem Moment haben wir sofort eine andere, unserer Meinung nach interessantere Entscheidung getroffen - warum nicht das Fotografieren an jemanden delegieren, der im Wesentlichen IMMER alles genau nach den Anweisungen macht und fast nie Fehler macht (wenn man genaue und qualitativ hochwertige Anweisungen berĂŒcksichtigt)? . Sie haben wahrscheinlich schon vermutet, dass es sich um einen Roboter-Merchandiser handelt.

Ich erinnere mich, als wir ĂŒber die verrĂŒcktesten Ideen nachdachten, angefangen von Roboterdrohnen, die durch den Laden fliegen, bis hin zu automatischen Roboterkameras, die entlang Mono-Schienen an der Decke des Ladens fahren. Das erste, was wir gesehen und wirklich inspiriert haben, waren die Roboter der Bossa Nova Robotik, die in amerikanischen LĂ€den (zum Beispiel Walmart) eingesetzt wurden und den Kunden die Möglichkeit gaben, die nahe Zukunft ein wenig zu berĂŒhren. Infolgedessen kamen wir dennoch zu dem Schluss, dass wir einen traditionellen Roboter auf einem „Trolley-Chassis“ wie einem Roboterstaubsauger erstellen und ihn mit allen Arten von Kameras und Sensoren ausstatten mĂŒssen, die zum Navigieren und Fotografieren von Regalen erforderlich sind.

Formulierung des Problems:


Die Problemstellung ist also recht einfach: Wir benötigen einen Prototyp-Roboter, der unabhĂ€ngig (unter Aufsicht des Bedieners, jedoch ohne Steuerung des Joysticks) durch die Regale des GeschĂ€fts fahren, alle diese Regale fotografieren und die Fotos zur weiteren Verarbeitung auf den Server ĂŒbertragen kann. Der Roboter sollte aussehen, wenn auch nicht attraktiv, dann zumindest nicht erschreckend, damit die Ladenbesucher nicht davor zurĂŒckschrecken. Dies ist wichtig, da wir vorhatten, echte Experimente und Messungen in echten offenen LĂ€den durchzufĂŒhren, und niemand sie fĂŒr die Zeit unserer Manipulationen schließen wĂŒrde.

Die erste Version des Roboters wurde nach dem Kommandeur der Replikanten aus dem guten alten benannt. Ich hoffe, jeder kennt Ridley Scotts vertrauten und geliebten Film Blade Runner - Roy (wie wir ihn weiterhin nennen werden).

Woraus Roy bestand


Chassis:

  • Schweizer Motoren maxon - Schweizer, weil ihre chinesischen billigen Kameraden aus irgendeinem Grund sehr schnell in unseren HĂ€nden ausgebrannt sind
  • 4 RĂ€der vom Typ Omni-RĂ€der - zu dieser Zeit schienen wir genau Omni-RĂ€der zu benötigen, damit der Roboter schnell und ohne unnötige Bewegungen die Bewegungsrichtung Ă€ndern konnte
  • Sockel aus Aluminium und Kunststoff
  • Motorsteuerung
  • Batterie
  • NUC mit ROS ĂŒber Ubuntu zur Navigation
  • Lidar RPLidar A2 zum Erstellen von Karten, Navigation und Lokalisierung

Torso (Turm):

  • Aluminiumprofilrahmen
  • KunststoffoberflĂ€che
  • Kunststoffhalterungen fĂŒr Kameras, die auf einem 3D-Drucker gedruckt wurden
  • 4 USB-Bustler-Kameras
  • NUC zum Aufnehmen von Bildern und Senden von Fotos an den Server ĂŒber WLAN
  • 3D-Kamera der Tiefe wie Intel IntelliVision, die wir noch nicht verbinden konnten
  • LCD-Bildschirm zum Debuggen und Anzeigen von Service- und Werbeinformationen

Es war nicht schwer, den Wagen und die Karosserie zusammenzubauen, wir haben mehrere Monate damit verbracht. Bei der Montage und Einstellung des Wagens wurden wir von mehreren ehemaligen Mitarbeitern des TsNII-RTK unterstĂŒtzt.

Wie alles funktionierte und was daraus wurde


Jeder, der mit der Arbeit in ROS vertraut ist, kann dieses Kapitel ĂŒberspringen. Es ist unwahrscheinlich, dass er etwas Einzigartiges oder Originelles darin findet, aber diejenigen, die nicht zum Thema gehören, werden interessiert sein. Ich werde Ihnen gleich sagen, wie das alles in einem echten GeschĂ€ft passiert ist (wir wurden dann im noch lebenden und gesunden SPAR in Kupchino getestet):

  1. Wir kommen in den Laden, finden das Rack, das wir brauchen (der Prototyp wurde in der Produktkategorie Tee getestet, dann wurden weitere 4-5 Produktkategorien fotografiert), wir finden eine unbesetzte Verkaufsstelle (dies war ĂŒbrigens ziemlich schwierig) und packen das gesamte Hab und Gut aus.
  2. Roy ( — , , ).

  3. WiFi- .
  4. Ubuntu+ROS , Game-Pad .
  5. : ROS, Teleop ( ), Gmapping ( ), Rviz ( Roy).
  6. — , Roy , ( , Roy «» «»).
  7. Nachdem die Karte erstellt wurde, speichern Sie sie und hĂ€mmern Sie die Koordinaten der Vermessungspunkte ein (der Anfang des Racks 1 ist Punkt „A“, das Ende des Racks 1 ist Punkt „B“, die Drehung betrĂ€gt 90 Grad, das Ende des Racks 2 ist Punkt „C“ im Grunde genommen das Gestell in Form des Buchstabens "G" entfernt)

FĂŒhren Sie als NĂ€chstes das Fotoskript aus (alles ist bereits ohne Gamepad, echte „Magie“):

  1. Roy geht zur angegebenen Position - Punkt "A".
  2. Roy wird korrekt eingesetzt (mit Kameras im Regal), die Rotationsgrade werden ebenfalls im Skript festgelegt.
  3. Roy fĂ€hrt langsam am Rack entlang, schießt mit jeder Kamera mehrmals pro Sekunde und speichert das Foto im NUC. In diesem Fall werden die Kameras synchronisiert und nehmen gleichzeitig Fotos auf.
  4. Im gleichen Moment beginnt ein anderes Skript mit dem asynchronen Senden von Fotos ĂŒber WLAN an den Server.
  5. Roy fĂ€hrt an einem Rack entlang (Punkt „B“), stoppt die Kameras fĂŒr die Dauer der Drehung, macht eine 90-Grad-Drehung und schaltet die Kameras wieder ein.
  6. Es fĂ€hrt entlang des 2. Racks bis zum Punkt „C“.
  7. Schaltet die Kameras aus.
  8. Kehrt in die Ausgangsposition zurĂŒck (Punkt "A").

Weitere Arbeiten sind bereits direkt auf dem Server:

  1. In dem Moment, in dem alle Fotos auf den Server ĂŒbertragen werden, beginnt der Server mit dem Kleben von Fotos und dem Erkennen von Waren im Regal
  2. Wenn alle Prozesse abgeschlossen sind, gibt es in der WeboberflÀche Regale mit Waren, die mit Warenaufschlag + allen erforderlichen Analysen gekennzeichnet sind (Warenanteil im Regal, nicht vorrÀtig, Vergleich mit dem Planogramm usw.).



Fassen wir zusammen, was wir herausgefunden haben


  • Vielleicht der wichtigste Punkt - wir können einen Prototyp des Roboters selbst erstellen, es ist nichts Unrealistisches daran, das gesamte System (Sammeln von Fotos + Navigation + DatenĂŒbertragung + Datenverarbeitung + Datenvisualisierung) funktioniert, aber dies ist nur ein Prototyp
  • Eine interessante und wichtige Beobachtung - Besucher des GeschĂ€fts haben keine Angst und "scheuen" den Roboter nicht - GroßmĂŒtter bemerken es einfach nicht, Kinder bewundern es, andere sind sehr interessiert an "Was ist das und warum ist es notwendig", Merchandiser machen sich Sorgen, weil es ihr direkter Konkurrent ist
  • Die Frage der Auswahl von Ersatzteilen muss angesichts der Kosten, VerfĂŒgbarkeit und QualitĂ€t mit Bedacht angegangen werden

Roy-Fehler, die nach der Erstellung und PrĂŒfung des Prototyps festgestellt wurden


Das grĂ¶ĂŸte Problem beim Erstellen einer Karte und das damit verbundene Navigationsproblem

  • Die Karte wurde nicht immer genau erstellt
  • Sehr oft wurde es ab dem 1. oder 2. Mal schlecht gebaut. Es dauerte eine halbe Stunde, um eine Karte zu erstellen
  • Roy ging manchmal sogar auf einer guten Karte "verloren" (es war sofort klar, da er anfing, sich an einer Stelle zu drehen und nirgendwo anders hinging, er musste das Gamepad einschalten und zur manuellen Steuerung wechseln)

Wir hatten solche Hypothesen zu diesem Problem:

  • Unsere Omni-RĂ€der rutschten manchmal ĂŒber die glatten Fliesen des Ladens, was die KilometerzĂ€hlerparameter beeintrĂ€chtigen konnte
  • Roy hatte zu wenig "Augen", vielleicht reichte ihm ein Lidar nicht und es mussten weitere Sensoren hinzugefĂŒgt werden
  • Vielleicht war unser Lidar nicht der korrekteste und genaueste oder schlecht abgestimmte, vielleicht lag das Problem darin, insbesondere angesichts der KomplexitĂ€t der Aufgabe (ein kleiner Abstand zum Regal, sehr lange Gestelle).

Andere Nachteile:
  • — (+ ), 30 60 , Roy 2
  • ( ), ( )
  • Roy , , - (QR- , bluetooth- ..)
  • () ( ) , ,
  • ( , , , )
  • ( , ) ( 10 )
  • Roy , , , ( , « »)
  • Roy ( 3-4 ),

2 (Zhora Leon)


Die Pandemie des Coronavirus hat gezeigt, dass in einigen Situationen der Einsatz eines Roboters nicht nur wĂŒnschenswert, sondern sogar notwendig ist. Wenn wir uns in einer Situation befinden, in der es besser ist, das Haus ĂŒberhaupt nicht zu verlassen, können uns Roboter, Lieferboten, ReinigungskrĂ€fte und Analysten bei der Lösung einer Vielzahl wichtiger Probleme helfen. Wenn Sie unseren Roy oder seine BrĂŒder von dieser Seite betrachten, sieht das Projekt noch interessanter aus - zum Beispiel die Idee, einen Roboter-Marschierer in einen Roboter-Desinfektor oder einen Roboter umzurĂŒsten, der die Einhaltung sozialer Distanz ĂŒberwacht und diejenigen, die sich drĂ€ngen, unauffĂ€llig warnt an einem Ort oder in der Warteschlange.

Die Plattform, auf deren Grundlage wir eine neue Version erstellen möchten, kann nicht nur Regale scannen, sondern auch die Gesichter der Besucher erkennen. Andere interessante Merkmale solcher GerÀte könnten sein:

  • gezielte Werbung auf LCD-Bildschirmen: Aus der Serie sehe ich eine Frau mit einem Baby - ich biete Windeln an, ich sehe Rentner - ich biete Waren auf Lager an;
  • Kunden helfen, Produkte zu finden
  • Überwachung von Ladendieben anhand von Personen
  • Lagerbestand, UnterstĂŒtzung der Logistikabteilung bei der Beschaffungsplanung
  • usw. bis hin zum Abstellen von Waren in Regalen

Zusammenfassend können wir sagen, dass wir in der 2. Version des Prototyps sehen möchten:

  • industrielles "sexy" Design, das eine Reihe von "Tricks" aller Art bietet, wie ein GerĂ€t zur Kommunikation mit der Außenwelt (Lautsprecher, Mikrofon, Bildschirme, Kameras, Anzeige von Emotionen usw.)
  • Alle Prozesse mĂŒssen erheblich beschleunigt werden
  • Das neue GerĂ€t sollte einfach zu skalieren und relativ billig sein
  • brauchen Genauigkeit bei der Navigation und Lokalisierung
  • brauchen globale Navigation im gesamten GeschĂ€ft
  • +

P.S. - ( ), , .

P.P.S. , , .

All Articles