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)
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:
Lok24 hat geschrieben: