Expertise · Systeme für Roboter

Software für Roboter: die Schicht, die die Bewegung entscheidet, das Sehmodul und das Hörmodul. Heute haben wir Offline-Prüfung und Simulation — wir haben nichts, was einen echten Motor ansteuert.

Wir schreiben Kinematik, Bahnverifikation und reproduzierbare physikalische Simulation, mit Gates, die blockieren, wenn der Nachweis fehlt. Für Vision haben wir einen Prototyp auf einer festen Kamera, nicht auf einem Roboter. Für Audio auf dem Roboter haben wir nichts gebaut, und die Seite sagt das, statt Belege von der Telefonie zu übernehmen. Wir arbeiten nicht mit ROS.

Ein Projekt besprechen

Angebot, mit BedingungenAm rulat azi tot ce se poate rula. Stratul de control există și e serios, dar e offline: un modul propriu de cinematică pentru un braț cu șase axe, care a rezolvat 8.400 din 8.400 de puncte de traseu, și un validator de fizică pe MuJoCo 3.10.0 cu 34 de teste trecute, plus 14 teste pe partea de vizualizare. Amândouă declară în propria sursă că nu au transport către hardware și nu pot comanda un robot real. La vedere avem un prototip propriu — detecție și urmărire de persoane pe cameră IP fixă — cu un singur comit și cu directorul de teste gol. La audio pe robot avem zero: tot ce e pe disc e voce de call-center sau bibliotecă terță de telefonie, iar singura lucrare acustică proprie s-a încheiat cu un rezultat negativ, scris în aplicație. ROS: zero instalat, zero scris. Regula cere minimum două implementări proprii pentru „am făcut”; pe control le am, dar niciuna nu atinge hardware, iar celelalte două straturi ale serviciului sunt sub prag. Deci: ofertă cu condiții, cu granițele desenate.

Die Software eines Roboters hat drei Schichten, die auf unterschiedliche Weise kaputtgehen: was sieht und hört, was entscheidet, und was an die Motoren gesendet wird. Auf den ersten beiden haben wir eigene Arbeiten mit laufenden Tests. Auf der dritten — der Brücke zur Hardware — haben wir nichts, und das ist die Grenze des Dienstes, kein Implementierungsdetail. Zwei unserer Codes sagen das in ihrem eigenen Header auf Englisch, genau damit es nicht falsch gelesen werden kann: Das Kinematikmodul hat keine Anbindung an Hardware und kann keinen echten Roboter steuern.

Was es auf der Bewegungsseite gibt, ist Prüfung vor der Bewegung. Ein eigenes Modul berechnet die Vorwärtskinematik, die Jacobi-Matrix und die inverse Kinematik für einen Arm mit sechs Achsen, mit einem vorgeschriebenen Puffer gegenüber den Grenzen jeder Achse, und wurde genutzt, um eine komplette Bahn zu prüfen: 8.400 angeforderte Punkte, 8.400 gelöste, wobei die maximale Geschwindigkeit pro Achse unter 8% des Kataloglimits blieb. Separat läuft ein Physik-Validator auf MuJoCo 3.10.0 auf der CPU, mit einem Rechenschritt von einer Millisekunde, in sechs Szenarien, jedes zweimal, mit demselben Seed — und die zwei Läufe liefern identische Fingerabdrücke. Determinismus ist keine Behauptung, sondern ein Vergleich von Prüfsummen.

Was es auf der visuellen Seite gibt, ist weniger, und es ist ehrlich, das zu sagen. Ein eigener Prototyp macht Personen-Detektion und -Tracking auf IP-Kamerastreams, mit einem kleinen Detektor aus der YOLO-Familie, einem Multi-Object-Tracker, Pose-Schätzung für fünf Zustände und der Steuerung von Schwenk-Neige-Zoom der Kamera. Er hat nur einen Commit und ein leeres Testverzeichnis. Und der Unterschied zwischen dem und der Sicht eines Roboters ist real, nicht formal: Die Kamera auf einem Roboter bewegt sich mit ihm, die Szene ist nah, die Belichtung ändert sich bei jedem Schritt, und das Latenzbudget ist ein anderes, weil das Bild zu einer Bewegungsentscheidung gelangen muss, nicht zu einem Bildschirm. Wir haben keine Tiefenkamera, keine Kamerakalibrierung, keine visuelle Odometrie.

Auf der Robotik-Audioseite haben wir nichts aufgebaut, und wir werden keine Belege von anderswo ausleihen. Wir haben echte Spracharbeit für Telefonie und für konversationelle Assistenten, aber ein Mikrofon auf einem Roboter hat andere Probleme: Eigenrauschen der Maschine, Ventilatoren und Servomotoren, die genau dann anspringen, wenn sich der Roboter bewegt, die Richtung, aus der die Stimme kommt, der Nachhall im Raum und der variable Abstand. Die einzige eigene akustische Arbeit, die wir haben, endete mit einem negativen Ergebnis, in der Anwendung festgehalten, und wir veröffentlichen es so — weil ein gemessenes negatives Ergebnis nützlicher ist als ein Versprechen.

Was dazugehört

Die Arbeit, nach Bestandteilen

Wir prüfen die Kinematik, bevor wir etwas bewegen

Direkte Kinematik, analytischer Jacobi aus Kreuzprodukten aufgebaut, numerische inverse Kinematik mit vier Startpositionen und einem durch 10° gegenüber der Grenze jeder Achse vorgegebenen Reserve, mit Konvergenz bei 0,05 mm pro Position. Damit haben wir eine Anordnung in 1.331 Gitterpositionen und einen vollständigen Pfad von 8.400 Punkten überprüft, alle gelöst. Die Ergebnisse: maximale Achsgeschwindigkeit bei 7,86% des Kataloggrenzwerts und minimale Marge zu den Grenzen von 19,9°. Der Bericht schreibt seine Natur selbst: diskretes Offline-Screening, ohne Ausgabe an die Hardware.

Wir trennen Physik vom Bild, und zwar reproduzierbar

Der Physik-Validator ist ein separates Programm vom visuellen Teil, auf MuJoCo 3.10.0, auf dem Prozessor, mit einem Schritt von einer Millisekunde und einer Abtastung alle 20 Millisekunden. Sechs Szenarien, jedes zweimal mit derselben Saat ausgeführt, mit identischen Fingerabdrücken zwischen den Läufen. Die Toleranzen sind im Code deklariert, nicht hineingelesen: Energiedrift unter 1% relativ, Bodendurchdringung unter 3 cm, Verletzung der Gelenkgrenze unter 0,03 Radiant. Was im freien Fall gemessen wird, ist die Beschleunigung des Schwerpunkts, verglichen mit der konfigurierten Gravitation — 9,80665, 1,62 und 3,72076 Meter pro Quadratsekunde.

Wir setzen ein Tor, das blockiert, nicht eines, das nur etikettiert

Das Aktionsregister verlangt von jeder Bewegung, ihre Herkunft anzugeben, und alle 15 registrierten Aktionen sind kinematisch markiert, null validiert — weil kein Controller von ihnen durch einen Starrkörpersimulator mit Aktuatorgrenzen und Kontaktvalidierung gesteuert wird. Darüber liegt ein Freigabetor, das die Beweisdatei liest und abfällt, wenn eine Schlüsselkonstante nicht auf Hardware kalibriert ist. Heute fällt es: Eine einzige Gelenkstopp-Konstante von 5 Millisekunden ist im Code als vorläufiger Parameter deklariert, nicht als gemessener Wert — und das reicht, damit die vollständige Prüfung mit einem Fehler endet. Es ist eine von uns gegen uns selbst geschriebene Regel.

Wir lesen die Roboterbeschreibung mit eigenem Parser und sagen, was sie auslässt

Für die Anzeige und Inspektion der Modelle haben wir einen eigenen MJCF-Format-Parser geschrieben: Körper, Scharnier-, freie, gleitende und sphärische Gelenke, Geometrien, Materialien und das Laden von Meshes, mit Geometrie-Cache. Er lässt absichtlich die Kollisionsgeometrien aus, weil es ein visueller Parser ist, kein Kontaktparser — im Code geschrieben, nicht nachträglich entdeckt. Die verwendeten Modelle sind die offiziellen, mit 29 Freiheitsgraden für den Humanoiden und 12 für den Vierbeiner.

Wir verwechseln nicht die kommandierten Werte mit den gemessenen

Die Winkel, die auf dem Bildschirm erscheinen, sind die vom Controller kommandierten, in nur eine Richtung an die Oberfläche veröffentlicht. Sie enthalten kein Encoder-Rauschen, keinen gemessenen Zustand, kein Drehmoment, keine Geschwindigkeit und keine Temperatur — im technischen Audit des Projekts ausdrücklich so geschrieben. Diese Unterscheidung wirkt klein, bis jemand ein schönes Diagramm für Robotik-Telemetrie hält; deshalb schreiben wir sie in den Code, ins Audit und hier.

Vision: Personen-Erkennung und -Verfolgung auf fester Kamera

Ein eigener Prototyp, der IP-Kamerastreams annimmt, Personen mit einem kleinen Modell aus der YOLO-Familie erkennt, sie zwischen den Frames mit einem Multi-Object-Tracker bei einer Vertrauensschwelle von 0,5 verfolgt, die Pose in fünf Zuständen schätzt — unbekannt, sitzend, stehend, gehend, gebeugt — und die Kamera über das Standard-Steuerprotokoll drehen kann. Er läuft zwangsweise auf dem Prozessor, wegen einer im Code vermerkten Inkompatibilität. Sein tatsächlicher Stand: ein einziger Commit und ein leeres Testverzeichnis. Es ist ein Prototyp, kein Produktionsmodul, und es war nie auf einem Roboter.

Audio auf dem Roboter: Wir sagen, was fehlt, statt von Telefonie zu leihen

Wir haben keinen Wake-Word-Detektor, keinen lokal laufenden Sprachdetektor, kein Beamforming, keine Richtungsschätzung und keinen von uns geschriebenen Code zur Echounterdrückung. Was wir im Sprachbereich haben, ist für Telefonanrufe und für konversationelle Assistenten: Das Unterbrechen des Sprechers erfolgt entweder durch den Detektor im Dienst des Anbieters oder durch das Drücken einer Taste im Telefonmenü, und die Echounterdrückung kommt aus den Browser-Bibliotheken oder aus einem Drittanbieter-Telefonie-Stack. Das sind reale Dinge, aber sie lösen ein anderes Problem als ein Mikrofon, das auf einer sich bewegenden Maschine montiert ist und ihren eigenen Lärm erzeugt.

ROS: wir haben es nicht, und wir tun auch nicht so

Es ist auf keiner unserer Maschinen installiert, und wir haben nie einen eigenen Node, eine Startdatei oder ein eigenes Paket geschrieben. Das einzige Paket mit ROS-spezifischem Build-System auf dem Datenträger ist die öffentliche Beschreibung eines Industrieroboters, als Modelldatei heruntergeladen und genau so verwendet, nicht kompiliert. Wenn Ihr Projekt ROS 2 als gegeben voraussetzt, ist das eine Information, die Sie vor dem ersten Gespräch haben müssen, nicht danach.

Was wir akzeptieren und was nicht

Wir würden annehmen: Kinematik- und Trajektorienprüfung vor einer Anschaffung, Simulation mit deklarierten Toleranzen, ein auf Ihren Daten gemessenes Wahrnehmungsmodul und eine Brücke zur Hardware, die zusammen mit dem Integrator erstellt wird, der für die Sicherheit verantwortlich ist. Wir würden nicht annehmen: allein die Schicht zu schreiben, die einen Roboter im Notfall stoppt, ein Audiomodul auf dem Roboter ohne vorherige Messung des Eigenlärms Ihrer Maschine zu versprechen, und auch nicht zu sagen, dass unsere Erfahrung mit Stimme am Telefon das Hören eines Roboters abdeckt.

Wie es aussieht

Der Weg, Schritt für Schritt.

Wir definieren die Aufgabe und die physischen Grenzen, dann prüfen wir, ob es hineinpasst

Was der Roboter erreichen muss, in welchem Volumen, mit welcher Geschwindigkeit und mit welcher Last. Danach die Prüfung: Volumenabdeckung, Spielraum gegenüber den Grenzen jeder Achse, Geschwindigkeit und Beschleunigung auf der Bahn, Kollisionen an echter Geometrie als Screening. Wir liefern den Bericht mit den schriftlich festgehaltenen Einschränkungen. Diese Etappe hat ein gutes Verhältnis zwischen Kosten und vermiedenem Schaden, weil sie vor einem Kauf durchgeführt wird.

Wir simulieren mit angegebenen Toleranzen und mit überprüfter Deterministik

Szenarien, fester Seed, wiederholte Läufe, Vergleich von Fingerprints, im Code geschriebene Toleranzen. Wir liefern auch die Liste der Dinge, die die Simulation NICHT nachweist — bei uns bestätigt zum Beispiel ein Validator, der freien Fall und Positionshaltung auf einer Testebene bestätigt, nicht das Gehen, komplexen Kontakt oder die Dynamik des Aktuators, und schreibt das selbst.

Wir bauen die Wahrnehmung auf Ihren Daten auf, nicht auf einem öffentlichen Datensatz

Ein Detektor, der auf Bildern aus dem Internet funktioniert, sagt nichts über Ihre Halle aus. Die Etappe bedeutet Erfassung aus der realen Umgebung, ein eigenes Evaluierungsset, eine Referenzmessung und erst dann die Wahl des Modells und des Ausführungsorts. Wir liefern die Referenzwerte und die Methode, mit der Sie sie reproduzieren können, auch wenn sie schwach sind.

Die Brücke zur Hardware — die Etappe, die wir nie gemacht haben

Wir schreiben sie zuletzt und wir schreiben sie mit Bedingungen, weil sie die einzige auf der Liste ist, in der wir keine eigene Erfahrung haben. Sie wird gemeinsam mit dem Integrator oder dem Hersteller des Roboters umgesetzt, und die Funktionen für Notstopp, Begrenzung und Sicherheit bleiben in der Verantwortung dessen, der für die Maschine verantwortlich ist. Was wir bis dorthin liefern können, ist die Entscheidungsschicht, geprüft, mit dokumentierter Schnittstelle.

Lanțul unui robot, de la stânga la dreapta, cu starea reală a fiecărei verigi. Vedere: prototip pe cameră fixă, un singur comit, fără teste. Auz: gol — nimic construit pentru un microfon pe o mașină care se mișcă. Decizie și cinematică: verificat, cu 8.400 de puncte rezolvate și cu o poartă care blochează atunci când o constantă nu e calibrată. Ultima săgeată, cea către motoare, e întreruptă: niciun cod al nostru nu are transport către hardware. Desenul e făcut ca să se vadă unde se oprește serviciul, nu ca să pară complet.

Die Daten

Was wir anfassen, wo die Daten liegen und wie lange sie bleiben

Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.

Die Kamera eines Roboters filmt Menschen, und das verändert alles: Ein Sehmodul, das Personen erkennt und verfolgt, erzeugt personenbezogene Daten im eigentlichen Sinn des Wortes, auch wenn niemand namentlich identifiziert wird. Die Fragen werden vor der ersten Codezeile gestellt: Wird das Bild gespeichert oder nur das Ergebnis, wo wird verarbeitet, wer hat Zugriff auf die Aufzeichnungen, wie lange werden sie aufbewahrt, was wird den Gefilmten angezeigt. Unser Prototyp wurde als technisches Experiment gebaut, nicht als in Betrieb genommenes System, und wir schlagen ihn nicht als solches vor.
Auf dem Gerät oder auf dem Server — eine Entscheidung der Latenz, nicht der Präferenz: Wenn das Bild in eine Bewegungsentscheidung einfließen muss, geht der Weg zu einem Server und zurück direkt ins Reaktionsbudget ein. Wenn das Ergebnis nur angezeigt oder aufgezeichnet wird, ist der Server akzeptabel. Die Entscheidung wird aus dem an Ihrem Fall gemessenen Latenzbudget getroffen und festgehalten. Unser Prototyp läuft zwangsweise auf dem Prozessor, was eine reale Geschwindigkeitsbegrenzung ist, im Code notiert.
Die Simulationen werden mit Seed und Fingerabdruck aufbewahrt: Ein Simulationsresultat ohne Generatorsamen und ohne Prüfsumme der Eingaben ist kein Beleg, sondern eine Geschichte. Unsere Physikberichte tragen den Samen, die Zahl der Läufe pro Szenario, die Version der Engine und den Determinismusstatus; die Kinematikberichte tragen den Fingerabdruck der Eingabedateien. So kann man Monate später prüfen, ob eine zitierte Zahl noch gültig ist.
Audio bedeutet, einen Raum aufzuzeichnen: Ein Mikrofon an einem Roboter hört alles, was um ihn herum geschieht, nicht nur den erteilten Befehl. Die Regel, die wir anwenden würden, ist, dass Daueraufzeichnung nicht standardmäßig existiert, sondern nur das für die Entscheidung notwendige Fenster, und dass das, was zur Verbesserung aufbewahrt wird, eine explizite Wahl mit Frist ist. Ein solches System haben wir noch nicht gebaut, also ist das eine erklärte Position, keine nachgewiesene Praxis.
Die Modelle und Robotbeschreibungen haben ihre eigenen Lizenzen: Die Robotermodelle, die wir in der Simulation verwenden, stammen aus öffentlichen Sammlungen unter permissiven Lizenzen, und die Beschreibungen industrieller Roboter sind öffentliche Herstellerdateien. Sie gehören uns nicht, und wir beanspruchen sie nicht; in Ihrem Projekt wird die Lizenz jeder externen Quelle geprüft, bevor sie in das Lieferobjekt eingeht.

Ein Fall

Eine eigene akustische Messung, die mit „nein“ endete, und warum wir sie veröffentlichen

Die Ausgangslage

In einer eigenen macOS-Anwendung wollten wir herausfinden, ob Lautsprecher und Mikrofon eines Consumer-Geräts als einfacher Sonar verwendet werden können — ein ausgesandtes Signal, sein gemessenes Echo, ein abgeleiteter Abstand. Die Frage ist genau die, die auch bei einem Roboter auftaucht: wie viel kann man über den Raum um sich herum mithilfe der bereits vorhandenen Audio-Hardware herausfinden, ohne zusätzliche Sensoren.

Was wir gebaut haben

Wir haben die komplette Kette aufgebaut, nicht nur eine Skizze: ein 12-Millisekunden-Frequenzsweep, der von 2 bis 8 Kilohertz ansteigt, gefenstert, mit geringer Amplitude ausgesendet; Kreuzkorrelation zwischen gesendetem und aufgezeichnetem Signal; Detektion der direkten Ankunft mit einem Schutzfenster von 1,5 Millisekunden, damit die Nebenkeulen der Autokorrelation nicht für ein Echo gehalten werden; Suche nach dem Echo in einem Fenster von bis zu 60 Millisekunden, mit getrennten Korrelations- und relativen Verstärkungs-Schwellen; Schallgeschwindigkeit, korrigiert um die Lufttemperatur. Fast 800 Zeilen Swift, mit Audio-Path-Detektion — wenn Sender und Empfänger auf verschiedenen Geräten sind, ist die Geometrie bistatisch und eine einzige Verzögerungszeit definiert eine Ellipse, keinen Punkt.

