- Start
- |
- Gemeinschaft
- |
- Modelle
- |
- Infos
- |
- Markt
- |
- Hilfe+Kontakt
- |
- |
Hallo,
gestern kam die Frage nach der Bedienbarkeit des Liebherr.
Nun, die bekannte App BrickController2 steuert jetzt auch die PoweredUp und Boost Hubs.
https://www.eurobricks.co...d-ios-game-controller/
Dann sollte es zum CONTROL+ nicht mehr weit sein.
Ich finde es schade, dass diese Themen hier derart wenig Beachtung finden oder nur diskutiert wird, was die neuen Produkte alles nicht können, anstatt auch die neuen Möglichkeiten zu sehen.
Mir persönlich gefällt das alles sehr gut.
Bin ich damit hier denn der Einzige?
Grüße
Werner
Garbage Collector , Thomas52xxx , , Dirk1313 , Masklin , XoverBrick , freakwave , Magic11r , JuL gefällt das (9 Mitglieder)
Werner schrieb;
Das sind alles irgendwelche Platinchen, aber was hat das alles mit LEGO zu tun?
...
Hallo Werner,
beantworte ich gerne wie folgt:
1. "Das sind alles irgendwelche Platinchen, aber was hat das alles mit LEGO zu tun?"
Zunächst mal nix, aber wie du schreibst suchst du dir gerne mal viele Komponenten aus dehnen eine Lösung bestehen könnte.
Ich denke das das eine oder andere für die eine oder andere LEGO Steuerung zumindest eine Inspiration sein kann.
2".Warum sollte man das Technic Hub ersetzen wollen? Oder meinst Du Control+ (das ist die Steuerung)?"
Sagen wir ich tue mich mit den Namen schwer, ich dachte Control+ ist der Name der "Produkt Familie" bestehend aus Software, Hub Motoren, da keines dieser neuen Elemente zu bestehenden älteren Lösungen kompatibel ist.
Warum ich den ersetzen will: Im Einzelfall kann, die unmittelbare Verwendung anderer Konzepte (Einbau RC Empfänger) , unmittelbare Verwendung Gamecontroller, ohne umweg über BLE lediglich aus dem Grund "diese" Elemente weiter zu verwenden, einfacher sein, wenn das Ziel lediglich ist eine "normale - greifbare" Steuerung verwenden zu wollen.
Du hast geschrieben:
Im Zweifel muss man das Produkt ignorieren, stimmt soweit : Im Zweifel teile beschaffen und mit eigener Automatisierung versehen, im Grunde Gefällt mir beim Liebherr die Produktidee nur nicht das Bedienkonzept.
Hobby ist wenn: "Man mit dem größtmöglichen Aufwand, den geringstmöglichen Nutzen erziehlt", hörte ich mal 
4. "Und außerdem fehlt da mit den "Leitungstreibern" die Tachofunktion der Motoren, die wird über UART realisiert."
Die Wiederherstellung dieser Funktion, wenn benötigt, sollte bei genügender Kenntnis über Hardwareseitig und Funktionsweise des Originals kein Problem sein.
5. Oder das ADAFRUIT für 35- was macht das, was mein PI Zero für 10,-- nicht macht, ohne jedes Hardware-Gebastel?
Und mit der Möglichkkeit der Anzeige etc.
Es mag den Rahmen hier sprengen:
Die Diskussion ob für eine Automatisierungslösung ein "bare metal" µC oder ein "höheres System" Notwendig oder geeignet ist ist nicht trivial und leider oft auch recht religiös geführt.
Vereinfacht ist das Problem:
Auf dem Chip kostet jede Ressource Geld, bei begrenztem Platz , man muss Kompromisse finden.
Der wesentlichste Nachteil, welche Chiptypen wie Rasbery Pi oder ähnlich haben ist der "Mangel an automatisierungsspezifischer Hardware "on chip".
Beispiel für einen anderen Controller :https://www.st.com/en/microcontrollers-microprocessors/stm32h745-755.html
Die Frage lautet: Wann braucht und vermisst man welche Ressource genau: Als Bastelcontroller für Hardware halte PI und CO nur für bedingt geeignet.
Gleichwohl ist der Aufwand in Zeit und Kosten für eine ansprechende Oberfläche nicht zu unterschätzen:
https://www.mikroe.com/mikromedia-7-capacitive
auch wenn teilweise kostenlos, nicht trivial in der Anwendung:https://www.touchgfx.com
Es gibt auch heterogene Mutlicoresysteme welche beide Systeme vereinen:
Am Ende: Im Bereich des bezahlbaren Hobbies muss man ein Endscheidung treffen beide Systeme haben jeweils vieles was der andere nicht bietet.
Die Herkunft, und Erfahrung = Wohlfühlfaktor nicht vernachlässigen.
PS:
Und wenn du ehrlich bist: Eine ansprechende Oberfläche auf dem Rasbery PI zu erstellen, ist im zweifel auch nicht trivial.
Mit erstellen meine ich nicht das "zusammenklicken" fertiger Widgets, eher ein eigenes QT5 Project, oder HTML basiert mit eigen erstellten CSS Graphik Designs
6.Leider habe ich nicht verstanden, wozu das alles gut sein soll, oder, anders gefragt: welches "Problem" möchtest Du denn lösen?
Es geht einfach nur um ein lockeres Brainstorming welche Ansätze, Produkte, Ideen, Konzepte, es geben könnte am Zustand etwas zu ändern.
Mit Zustand meine ich : Offenbar sind "Leute" mit dem Weg von LEGO in Bezug auf die Automatisierung in Hardware und Software unzufrieden.
Nun kann man auf LEGO warten oder sich austauschen welche alternativen es gäbe.
Also wieder die von dir gewünschte Diskussion
Das Problem ist: Ich suche momentan nach einer Lösung für ein Problem was ich selber konkret gar nicht habe.
Sollte ich bei meiner Programmierbarkeit auf eines stoßen, frag ich dich mal.
Auch wenn wir bezüglich der verwendeten Plattformen auseinanderlegen.
Ich werde dann mal das Problem so weit zu abstrahieren zu versuchen das wir uns nicht über Bibliotheken, sondern spezifische BLE Fragestellungen unterhalten.
In deinem Fall werde ich bei Zeiten Fragen zum LEGO Protocoll fragen
Nochmals danke für deine Eingaben und Anmerkungen und Gruß
Marc
Hallo Marc,
Ruppie hat geschrieben:
Hallo Marc,
Ruppie hat geschrieben:
Tag Werner ,
"Der wesentlichste Nachteil, welche Chiptypen wie Rasbery Pi oder ähnlich haben ist der "Mangel an automatisierungsspezifischer Hardware "on chip".
Was meint das? Welche Art Hardware wäre das?"
Versuch das in aller Kürze darzustellen:
Das Problem sind die unterschiedlichen Architekturen
Dein Chip im PI und ähnlich ist usgelegt in möglichst großer Rechenleistung / auch Mehrkerne zur Unterstützung "hoherer" Betriebsysteme, LINUX, WINIOT,,,,
"klassiche Microcontroller" sind ausgelegt auf möglichst große Rechenleistung in der Berechnung von "Steuerungstechnische " Algorithmen, manchmal noch im Bereich DSP (Digitale Signal Verarbeitung), schnelles Regeln etc..
Da ist der overhead eines "großes BS" oft störend und Echtzeitfähigkeit oft nicht gegeben/ verfügbar.
Alles andere wird in die Peripherie "ON Chip" verleg: Zunächst mal die Signalverarbeitung / Datenhandling aller Schnittstellen
: CAN, USB,I2C,SPI, Aber auch sämtliche Timer und Zeitgeber, Analog/ Digitalwandler ... werden nicht von der eigentlichen CPU behandelt.
Der größte unterschied ist das diese Resourcen, in wesentliche größerer Anzahl Verfügbar sind als in Chip Architekturen
wie PI. Ausserdem ist die Verwendung konfiguration/ ähnlich Gerätemanager/ dieser Perperie sehr feinfühlig möglich.
Das ist keine Wertung: Hat eher was mit der "Automatisierungspyramide zu tun".
Wenn man diese Variantenvielfallt nicht benötigt, ohnehin egal
Noch wichtiger:
Nix womit sich ein "normaler LEGO Mensch" belasten muss
Hallo,
ah, vielen Dank, interessant.
Verstehe.
Ich dachte wir sprechen über den "Mittler" zwischen Bedienteil und Hub.
Und da geht es "nur" darum, 10 Byte in 10 andere umzusetzen.
Und das alles via BT übertragen, was vermutlich dramatisch länger dauert.
Das heißt aber eine sinnvolle Auswahl der HW kann nur erfolgen, wenn ich die genauen Anforderungen kenne.
(Gut, das ist jetzt wenig überraschend...)
Die Diskussion ist zwar interessant, hängt aber ein wenig in der Luft weil mir nach wie vor nicht klar ist was Du überhaupt erreichen möchtest, also welche Komponenten Dein System bilden und welcher Komponente welche Aufgabe zukommt. (Skizze!)
Was ich suche sind drei $IRGENDWAS für drei Funktionen, hier mal am Beispiel Eisenbahn:
- Bedienteil
- HW-Konfiguration (Zug rot = MAcAdresse xyz), Zug Blau Sensor an Hub0, Port4)
- Steuerung (Taste X Bedienteil -> Zug Blau schneller, Sensor 5 rot -> Zug Halt)
Ab da geht es via BT -> LEGO Wireless Protokoll -> LEGO HUB
Bedienteil muss es mehrere Sorten geben (Gamepad, LEGO-Pult, LEGO FB, SmartDevice)
Konfiguration und Steuerung können eins sein.
Vielleicht hast Du da ein paar Tips, wie man das lösen könnte.
Grüße
Werner
Hallihallo Lok24,
ich finde die umstellung von IR auf BT sehr gut, aber mich kotzt es an, dass ich ein mobile + app zur Steuerung brauche. Ich will eine/n klassische fernbedienung/controller. Aufbauen, batterien rein, spielen! A propos batterien: wann gibt es endlich mal akkus, die ich aufladen kann, ohne diese olle batteriebox ausbauen zu müssen? bei den preisen heutzutage wäre das ein Mindestmaß an leistung!
Zur app: kein mensch kann mir versichern, wie lange die unterstützung dafür läuft. wenn's ganz blöd läuft, stampft lego sein control+ nach einem jahr wieder ein und man hat ein 400€-model, dass mangels software nicht mehr bespielbar ist. Supper!
Bluetooth ja, control+ nein danke!
LG Gerd
Carrera124 gefällt das
Hallo Gerd,
Ja, das sind die Haupt-Kritikpunkte.
Ich kann hier nur nach meinem Wissenstand berichten.
Fragen nach dem "Wann" kann ich leider auch nicht beantworten.
heldderbeine hat geschrieben:
Danke für die rueckmeldung. ich verstehe deinen Ansatz und vieles, was du schreibst, ergibt durchaus sinn. Da aber niemand von uns hellseher ist, ist alles, was die zukünftige nutzbarkeit der app betrifft, reine spekulation. und ich bin nicht bereit für eventualitäten, so viel geld auszugeben. Das muss natürlich aber jeder für sich selbst entscheiden. Was die nutzung mit software anderer anbieter betrifft, macht die ganze sache in meinen augen nur (un)nötig kompliziert. ich erwarte von lego einfach, dass ich für mein geld ein bespielbares set bekomme, ohne dass ich dafür ein handy mit der dazugehörigen app eines fremdanbieters brauche. lego sollte sich wieder ins bewusstsein rufen, dass ihre produkte in erster linie eines sein sollen: kinderspielzeug! (das betrifft nicht nur technic, sondern fast alle anderen themenbereiche, in denen es fast ausschließlich nur noch überteuerte lizenzsets gibt.)
Carrera124 , gefällt das
Abend Werner:
Ich bin noch in der "Spielphase" / Weg- Findungsphase bevor ich mir konkretere Gedanken mache, probiere noch verschiedenes aus.
Wie beschrieben: Wenn ich meine Gedanken geordnet habe, gibts auch mehr.
Aber:
Wenn ich die Erwartungen und Wünsche der "Anderen" zusammenfasse, und das Ziel auch eben auch sein sollte wenn man nicht der einzige ist dem es nützt wäre mein vorschlag wie folgt.
1. Es ist ein Gerät welches möglichst unabhängig von Entwicklungsvorgängen im "allgemeines Konsum ermarkt" ist
2. Es soll möglichst vielfältig einsetzbar sein, Es soll nicht zwingend auf Touch Bedienung limitirt sein, es soll auch mechanische Bedienelemente haben
.....
Am Ende scheint, mi,r wird das Gerät ähnlichkeit mit aus dem Modellbau bekannten Multichannel Computeranlagen haben.
Das wichtigste ist: Das Gerät ist eine eigenständige Fernbedienung, welche in keiner Form noch Adapter , Gateways, benötigt.
Vielleicht hast du schon alles/ vieles was was du suchst:
Fall1 : Wenn du deine Lösung um ein HDMI Display ergänzt und ein wenig Zeit investierst, dann
Hättest du die Funktionalität des Brickcontroller app unmittelbar "in deinem Gerät"
Wenn du nun noch ein kleiners Display wählst als 7 Zoll verwendest, und die Bedienelemente eines Gamepad
drum herum gruppierst hast du schon die kompakte Fernsteuerung, welche alle suchen.
Neigungssensoren, XY Joysticks , Knöppe LED und Schalter gibt es ja genug.
Da Problem wird sein jemand Creative zu finden welches ein formschönes Handliches Gehäuse dafür zeichnet und druckt.
Ist aber unwesentlich: Für den Begin, bis man eine Idee hat wie man Elemente Anordnet
Also ähnlich so: https://www.amazon.com/Fl...ticopter/dp/B01G1SKJZ0
Wie einfach oder "fancy" die Bediengührung auf dem Display ist ist eine Frage von Geld/ Geschmack und am Ende ausprobieren.
Fall 2:
Mit der Lösung die ich vorgeschlagen habe magst du nicht jedes Gamepad mit deinem PI verbinden, aber wäre das PS4 Pad nicht ausreichend.
Also:
Deine Entwicklungsbasis welche unmittelbar mit dem LEGO HUB kommuniziert ist immer den PI alles andere baust du einfach drum herum.
Oder habe ich was falsch verstanden was du suchst ?
Weil: Ein Pult hattest du ja auch schon
Das Konfigurationsproblem habe ich nicht Genau verstanden was da deine Anforderungen sind
Im Zweifel liegt dein Problem, bei deinen nunmehr gestiegenen Anforderungen vielleicht auch im Software Architekturbereich.
Ich kenne Pyton im speziellen und Programmiermöglichkeiten auf dem PI im besonderen zu wenig;
Die Fragen lauten:
Welche Funktionalitäten muss meine Software , jeweils für jeden Typ Steuerung erfüllen.
Mit Typ Steuerung wäre hier:
- PI mit Gamepad
- PI mit PULT
- PI nur mit Touchdisplay
- PI mit Touchdisplay und weiteren Bedienelementen
ich würde davon absehen eine Software Schreiben zu wollen welche im "ersten Schuss" alles abdeckt.
Vorschlag wäre, da du zunächst annimmst das für jeden Steuerungstyp verschiedenen Programme erforderlich wären.
Die Frage wäre welche Programmierumgebung / Sprache geignet wäre, es geht ja dann nicht mehr darum "mal eben" einen Befehl über Script oder Shell befehl zu triggern.
Mir fehlt jedoch die Erfahrung auf dem PI sonst hätte ich behauptet,C oder C++ wäre erforderlich um eine "Normale" ordentliche strukturierte, in sich geschlossene Anwendung zu erstellen.
Bestimmt liege ich hier falsch:
Ich wollte nur sensibilisieren:
Es gibt einen Unterschied zwischen "frikeln","schnüffeln", "probieren" und Der Entwicklung eine vollwärtigen Programmes mit Praxisnutzen.
Ich hoffe ich habe nicht zuviel Blödsinn erzählt
PS:
Wer "Angst" vor der Entwicklung grafischer Oberflächen hat:
https://www.amazon.de/UNI...aspberry/dp/B008RU8VKG
der
https://4dsystems.com.au/...ry-pi-primary-displays
Allerdings muss man dan im Zweifel mit den Einschränkungen der Editoren leben.
Bis dann
Gruß
Marc
Hallo Marc,
Ruppie hat geschrieben:
