ev3dev: C für EV3

NXC, C/C++, Lejos, pbLua, RobotC...

Moderator: Moderatoren

Technicmaster0
Schreibt super viel
Schreibt super viel
Beiträge: 376
Registriert: 22. Dez 2010 12:36
Wohnort: In Berlin rechts abbiegen
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Technicmaster0 » 4. Mai 2015 20:11

Die Kameras und ein paar andere Sachen könntest du ja über USB/ Bluetooth ansteuern (z.B. mit nem USB Hub). Die Batteriestärke wird ja intern vom EV3 gemessen. Gyro Accel und Kompass gabs ja glaube ich auch von Mindsensor in einem.

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 5. Mai 2015 07:33

war ja nur um alles mal etwas auf die Spitze zu treiben, auf Peters Post hin.
Aber 50 klingt auf den ersten Blick so viel, doch so extrem ist das gar nicht.
Auch für die (externen) 12V Batterie-Akkuwächter, das Keyboard, die Pixy-/EV3Cams, und natürlich die Taster kann viel über i2C-Multiplexer laufen - aber eben nicht alles, es ist ja kein echtes I2C beim EV3 mit 100-400kbps und >120 Device-Adressen.
Und die meisten EV3-Sensoren sind UART (allerdings wieder mal nicht Industrie-Standard), die lassen sich auch nicht kaskadieren.
Daher: Daisy-Chaining!
Aber dann hat man keinen USB-Port mehr frei, denn da stecken ja die Daisy-chaining-Kabel drinnen!
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 5. Mai 2015 12:32

Funktioniert daisy chaining nicht mit einem USB-Hub?

Anyway.

Ich bleibe dabei. Man kann nicht einerseits derartig professionell arbeiten, dass man 50 Sensoren einschließlich irgendwelcher Thirdparty Sensoren anschließen will, aber andererseits nichts dafür dazulernen wollen. Wie gesagt: Wenn das alles mit NXT geht, nutz NXT. Ist auch billiger. Mit dem relativ leistungsstarken ARM Prozessoren im EV3 verlässt man imho sowieso die klassischen zentralen Steuerungsnetzwerke, wo jeder Sensor und Aktor ein eigenes Kabel/Kanal zur Steuerungseinheit hat und nähert sich dem dezentralen Ansatz, indem keine Messwerte mehr übertragen werden (ich finde ein EV3-Brick ist für stupides Forwarden eh einen Zacken zu teuer und zu mächtig), sondern semantische Nachrichten, meist über ein Kabel / einen Kanal.

Zu dem Beispiel mit den 50 Sensoren und den 12 Ultraschallsensoren gäbe es halt 3 EV3 bricks, die mit der gleichen Software bespielt werden, aber nicht stupide Messwerte umherschicken und 11 andere EV3 Slaves mit den Nachrichten behelligen, um zum Master-EV3 vorzudringen, sondern direkt Entscheidungen treffen und nur eine Nachricht schicken, ob ein Hindernis vorliegt oder nicht. Mittels TCP/IP könnte man sogar den Verlust von analogen Nachrichten vermeiden. Die Information schicken sie dann einmalig an den "Bewegungs-EV3" und gut ist. Wenn man richtig Langeweile hat, kann man die 13 EV3s für die 50 Sensoren im Hintergrund noch massiv parallel an einem neuralen Netz werkeln lassen. ;) (KA, wie gut das parallelisierbar ist, bei dem schlechten Netzwerk sollte es vor allem sehr grob granular sein).

Auch heutige Sensor-Aktor-Netzwerke in Gebäuden haben keine zentrale Steuereinheit mehr, sondern die Aktoren und Sensoren sprechen über einen Bus (lies: Nur ein Kabel, wo die Module mittels Stechleitungen drarnhängen) teils direkt, teils über eine dezentrale Steuereinheit miteinander.

TL; DR: 13 EV3s in einer Daisy Chain sind imho Wahnsinn und verschwendetes Geld und Potenzial. Dann sollte man doch über NXT oder Nicht-Lego Alternativen nachdenken.

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 5. Mai 2015 13:44

neinnein, keine 13, nur 4, außerdem war das nur ein Extrembeispiel.
je 16 Touch können an 1 i2c mux
je 8 Standard-ADC können an 1 I2C mux
einige Standard-I2C Sensoren+Muxer (PCFs, auch Arduinos als slaves) können notfalls gemeinsam an 1 EV3-I2C port,
je max 3 Lego/Mindsensors-I2C können an 1 eigenen EV3-I2C-Port (per Portsplitter)
je max 3 Lego UART-Sensoren können an 1 eigenen EV3-I2C-Port (per Mindsensors Multiplexer).

