Technologie-Stack und Produktportfolio der kognitiven Robotik
Executive Summary
Neura Robotics positioniert sich als Anbieter „kognitiver Robotik“ mit einem klar erkennbaren Muster über die gesamte Produktlinie: Roboter sollen nicht nur Bewegungen ausführen, sondern über integrierte Wahrnehmung (Vision, Audio, Kraft/Taktilität, Safety-Sensing) in variablen, menschengeteilten Umgebungen robust agieren. Das zeigt sich in der Hardware (z. B. Drehmoment-/Encoder-Sensorik, optionale 6‑DoF‑Kraft‑Moment‑Sensoren, Safety‑Detektion ohne physische Barrieren) ebenso wie in der Software (No‑Code/Low‑Code‑Bedienung, Python‑APIs/SDKs, ROS‑2‑Anbindung dort, wo Mobilität und Flotten relevant sind) und im Ökosystemansatz (Neuraverse als Orchestrierungs‑, Digital‑Twin‑ und Skill‑Plattform).
Technisch lässt sich das Portfolio in drei Klassen gliedern: (1) stationäre Cobots/Roboterarme (LARA als 6‑DoF‑Cobot‑Familie, MAiRA als 7‑DoF‑„kognitiver“ Arm mit Touchless‑Safe‑Human‑Detection), (2) mobile Plattformen (MAV als AMR/FTS‑ähnliches „Multi‑Sensing Autonomous Vehicle“; MiPA als persönlicher Assistenzroboter mit SLAM/LiDAR‑Navigation und „offener Plattform“), (3) „Physical‑AI“-Plattformen für unstrukturierte Umgebungen (Humanoide 4NE1/4NE1 Mini und der vierbeinige NEURA Quadruped). Übergreifend werden Integrationspfade in industrielle Automatisierung (z. B. Ethernet/IP, Modbus, teils PROFINET laut Produktseite; zusätzlich OPC UA/EtherCAT/ROS 2/VDA‑5050 bei MAV) sowie Developer‑Schnittstellen (NeuraPy/Python‑SDKs) sichtbar.
Stärken liegen in der stringenten „Sensor‑zu‑Skill“-Kette (Wahrnehmung → On‑Device‑Inferenz/Regelung → sichere Interaktion → Deployment/Flottenlernen). Limitierend wirkt aus Sicht technischer Evaluierung, dass einige für Industrie‑Rollouts entscheidende Kennwerte je nach Produktklasse noch nicht vollständig öffentlich spezifiziert sind (z. B. detaillierte Cycle‑Time‑Benchmarks, absolute Genauigkeiten über Nutzlast/Temperatur, Controller‑Redundanzen, Safety‑Optionen pro Konfiguration). Wo Angaben fehlen, sollte man in Projekten frühzeitig Datenblätter, Safety‑Konzepte und Integrationshandbücher anfordern und Proof‑of‑Concepts mit realen Takt‑ und Qualitätskriterien fahren.
Inhalt
Ausgangslage und Positionierung
Das Unternehmen wurde 2019 von David Reger in Metzingen (nahe Stuttgart) gegründet und beschreibt seine Produktstrategie als „One‑Device“-Ansatz: Roboter sollen – analog zu „Smartphones mit Armen und Beinen“ – zentrale Komponenten und Sensorik für „Physical AI“ in einem Gerät vereinen. Gleichzeitig betont Neura Robotics die In‑house‑Entwicklung zentraler Schlüsseltechnologien (KI, Steuerungssoftware, Sensorik, mechanische Komponenten).
Für ein Tech‑Blog ist vor allem interessant, dass Neura Robotics den klassischen Cobot‑Markt (Einsteiger‑Automatisierung, schnelle Inbetriebnahme, Standard‑I/O/Fieldbus) bewusst mit einer „kognitiven“ Ebene überlagert: Vision‑/Audio‑/Taktil‑Signale werden nicht nur als Add‑on verstanden, sondern als Grundlage für adaptivere Skills, sichere Mensch‑Roboter‑Kooperation und (über Neuraverse) Flotten‑ und Lebenszyklus‑Optimierung. Das Unternehmen kommuniziert dazu ein Ökosystem‑Narrativ („App‑Store“-ähnliche Skill‑Verteilung) sowie „NEURA Gyms“ als physische Trainingsumgebungen für reale Trainingsdaten.
Technologisch fällt außerdem auf, dass Neura Robotics Partnerschaften nicht nur als Vertriebslinie nutzt, sondern explizit als Daten‑ und Plattformstrategie: Neuraverse‑Partner werden u. a. als Unternehmen wie SAP, Schaeffler, NVIDIA und Vodafone genannt. Ergänzend zeigt die Zusammenarbeit mit Robert Bosch GmbH bzw. der Robert Bosch Robotics GmbH, dass der „Physical‑AI“-Pfad stark datengetrieben gedacht ist (Erfassung realer Bewegungs‑/Umfelddaten via Sensor‑Anzüge; gemeinsame Basis‑/Funktionssoftware und UIs).
Technologisches Fundament und Systemarchitektur
Hardware: Sensorik, Aktorik und Kinematik als „Wahrnehmungsplattform“
Über die Produktlinien hinweg wirkt die Hardware‑Architektur darauf optimiert, Sensorik eng mit der Bewegungsproduktion zu koppeln:
- Arme/Cobots: LARA ist als 6‑DoF‑Cobot (6 rotatorische Gelenke) ausgelegt, MAiRA als 7‑DoF‑Arm (kinematisch redundant), was in der Praxis Freiheitsgrade für Kollisionsvermeidung, bessere Bahnplanung um Objekte und ergonomischere Annäherungen ermöglicht.
- Kraft/Torque & Encoder‑Feedback: LARA wird mit Drehmomentsensorik in jedem Gelenk und 24‑Bit‑Encodern beworben; zusätzlich ist ein 6‑DoF‑Kraft‑Moment‑Sensor optional. MAiRA führt ebenfalls (optional) 6‑DoF‑F/T‑Sensing am Flansch sowie duale Encoder‑Hinweise auf der Produktseite.
- Mobile Plattformen: MAV nutzt 360°‑Laserscanner‑Sicherheit, SLAM‑Navigation und differenziellen Antrieb; Spezifikationen nennen u. a. Positioniergenauigkeiten im Millimeter‑bis‑Zentimeter‑Bereich (modellabhängig) und mehrere Lade‑/Betriebszeitprofile.
- Humanoide/Quadruped: 4NE1 wird als humanoides System mit 55 DoF, 360‑Grad‑Wahrnehmung und „touch‑sensitive sensor skin“ beschrieben; 4NE1 Mini bringt „kognitive Intelligenz“ in kompakterer Form (25 DoF Basis‑Einheit, optionale Safety‑Human‑Detection). Der Quadruped zielt auf unwegsames Terrain (Stufenhöhe, 360°‑Vision, autonome Pfadplanung).
Regelung und Steuerung: Echtzeit‑Motion plus Safety‑Master
In den Datenblättern der Arm‑Produkte taucht ein wiederkehrendes Muster auf: ein Real‑Time‑Motion‑Controller („NR‑Motion Master“) plus dedizierte Sicherheitsarchitektur („Safety master“, safe I/Os; bei MAiRA zusätzlich FSoE‑Kommunikation). Für LARA sind im Controller‑Kontext u. a. Modbus TCP und Ethernet/IP genannt; die Produktseite ergänzt weitere Industrienetzwerke (PROFINET, Modbus TCP/RTU, RS‑485). Da diese Angaben zwischen Produktseite und Datenblatt teils abweichen, ist für Integrationsprojekte der Abgleich mit dem konkreten Controller‑Release (Firmware/Optionen) entscheidend.
Für humanoide Systeme geben Stellenausschreibungen einen selten konkreten Einblick in die Embedded‑Ebene: Dort ist von hochdichter Sensorik/Aktorik mit 1‑kHz‑Regelraten, verteilten Motorcontrollern (FOC‑Regelung), Netzwerken wie CAN‑FD/SPI/RS‑485 sowie der Integration von micro‑ROS/DDS‑XRCE in Richtung ROS‑2‑Stack die Rede. Solche Informationen sind keine Produktspezifikation, aber ein plausibler Hinweis auf den angestrebten Systementwurf (deterministische Motorregelung + Sensorfusion + ROS‑2‑Kompatibilität).
Software‑Stack: No‑Code/Low‑Code, Developer‑APIs und ROS‑2 dort, wo Mobilität zählt
Neura Robotics adressiert zwei typische Adoptionshürden: (1) Programmieraufwand und (2) Integration in bestehende Automatisierung.
- Programmierung/Bedienung: LARA und MAiRA werden mit intuitiven, visuell geprägten UIs (Drag‑and‑Drop, No‑Code‑Setup) sowie Teaching‑Tools positioniert; „NEURA Teach“ zielt auf „Programming by Demonstration“ mit wenigen Tasten und schneller Umsetzung in wiederholbare Bewegungsabläufe (minimiert Teach‑Pendant‑Wechsel).
- APIs/SDKs: In den Datenblättern wird die NeuraPy‑API als Software‑Interface genannt (Python‑SDK; Zugriff auf Robot‑ und Sensor‑Daten). Das adressiert Integratoren, die Perception/Planung/Applikationslogik im eigenen Stack abbilden wollen.
- ROS‑2 & Flottenstandards: Bei MAV wird ROS 2 explizit als Navigationsoption mit VDA‑5050‑Kompatibilität genannt; im Datenblatt erscheinen zusätzlich Schnittstellen wie OPC UA, EtherCAT, CAN und VDA‑5050 neben „Python API“. Das ist für Intralogistik‑Integrationen relevant, weil ROS‑2‑/VDA‑5050‑Ökosysteme oft in gemischten Flotten genutzt werden.
AI/ML‑Komponenten: AURA, On‑Device‑Inferenz, Sim‑to‑Real und Neuraverse‑Lernschleifen
Auf der KI‑Seite sind vier Bausteine besonders konkret kommuniziert:
- AURA (SenseKit): AURA verarbeitet Bild‑, Sprach‑ und Berührungsdaten in Echtzeit auf einer integrierten Recheneinheit und übernimmt Wahrnehmung, Entscheidungsfindung und Steuerung lokal (nicht cloud‑abhängig). Das ist in industriellen Settings (Latenz, Ausfallsicherheit, Datenschutz) oft ein zentraler Architekturvorteil.
- Touchless Safe Human Detection (MAiRA): MAiRA beschreibt eine berührungslose Personenerkennung mit Schutzzonenlogik und Zertifizierungsanspruch (PL e / SIL 3, TÜV‑geprüft) sowie Erkennung innerhalb eines 3‑m‑Radius.
- Neuraverse + NEURA Gym: Neuraverse wird als kontinuierlich lernendes „Betriebssystem“ beschrieben, das Orchestrierung, digitale Zwillinge und App‑Entwicklung vereint; „NEURA Gyms“ sollen reale Trainingsdaten erzeugen und Modelle physikalisch validieren. Das zielt auf eine Sim‑to‑Real‑Pipeline, in der Skills nicht nur simulativ, sondern unter kontrollierter realer Interaktion reifen.
- Mehrschichtige KI‑Architektur (Kooperation): In einem Beitrag zur Zusammenarbeit mit NVIDIA wird eine mehrschichtige KI‑Architektur beschrieben (Echtzeit‑Sensorinferenz, lokale Inferenz/Verfeinerung auf dem Roboter, verteilte Inferenz über mehrere Agenten/Schwarm, Model‑Repository, cloud‑basierte Trainingsinfrastruktur plus lokale Serverebene; Simulationsbezug über NVIDIA Omniverse/Isaac‑Komponenten). Das ist ein klares Signal, dass Neura Robotics über das klassische „Roboter + Controller“‑Paradigma hinaus eine Daten‑ und Modell‑Operations‑Schicht (MLOps/RobOps) anstrebt.
Mermaid‑Referenzdiagramm: Systemarchitektur
Externe IntegrationenSoftware-LayerRobotersystem (Plattform)SteuerungSensorikHardwareAktorik & Getriebe/AntriebeEncoder / Drehmoment-SensorenEndeffektor / WerkzeugflanschMobile Basis (optional)3D/RGB/ToF-VisionMikrofon-Array / Lautsprecher6-DoF Kraft/Moment (optional)Safety: Laser-Scanner / Human-Detection / Sensor-SkinUmgebungs-Sensoren (Temp, Feuchte, etc.)Echtzeit-Motion-ControllerSafety-Master + Safe I/O (FSoE/Fieldbus)On-Device Compute: Perception & KI-InferenzTreiber & RuntimeNo-/Low-Code UI, Teach-by-DemonstrationDeveloper APIs: Python SDK / NeuraPyROS 2 Interface (wo verfügbar)PLC & Feldbus (z.B. PROFINET, EtherNet/IP, Modbus, EtherCAT)MES/SCADA/Line-ITNeuraverse/Cloud: Orchestrierung, Digital Twin, SkillsCode anzeigen
Produktportfolio und technische Daten
Im Folgenden sind alle auf den Produkt‑ und Reservierungsseiten sowie in öffentlich verfügbaren Datenblättern genannten Produkte aufgeführt. Wo technische Kennwerte (z. B. Wiederholgenauigkeit, Payload‑Einflusskurven, Controller‑Optionen) nicht spezifiziert sind, wird das ausdrücklich vermerkt.
LARA: 6‑DoF‑Cobot‑Familie für den Automatisierungseinstieg (und darüber hinaus)
Kurzprofil: LARA positioniert Neura Robotics als Anbieter einer skalierbaren Cobot‑Serie, die „Industriepräzision“ mit kollaborativer Nutzbarkeit kombiniert und dabei schnelle Einrichtung, No‑Code‑Bedienung und vorkonfigurierte Anwendungen (z. B. Palettieren, Schweißen) betont.
Gemeinsame Architektur‑/Integrationspunkte:
LARA ist in den Datenblättern als 6‑DoF‑Roboter mit any‑orientation‑Montage beschrieben; die Steuerung nennt NeuraPy‑API und klassische Industrie‑I/Os/Netzwerke (u. a. Modbus TCP, Ethernet/IP im Datenblatt; zusätzliche Netzwerke auf der Produktseite). Für modulare Hardware‑Erweiterungen werden EtherCAT und IO‑Link als standardisierte Schnittstellen erwähnt.
Modelle & Eckdaten (aus Datenblatt):
- LARA 3: 6 DoF; Payload 3 kg; Reach 590 mm; Gewicht 18 kg; Repeatability ±0,02 mm; Montage: any orientation; IP‑Angaben: IP66.
- LARA 5: 6 DoF; Payload 5 kg; Reach 800 mm; Gewicht 26 kg; Repeatability ±0,02 mm; Montage: any orientation; IP66.
- LARA 8: 6 DoF; Payload 8 kg; Reach 1300 mm; Gewicht 48 kg; Repeatability ±0,02 mm; Montage: any orientation; IP66.
- LARA 10: 6 DoF; Payload 10 kg; Reach 1000 mm; Gewicht 45 kg; Repeatability ±0,02 mm; Montage: any orientation; IP66.
- LARA 15: 6 DoF; Payload 15 kg; Reach 1600 mm; Gewicht 67 kg; Repeatability ±0,05 mm; Montage: any orientation; IP54.
- LARA 20: 6 DoF; Payload 20 kg; Reach 1800 mm; Gewicht 98 kg; Repeatability ±0,05 mm; Montage: any orientation; IP54.
- LARA 25: 6 DoF; Payload 25 kg; Reach 1800 mm; Gewicht 101 kg; Repeatability ±0,05 mm; Montage: any orientation; IP54.
- LARA 30: 6 DoF; Payload 30 kg; Reach 1300 mm; Gewicht 98 kg; Repeatability ±0,05 mm; Montage: any orientation; IP54.
- LARA 30L: 6 DoF; Payload 30 kg; Reach 1800 mm; Gewicht 126 kg; Repeatability ±0,05 mm; Montage: any orientation; IP54.
Typische Anwendungen:
Von „First‑Automation“ (Pick‑and‑Place, einfache Maschinenbedienung, Handling) bis zu prozessnäheren Anwendungen mit Add‑ons: Schweißen/Palettieren über vorkonfigurierte Applikationsbausteine; Schleifen/Polieren in Kombination mit Kraft‑Moment‑Sensorik (NEURA Touch).
MAiRA: 7‑DoF‑Cobot mit kognitiver Sensorik und Touchless‑Safety‑Konzept
Kurzprofil: MAiRA wird als „weltweit erster kommerziell verfügbarer kognitiver Roboter“ beschrieben und kombiniert (je nach Konfiguration) Vision, Audioverarbeitung, Kraftsensorik und KI‑gestützte Safe‑Human‑Detection.
Kinematik und Performance‑Kennwerte:
MAiRA ist als 7‑DoF‑Arm (7 rotary joints) mit any‑orientation‑Montage und IP65 klassifiziert. Die Datenblätter führen eine „Accuracy“ von ≥0,01 mm (Referenz ISO 9283; anwendungsabhängig) und ein Sicherheitsniveau PLd Cat.3 / SIL3 an.
Modelle & Eckdaten (aus Datenblatt):
- MAiRA S: 7 DoF; Payload 15–18 kg; Reach 1100 mm; Gewicht 51 kg; Accuracy ≥0,01 mm; Montage: any orientation; IP65.
- MAiRA M: 7 DoF; Payload 12–14 kg; Reach 1400 mm; Gewicht 53 kg; Accuracy ≥0,01 mm; Montage: any orientation; IP65.
- MAiRA L: 7 DoF; Payload 9–11 kg; Reach 1600 mm; Gewicht 56 kg; Accuracy ≥0,01 mm; Montage: any orientation; IP65.
Safety‑ und Interaktions‑Merkmale:
MAiRA beschreibt eine berührungslose Schutzzone mit Personenerkennung (bis 3 m Radius, Unterscheidung Mensch vs. andere bewegte Objekte) und ein Zonenmodell (volle Geschwindigkeit / reduzierte Geschwindigkeit / Stopp). Zudem wird ein TÜV‑geprüftes Sicherheitsdesign bis PL e / SIL 3 genannt.
Integration:
Im Datenblatt werden u. a. GPIO/Modbus‑Interfaces (inkl. Modbus RTU via M8) sowie der Zugriff auf Robot‑ und Sensor‑Daten über die Python‑basierte NeuraPy‑API (SDK) genannt; außerdem wird „Open Architecture“ mit optionalem Zugang zu Low‑Level‑Controllern/Sensor‑Daten erwähnt.
Markt‑Signal:
Die MAiRA‑Plattform dient als Basis für eine kognitive Roboterlinie von OMRON; dort werden optionaler 3D‑Vision‑Sensor, intuitive UI und Neura‑Sicherheitsarchitektur als zentrale Eigenschaften hervorgehoben. Das ist ein Indiz, dass MAiRA‑Konzepte OEM‑fähig gedacht sind.
MAV: Mobile Transportplattform („Multi‑Sensing Autonomous Vehicle“) für Intralogistik
Kurzprofil: MAV adressiert autonome Materialflüsse (Intralogistik) und skaliert laut Produktseite von Einzelgerät bis Flotte. Wesentlich sind integrierte Sensorik (u. a. 360°‑Laserscanner), dynamische Sicherheitszonen und wählbare Navigations‑Stacks (Navitec oder ROS 2/VDA‑5050).
Modelle & Eckdaten (öffentliches Datenblatt):
- MAV 500: Payload 500 kg; Dimensions 1255×678×294 mm; Weight 300 kg; Velocity 1,5 m/s; Positioning accuracy ±5 mm; Uptime 7 h; Differential drive; IP44/IP54 (auf Anfrage).
- MAV 1500: Payload 1500 kg; Dimensions 1530×910×293 mm; Weight 400 kg; Velocity 1,5 m/s; Positioning accuracy ±5 mm; Uptime 10 h; Battery increase bis 200 %; IP44/IP54 (auf Anfrage).
- MAV 3500: Payload 3500 kg; Dimensions 2375×1100×350 mm; Weight 500 kg; Velocity 1,3 m/s; Positioning accuracy ±10 mm; Uptime 7 h; Load detection: RFID‑basiert; Battery increase bis 200 %.
Hinweis zur Modellbezeichnung:
Auf der Produktseite werden neben MAV 500 und MAV1500 auch „MAV+“ genannt (mit abweichenden Payload‑/Uptime‑/Accuracy‑Angaben). Ohne zusätzliche Dokumente lässt sich öffentlich nicht eindeutig auflösen, ob „MAV+“ ein gesondertes Modell, ein Paket oder eine Umbenennung ist; für belastbare Planung sollte das konkrete Datenblatt zur gewünschten Variante herangezogen werden.
Safety, Zonenlogik und Betriebsrobustheit:
Die Produktseite beschreibt 360°‑Sicherheitserkennung über Laserscanner, PLd/Kat. 3 (ISO 13849‑1) sowie dynamische Anpassung von Sicherheitszonen und Geschwindigkeitsprofilen (voll / reduziert / sicherer Stopp). Im Datenblatt werden Safety‑Zonen (Safe stop + zwei Warning‑Zonen) und Field‑Sets (2–32) erwähnt.
Integration und Flottenfähigkeit:
Im Datenblatt werden als Kommunikations-/Integrationsschnittstellen u. a. Python API/ROS2/OPCUA/EtherCAT/VDA‑5050/CAN genannt; zusätzlich existieren Ethernet‑ und CAN‑Ports.
MiPA: Persönlicher Assistenzroboter als „offene Plattform“ für Service‑Anwendungen
Kurzprofil: MiPA wird als intelligenter Assistenzroboter positioniert, der in menschlichen Umgebungen arbeitet und Entwickler/Integratoren über Echtzeitdaten und APIs adressiert. Kern ist ein modularer Plattformansatz (Hardware‑Zubehör + konfigurierbare Software) für Branchen von Home über Retail bis Healthcare und „Workplace Assistance“.
Öffentliche technische Eckdaten:
Im Datenblatt werden 16 DoF (Basis ohne Endeffektoren) sowie eine Motion Endurance von 2–8 h genannt; außerdem werden Bausteine wie Language Model, Computer Vision und Reinforcement Learning als AI‑Komponenten aufgeführt. Payload, Reach, Robot‑Gewicht und Wiederholgenauigkeit sind im öffentlich sichtbaren MiPA‑Datenblatt nicht spezifiziert.
Sensorik & Navigation (Produktseite):
MiPA nennt SLAM‑basiertes Mapping, LiDAR und KI‑gestützte Planung für Bewegung in dynamischen Räumen sowie kontaktlose Personendetektion bis 3 m. Auf Sensorseite werden u. a. Temperatur/Luftfeuchtigkeit/GPS, (RGB‑)Kameras, Infrarot‑ und Ultraschallsensoren sowie Webcams genannt; Kommunikation über Wi‑Fi und Bluetooth.
Integration:
Aussagen zur konkreten industriellen Feldbus‑Integration sind auf der MiPA‑Produktseite nicht im Detail spezifiziert; die öffentliche Aussage „offene Plattform“ mit APIs und Echtzeitdaten deutet auf einen developer‑zentrierten Integrationspfad (App‑/Skill‑Entwicklung, Anbindung an Smart‑Home/Service‑Systeme).
4NE1: Humanoider „Teammate“ für realweltliche Aufgaben
Kurzprofil: 4NE1 wird als humanoider Roboter für Industrie‑Workflows ebenso wie für Alltagsunterstützung positioniert. Die Produktseite betont 360‑Wahrnehmung, Sensor‑Haut, multimodale KI und Reinforcement Learning; außerdem werden Modellvarianten (z. B. Rad‑Versionen, 7. Achse) und austauschbare Unterarme erwähnt.
Öffentliche technische Eckdaten (Datenblatt):
- Freiheitsgrade: 55 DoF (Gesamtsystem); eigene Hände: 12 DoF (separat ausgewiesen).
- Größe/Gewicht: 180 cm; 80 kg.
- Nutzlast: 10–100 kg (anwendungs‑ und konfigurationsabhängig).
- Geschwindigkeit: 5 km/h.
- Wahrnehmung & Safety: 360°‑Perception, touch‑sensitive sensor skin; Safety‑Human‑Detection‑Sensoren sind laut Datenblatt optional.
Integration:
Detaillierte Feldbus‑/API‑Spezifikationen für 4NE1 sind im öffentlich sichtbaren 4NE1‑Datenblatt nicht umfassend ausgeführt; genannt werden u. a. AI‑Voice‑Control und Remote‑Control‑Aspekte.
4NE1 Mini: Kompakter Humanoid für Bildung, Labore und Prototyping
Kurzprofil: 4NE1 Mini zielt auf Schulungsräume, Labore und Prototyping; die Reservierungsseite unterscheidet „Standard“ und „Pro“ (Pro inkl. 12‑DoF‑Hände; zusätzliche SDKs/Teleoperation/Digital‑Twin‑Zugriff).
Öffentliche technische Eckdaten (Datenblatt):
- DoF (Basis): 25 (ohne Hände/Endeffektoren; Hände können je bis zu 12 DoF haben).
- Höhe/Gewicht: 132 cm; 36 kg.
- Nutzlast: 3 kg.
- Speed (max): 4,6 km/h.
- Motion Endurance: 2,5 h.
- Schnittstellen: Wi‑Fi 6, Gigabit Ethernet, ROS2, C++ & Python SDK, NeuraSync; Safety‑Human‑Detection optional.
NEURA Quadruped: Vierbeiniger Explorer‑Roboter für raues Terrain
Kurzprofil: Der Quadruped wird für Inspektion, Überwachung und Lasttransport in herausfordernden Umgebungen positioniert; Reservierungsseite und Datenblatt betonen autonome Navigation, Multi‑Sensor‑Fusion und Neuraverse‑/NeuraSync‑Integration.
Öffentliche technische Eckdaten (Datenblatt):
- Payload: 22 kg; Weight: 60 kg; Height: 620 mm.
- Speed: 12 km/h; Battery life: 6 h; Step height: 15 cm; Environment vision: 360°.
- Interfaces: Wi‑Fi 6, Gigabit Ethernet, ROS2, C++, Python SDK, NeuraSync.
Wiederholgenauigkeit im Sinne eines Roboterarms (ISO‑9283) ist hier nicht spezifiziert (und für Laufroboter meist anders zu bewerten als bei Industrierobotern).
Add‑Ons und Ökosystem‑Produkte
NEURA SenseKit (Sensor‑/KI‑Kit für Cobots):
SenseKit ergänzt Standard‑Cobots um 3D‑Vision, Sprachsteuerung, Gesteneingabe und „Intelligenz“ (AURA). Es soll auf „jedem Cobot mit ISO‑Flansch“ funktionieren und greift auf Neuraverse zu; AURA läuft laut Produktseite lokal auf integrierter Recheneinheit (keine Cloud‑Abhängigkeit). Typische Beispiele sind Bin‑Picking, Kommissionierung und Qualitätsinspektion.
NEURA OmniSensor (Personenerkennung/Safety‑Perception):
OmniSensor wird als multimodales Personenerkennungssystem beschrieben, das Menschen von Objekten klassifizieren und adaptive Sicherheitszonen ermöglichen soll. Öffentlich spezifiziert sind u. a. eine Reaktionszeit von 50 ms, Erfassungsbereich ≤4 m und ein Sichtfeld je nach Modulanzahl (120°×80° bis 360°×180°). Die konkrete, standardisierte Safety‑Zertifizierung wird auf der OmniSensor‑Produktseite nicht als numerischer PL/SIL‑Wert ausgewiesen (im Gegensatz zu LARA/MAiRA‑Safety‑Angaben).
NEURA Touch (6‑Achsen‑Kraft‑Moment‑Sensor):
NEURA Touch adressiert kraftgeregelte Prozesse (Oberflächenbearbeitung, Konturverfolgung, Montage) über 6‑Achsen‑Messung (Fx/Fy/Fz/Mx/My/Mz), Temperaturkompensation, IP65‑Klassifizierung und EtherCAT‑Kommunikation. Positioniert wird „Plug‑and‑Play“ sowie Stabilität in schwankenden Umgebungen; belastbare quantitative Kraft‑/Moment‑Grenzwerte sind öffentlich auf der Produktseite nicht als Zahlenwerte angegeben.
NEURA Teach (Programmierung durch Vormachen):
NEURA Teach zielt auf schnelle Programmierung (Gesten/Handführung) mit „drei Tasten“ und reduziertem Setup‑Aufwand; es soll grundsätzlich mit „jedem Roboter“ funktionieren, mit erweiterten Funktionen über die Neura‑Softwareintegration. Hardware‑Kennwerte (Gewicht, Schutzart, Schnittstellen) sind auf der öffentlich sichtbaren Seite nicht spezifiziert.
Neuraverse (Plattform, Gym, Electronics):
Neuraverse wird als kontinuierlich lernendes Betriebssystem beschrieben, das Orchestrierung, digitale Zwillinge und App‑Entwicklung vereint und Skills global deploybar macht. Ergänzend werden NEURA Gyms als physische Trainingsanlagen für reale Trainingsdaten positioniert; außerdem wird „NEURA Electronics“ als Kompetenz zur Entwicklung/Fertigung von Schaltschränken, Leistungselektronik und Sensorintegration beschrieben.
Produktvergleich und Einsatzempfehlungen
Die folgende Tabelle fasst zentrale, öffentlich verfügbare Spezifikationen zusammen. Datenquelle sind die aktuellen, öffentlich zugänglichen Produktseiten und Datenblätter; Abweichungen zwischen Produktseite und Datenblatt sind (wo relevant) im Text diskutiert.
| Produkt | Kategorie | DoF | Nutzlast | Reichweite / Abmessung | Eigengewicht | Präzision / Genauigkeit | Montage | Integration (Auszug) | Empfohlene Use‑Cases |
|---|---|---|---|---|---|---|---|---|---|
| LARA 3 | Cobot‑Arm | 6 | 3 kg | Reach 590 mm | 18 kg | Repeatability ±0,02 mm | Any orientation | NeuraPy, Modbus/Ethernet‑IP (Controller); EtherCAT/IO‑Link (modular) | Kleinteile‑Handling, Montage, Labor‑Automation |
| LARA 5 | Cobot‑Arm | 6 | 5 kg | Reach 800 mm | 26 kg | ±0,02 mm | Any orientation | wie LARA 3 | Pick‑and‑place, Maschinenbedienung light |
| LARA 8 | Cobot‑Arm | 6 | 8 kg | Reach 1300 mm | 48 kg | ±0,02 mm | Any orientation | wie LARA 3 | Handling mit größerer Reichweite, flexible Zellen |
| LARA 10 | Cobot‑Arm | 6 | 10 kg | Reach 1000 mm | 45 kg | ±0,02 mm | Any orientation | wie LARA 3 | Standard‑Cobot‑Tasks, einfache Schweiß-/Palettier‑Skills (je nach Setup) |
| LARA 15 | Cobot‑Arm | 6 | 15 kg | Reach 1600 mm | 67 kg | ±0,05 mm | Any orientation | wie LARA 3 | Schwerere Bauteile, größere Arbeitsräume |
| LARA 20 | Cobot‑Arm | 6 | 20 kg | Reach 1800 mm | 98 kg | ±0,05 mm | Any orientation | wie LARA 3 | Palettieren/Materialhandling, große Reichweite |
| LARA 25 | Cobot‑Arm | 6 | 25 kg | Reach 1800 mm | 101 kg | ±0,05 mm | Any orientation | wie LARA 3 | schweres Handling, robuste Anwendungen |
| LARA 30 | Cobot‑Arm | 6 | 30 kg | Reach 1300 mm | 98 kg | ±0,05 mm | Any orientation | wie LARA 3 | hohe Payload bei mittlerer Reichweite |
| LARA 30L | Cobot‑Arm | 6 | 30 kg | Reach 1800 mm | 126 kg | ±0,05 mm | Any orientation | wie LARA 3 | maximale Reichweite + hohe Payload |
| MAiRA S | kognitiver Cobot‑Arm | 7 | 15–18 kg | Reach 1100 mm | 51 kg | Accuracy ≥0,01 mm | Any orientation | NeuraPy‑SDK; Modbus/IO; Safety master + FSoE | variable Prozesse, HRC‑nahe Aufgaben, bin picking (mit Vision) |
| MAiRA M | kognitiver Cobot‑Arm | 7 | 12–14 kg | Reach 1400 mm | 53 kg | ≥0,01 mm | Any orientation | wie MAiRA S | kognitive Automation mit größerer Reichweite |
| MAiRA L | kognitiver Cobot‑Arm | 7 | 9–11 kg | Reach 1600 mm | 56 kg | ≥0,01 mm | Any orientation | wie MAiRA S | lange Reach‑Tasks, z. B. Regale/Stationen bedienen |
| MAV 500 | mobiles Transportfahrzeug | – | 500 kg | 1255×678×294 mm | 300 kg | ±5 mm Positioning | Bodenfahrzeug | CAN/Ethernet/Python API; (ROS2/VDA‑5050 laut Features) | Materialtransport, Labor/Engstellen, mobile Materialflüsse |
| MAV 1500 | mobiles Transportfahrzeug | – | 1500 kg | 1530×910×293 mm | 400 kg | ±5 mm | Bodenfahrzeug | wie MAV 500 | schwere Intralogistik, Flottenbetrieb |
| MAV 3500 | mobiles Transportfahrzeug | – | 3500 kg | 2375×1100×350 mm | 500 kg | ±10 mm | Bodenfahrzeug | wie MAV 500 | Schwerlast‑Transport, große Linienlogistik |
| MiPA | Assistenzroboter (Service) | 16* | nicht spezifiziert | nicht spezifiziert | nicht spezifiziert | nicht spezifiziert | mobile Plattform | Echtzeitdaten & APIs; Wi‑Fi/Bluetooth; SLAM/LiDAR | Service‑/Healthcare/Retail/Home; vielseitige „Skills“ |
| 4NE1 (Gen 3.5) | Humanoid | 55 | 10–100 kg | Höhe 180 cm | 80 kg | nicht spezifiziert | Humanoid | AI‑Voice/Remote; weitere Schnittstellen nicht spezifiziert | flexible Aufgaben in unstrukturierten Umgebungen, Logistik/Service |
| 4NE1 Mini | kompakter Humanoid | 25 | 3 kg | Höhe 132 cm | 36 kg | nicht spezifiziert | Humanoid | Wi‑Fi6, GbE, ROS2, C++/Python SDK | Bildung, Forschung, Prototyping, Teleop (Pro) |
| NEURA Quadruped | Laufroboter | nicht spezifiziert | 22 kg | Höhe 620 mm | 60 kg | nicht spezifiziert | Laufplattform | Wi‑Fi6, GbE, ROS2, C++/Python SDK | Inspektion, Überwachung, Gelände‑Transport |
*DoF bei MiPA bezieht sich auf die Basis ohne Endeffektoren.
Bewertung: Stärken, Grenzen und Markt‑Fit
Stärken (technisch):
Erstens ist die Konsistenz zwischen Hardware‑Sensorik, Safety‑Konzepten und Software‑/Ökosystem‑Story beachtlich: MAiRA und LARA kombinieren klassische Cobot‑Metriken (Repeatability/Accuracy, IP‑Klassen, Tool‑Flansche nach ISO‑Norm) mit Developer‑APIs und mehrkanaliger Interaktion (Vision/Audio/Force). Zweitens ist MAV als mobile Plattform ungewöhnlich breit in Integrationsstandards aufgestellt (ROS2/VDA‑5050‑Option, OPC UA/EtherCAT/CAN/Python API) und damit für heterogene Werks‑IT/OT‑Landschaften attraktiv. Drittens stützt der Neuraverse‑Ansatz (Digital‑Twin‑Orchestrierung, Skill‑Deployment, Training in Gyms) eine skalierbare Roadmap für „Robots at scale“, bei der nicht jede Zelle isoliert optimiert werden muss.
Grenzen und offene Punkte (für technische Due‑Diligence):
Für Produktionsentscheidungen fehlen öffentlich an einigen Stellen die „harten“ Integrator‑Details: vollständige Controller‑Daten (z. B. Protokolloptionen pro Lizenz/Hardware, Safety‑I/O‑Topologien, zertifizierte Konfigurationsvarianten), standardisierte Performance‑Benchmarks (Cycle‑Time nach ISO‑9283‑Profilen, Bahnabweichung unter Last, Wiederholgenauigkeit über Temperatur), und – bei Humanoiden/Service‑Robotern – belastbare Angaben zu Wartungsintervallen, Ersatzteilkonzepten und Safety‑Optionen in konkreten Applikationen. Teilweise zeigen sich zudem Inkonsistenzen zwischen Produktseiten und Datenblättern (z. B. MAV‑Modellbezeichnungen bzw. Uptime‑Angaben; LARA‑SIL‑Level je nach Quelle). Technisch ist das nicht ungewöhnlich in schnell iterierenden Plattformen, aber es erhöht den Bedarf an „Version‑Pinning“ (genau definierte Hardware‑/Software‑Revisionen) im Projekt.
Markt‑Fit (praktisch):
Kurzfristig wirkt das Portfolio besonders stark in zwei Segmenten: (1) Cobot‑Modernisierung in KMU und industriellen Linien, in denen schnelle Inbetriebnahme, modulare Erweiterungen und sichere HRC gefragt sind (LARA/MAiRA + Add‑Ons). (2) Intralogistik‑Skalierung über MAV mit einer klaren Brücke zu Flotten‑/Standard‑Ökosystemen (VDA‑5050/ROS2) und vergleichsweise konkreten Transport‑Spezifikationen. Mittel‑ bis langfristig ist der „Physical‑AI“-Wettlauf (Humanoide/Quadruped) stark vom Daten‑ und Trainingskonzept abhängig; hier sind Neuraverse/NEURA Gym sowie die Datenkooperationen (z. B. Bosch, TUM RoboGym) strategisch plausibel, weil sie reale Trainingsdaten als Engpass adressieren.