Was dabei herauskam

Die Schlussfolgerung steht in der Anwendung, auf dem Bildschirm, der sagt, was sie messen kann und was nicht: am Lautsprecher und Mikrofon desselben Computers lassen sich nach der Kalibrierung grobe Änderungen der Reflexionen erkennen, weil die Latenz relativ stabil ist. Bei kabellosen Kopfhörern zerstören jedoch aktive Geräuschunterdrückung, Beamforming, der Codec und die variable Latenz die präzise metrische Messung — sie können also zur Kopforientierung verwendet werden, nicht als präzises Sonar. Das haben wir im Produkt geschrieben, nicht in einer internen Notiz.

Was der Fall nicht sagt

Das Ergebnis bezieht sich auf Consumer-Hardware über eine drahtlose Verbindung, nicht auf einen Roboter mit montierten und verkabelten Mikrofonen. Übertragbar ist nicht die Schlussfolgerung, sondern die Methode: Man misst den Kanal, bevor man die Funktion verspricht. Für einen Roboter würde dieselbe Untersuchung beim Eigenrauschen der sich bewegenden Maschine beginnen — und erst das Ergebnis dieser Messung würde sagen, was möglich ist.

Fragen

Was uns die Leute fragen, bevor sie anrufen

Haben Sie Ihre Software jemals auf einen physischen Roboter gesetzt?

Nein. Kein Code von uns hat jemals einen echten Motor gesteuert, und zwei unserer Codebasen erklären das sogar im Dateiheader, damit es nicht missverstanden werden kann. Was wir ausgeführt haben, ist Simulation und Offline-Prüfung. Wenn das für Ihr Projekt ein Problem ist, ist es besser, das gleich im ersten Satz zu wissen, als es erst in der dritten Sitzung zu entdecken.

Was haben Sie dann konkret?

Drei Dinge, alle vor Ihnen ausführbar. Ein Kinematikmodul für einen Sechsachsenarm, das einen Pfad von 8.400 Punkten ohne jeden Fehler geprüft hat, mit einem Mindestabstand von 19,9° zu den Achsgrenzen. Ein Physik-Validator auf MuJoCo 3.10.0, mit 34 bestandenen Tests und mit Determinismus belegt durch identische Fingerabdrücke bei wiederholten Läufen. Und ein Demonstrator im Browser mit 14 Tests, dessen Qualifikationsgate heute absichtlich fehlschlägt. Plus ein Sicht-Prototyp, über den wir offen sagen, dass er nur einen Commit und keinen Test hat.

Arbeiten Sie mit ROS?

Nein. Es ist bei uns nicht installiert, wir haben keinen Node, keine Launch-Datei und kein Paket geschrieben. Das einzige ROS-artige Paket auf unseren Datenträgern ist die öffentliche Beschreibung eines industriellen Roboters, heruntergeladen als Modelldatei für Kinematikberechnungen — als Daten verwendet, nicht gebaut. Wenn Ihr Team bereits in ROS 2 arbeitet und das eine Anforderung ist, beginnen wir dort bei null, und das muss mitgerechnet werden.

Können Sie das Sicht-Modul für unseren Roboter machen?

Mit einer Messphase davor, nicht auf Grundlage des Prototyps, den wir haben. Übertragbar daraus ist die Arbeitsweise — Detektor, Frame-zu-Frame-Tracker, Vertrauensschwelle, wo die Berechnung läuft. Nicht übertragbar ist die Situation: Die Kamera auf einem Roboter bewegt sich, das Subjekt ist nah, das Licht ändert sich bei jedem Schritt, und das Ergebnis muss zu einer Bewegungsentscheidung führen, nicht zu einem Bildschirm. Außerdem haben wir in keinem eigenen Projekt eine Tiefenkamera, Kamerakalibrierung oder visuelle Odometrie. Die erste Phase wäre die Erfassung in Ihrer Umgebung und eine Referenzmessung.