Könnte man max. 50 Sensoren mit 4 NXTs per NXC ansteuern, wäre das zwar schon ein erster Schritt ,
aber uninteressant, wenn man
a) mehr RAM braucht (NXT hat 40kB frei, der Due 90kB, aber 20MB würden benötigt)
b) mehr cpu-Power braucht (der Due ist etwa 50x so schnell wie NXT/NXC (Grafik-Display außen vor), aber der Ev3 könnte 100x so schnell sein)
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 5. Mai 2015 16:21

ps,
im Cubestormer 3 sind übrigens zwar nicht so viele Sensoren, aber dafür 31 Motoren und 8 EV3s verbaut. Die laufen aber mit dem original TI DaVinci Linux (soweit ich weiß), Vernetzung per USB-Daisy chaining (1+3) und zusätzlich per BT-Mailboxsystem (+4) - nur mal als Vergleich.
Wie man sieht, brauchen auch andere Tüftler viele IOs.
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Peter28
Schreibt viel
Schreibt viel
Beiträge: 185
Registriert: 2. Nov 2013 21:44
Wohnort: Schmallenberg

Re: ev3dev: C für EV3

Beitragvon Peter28 » 5. Mai 2015 16:29

HaWe,
Du hast mich überzeugt mit den 50 usw.usw. :D :D :D
Ich bin :ok: :lol:
Die letzten 2 Zeilen nicht so ernst nehmen
Tschüß Peter

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 7. Mai 2015 14:13

Was spricht eigentlich gegen RobotC? Das scheint mir eine sehr umfangreiche Lösung zu sein. Daisy Chaining geht zwar auch da nicht, aber immerhin wird daran wohl gearbeitet.

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 7. Mai 2015 14:44

extrem langsam
kostenpflichtig (jährliche Lizenzgebühren)
nur 15k freier RAM Speicher (etwa nur 1/2 bis 1/3 von dem, was der NXT mit NXC hat!!)
keine double (64bit floats)
ohne Daisy-chaining witzlos
bislang nur 1 BT master + 1 BT slave (mailbox-System)
guck mal den Benchmark-Vergleich:
http://www.mindstormsforum.de/viewtopic.php?p=64772#p64772
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 7. Mai 2015 15:30

Interessanter Benchmark. Muss den bei Gelegenheit mal unter ev3dev ausprobieren. ;)
Zu deinen Punkten:
extrem langsam

Hm, finde nicht, dass man das aus deinem Benchmark rauslesen kann. Die Arraysorierung und Anzeige von Text scheint das einzige wirkliche Problem zu sein, was ich persönlich nun nicht andauernd mache.
kostenpflichtig (jährliche Lizenzgebühren)

Wenn ich das richtig sehe, bekommt man für 80$ eine ewige Lizenz
nur 15k freier RAM Speicher (etwa nur 1/2 bis 1/3 von dem, was der NXT mit NXC hat!!)

Das sollte mit dem EV3 doch kein Problem sein?
keine double (64bit floats)

Wozu zum brenneden Getreide benutzt du auf so einem vergleichsweise schwachbrüstigen ARM doubles? Bei einer spontanen Nachprüfung (habe meinen EV3 brick gerade nicht zur Hand) scheint weder NXT noch EV3 überhaupt eine FPU zu haben.
ohne Daisy-chaining witzlos

Ich denke die Diskussion können wir uns sparen. :D
bislang nur 1 BT master + 1 BT slave (mailbox-System)

Okay, dazu kann ich nicht viel sagen.

Schade, das sah mir wirklich nach einer Alternative aus.

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 7. Mai 2015 15:40

lass das mal meine Sorge sein, wozu ich doubles benutze - ;)
alle EV3-Plattformen (gpp C auf DaVinci, leJOS, C#) haben doubles, leJOS sogar auf dem NXT, und auch der Due hat double (gottseidank).
Aber nur 1 Beispiel: analytische Algebra (z.B. Matrix-Algebra, z.B. Determinanten ausrechnen).
Außerdem rechnen eigentlich auch alle Backproagation-Netze mit double, damit sie nach 8 Stellen Genauigkeit nicht in lokalen Minima hängen bleiben. (Ich verzichte z.Zt zwangsweise beim Due darauf, weil sonst 92k Speicher nicht ausreichen, mit manchmal schlechten Konvergenz-Ergebnissen.)

Und 15k Speicher für den EV3 ist doch lächerlich, wenn 42MB verfügbar sind! (wie bei allen anderen Plattformen)

und RobotC braucht auf dem EV3 100x so lang zum Rechnen wie BCC/gpp/C (wobei hier noch immer die VM parallel läuft - ev3dev wäre dadurch noch schneller!)!!!

Also wirklich, eine RobotC Diskussion brauchen wir hier wirklich nicht zu führen.
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 7. Mai 2015 15:47

HaWe hat geschrieben:lass das mal meine Sorge sein, wozu ich doubles benutze -
alle EV3-Plattformen (gpp C auf DaVinci, leJOS, C#) haben doubles, leJOS sogar auf dem NXT.
Aber nur 1 Beispiel: analytische Algebra (z.B. Matrix-Algebra, z.B. Determinanten ausrechnen).

Jo, mach was du denkst, aber ich bleibe bei meiner Behauptung, dass auch analytische Algebra zumeinst mit floats auskommt. Insbesondere, wenn es um autonome Roboter geht, die die vorhandene Rechenkraft sinnvoll für Entscheidungen nutzen wollen, kann man leichte Ungenauigkeiten auch schonmal hinnehmen, wenn man dafür schneller reagieren kann. ;)

Und 15k Speicher ist doch lächerlich, wenn 42MB verfügbar sind! (wie bei allen anderen Plattformen)

Was, auch 15K Speicher auf dem EV3? Okay, DAS ist wirklich krass.

Sorry, wenn 5 oder 10 Jahre Forenkultur von mir wiederholt werden, bestimmt alles keine neuen Diskussionen. Nur ich bin neu. Aber immerhin gibt es so etwas Leben hier. ;)

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 7. Mai 2015 15:49

nein, Determinanten werden oft mit floats falsch berechnet - wo sie eigentlich exakt Null sein müssten (da linear abhängig), haben sie per 32bit float u. U. plötzlich positive Werte, als wären sie eindeutig lösbar - das ist komplett unsinnig, wenn man daraus dann ihre Inverse berechnen will!
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 7. Mai 2015 16:24

und nochmal wegen der Geschwindigkeit, Robot C gegen native Executables (ausgebremst durch FW!):
(Die RobotC-Werte wurden von Xander Soldaat, inzwischen RobotC-Mitarbeiter, selber ermittelt, allerdings für ein älteres Release )

Code: Alles auswählen

                                          BCC/gpp C   RobotC

 0 integer add/subtr                          3         336     
 1 integer multiply/division                 13         589     
 2 float operations                          61       ( 226)   
 3 MersenneTw.PRNG(bit-alg.) (N/A:max+)       4        1204     
 4 matrix algebra (prod/determ.)             10         325 


da liegen doch Welten dazwischen, und wie gesagt, ev3dev/C wäre ja NOCH schneller als BCC/gpp/C, das sieht man z.B. schon daran, dass bereits die Java- und die Mono-VM teilw. schneller sind als native Executables unter der Lego-FW!
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 7. Mai 2015 18:09

Ich verstehe nicht, wieso native Executables unter der Lego-FW langsamer laufen sollten als mit Java oder Mono - gerade, wenn man mit -O3 kompiliert.

Aber zu deiner erweiterten Tabelle: Der Unterschied ist ja wirklich frapierend! Faktor 100 ist schon eine Klasse für sich. O_O

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5399
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: ev3dev: C für EV3

Beitragvon HaWe » 7. Mai 2015 18:15

Ich verstehe nicht, wieso native Executables unter der Lego-FW langsamer laufen sollten als mit Java oder Mono

tun sie auch nicht -
das ist eine Eigenheit der Lego-FW:

Linux läuft, klar, aber auch die Lego-VM läuft immer als task, weil man ohne sie nicht auf die Module für Buttons, Bildschirm, USB etc zugreifen könnte (Linux-Fachleute können das sicher besser erklären).
Wie Xander Soldaat es mal erklärte:
wenn man die Lego VM abschaltet, würde man den Ast absägen, auf dem man sitzt.

Daher kann man zwar schnelle Ecexutables erzeugen (gpp C mit code sourcery Lite toolchains, wie das wohl heißt), aber parallel zu den executables läuft nach wie vor die Lego-VM als Parallel-Task - und das kostet natürlich cpu-Power.

Dämlich, aber wahr. :-pc:


Java hat eine eigene FW und einen JIT-compiler (Mono ebenso), die machen nach und nach ihre "eigenen" "executables".

:mrgreen:
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E


Zurück zu „textbasierte Programmiersoftware“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 15 Gäste

Lego Mindstorms EV3, NXT und RCX Forum : Haftungsauschluss