Sie haben Sprachagenten. Ist das nicht dasselbe wie einen Roboter zu hören?

Nein, und wir wollen auch nicht, dass es so wirkt. Am Telefon ist der Kanal bekannt und eng, der Sprecher sitzt dicht am Mikrofon, und eine Unterbrechung des Sprechers wird entweder vom Dienst des Anbieters oder durch einen Tastendruck gelöst. Bei einem Roboter steht das Mikrofon auf einer Maschine, die genau dann, wenn sie sich bewegt, ihr eigenes Geräusch erzeugt, die Stimme kommt aus einer Richtung, die sich verändert, der Raum erzeugt Echo und der Abstand variiert. Das sind Probleme der Akustik, nicht des Gesprächs. Wir könnten mit einer Messung des Eigengeräuschs Ihres Roboters beginnen — aber das wäre eine neue Arbeit, keine Erweiterung der Telefoniearbeit.

Warum veröffentlichen Sie ein Qualifizierungstor, das scheitert?

Weil die Alternative wäre, dass es ohne Aussagekraft passiert. Unser Tor liest eine Nachweisdatei und prüft, ob eine kritische Konstante — die Stillstandszeit am Endanschlag des Gelenks — auf der Hardware kalibriert wurde. Das war sie nicht: Es ist ein vorläufiger Wert von 5 Millisekunden, gesetzt, damit eine stabile Simulation existiert. Solange er vorläufig ist, schlägt die vollständige Prüfung fehl, und alle Aktionen bleiben kinematisch markiert. Der Tag, an dem sie besteht, wird genau deshalb etwas bedeuten, weil sie heute nicht besteht.

Was demonstrieren Ihre Simulationen nicht?

Mehr, als sie demonstrieren, und das ist in den Berichten festgehalten. Der Physik-Validator bestätigt den freien Fall und das Halten der Position auf einer Testfläche — nicht das Gehen, nicht den komplexen Kontakt, nicht die Aktor-Dynamik, nicht die synthetischen Sensoren. Das Trajektorien-Screening bestätigt Kinematik und Geometrie — nicht das Material, nicht flexible Schläuche, nicht Prozessverzögerungen, nicht die Start-Stopp-Rampen des Controllers. Und die Bewegung im Browser ist eine Vorschau, kein Simulationsergebnis.

Wir brauchen eine Sicherheitszertifizierung. Machen Sie das?

Nein. Die Sicherheitsarchitektur können wir entwerfen — separater Kreis für die Bewegungssteuerung, unabhängiger Sicherheitscontroller, sicheres Abschalten des Drehmoments, Bremsen mit Feedback, Fehlzustände, die sicher ausfallen; das haben wir auch in einem eigenen Maschinenprojekt gemacht. Aber die Konformitätsbewertung und die Verantwortung für die in Verkehr gebrachte Maschine bleiben beim Hersteller oder beim Integrator. Diese Rolle übernehmen wir nicht und wir unterschreiben nicht anstelle von jemandem.

Warum steht auf dieser Seite „Angebot“?

Weil der Dienst drei Schichten hat und keine davon die Schwelle vollständig überschreitet, die wir uns gesetzt haben. Bei der Steuerung haben wir zwei eigene Arbeiten mit bestandenen Tests, aber keine erreicht Hardware. Bei der Sicht haben wir einen Prototyp mit einem Commit und ohne Tests. Bei Audio für Roboter haben wir null. Wir hätten eine Seite schreiben können, die nach Erfahrung klingt, mit Wörtern wie „Wahrnehmung“ und „Steuerung“ ohne Zahlen. Sie hätte bis zur ersten Frage eines Ingenieurs standgehalten.

Worauf die obigen Aussagen beruhen (17 Quellen)

`vision.megapromoting.com` nu e un sistem de vederehttps://vision.megapromoting.com · 2026-09-06

16 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.

Wie wir arbeiten Alle Dienstleistungen

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen