mit „irgendwie mit Scratch“ meinst Du vermutlich Enchanting. Dafür gibt es ein deb, welches ich in meinem KDE Neon 5.16.4 (auf der Basis von Ubuntu 18.04) gerade ohne Probleme installieren konnte. http://enchanting.robotclub.ab.ca/tiki-index.php
Scratch 1.4 und OpenJDK waren bei mir allerdings bereits vorher installiert.
Ich habe zwei Jahre Robotik mit Enchanting gemacht. Ich finde den Ansatz gut, aber Enchanting (das ja nicht mehr weiterentwickelt wird) hat leider viele Bugs.
Man merkt das schon daran, dass der Roboter unter Enchanting viel träger reagiert als unter Roberta.
Ein weiterer Nachteil ist das Flashen. Zu oft darf man das nicht machen, sonst geht das Flash-Rom kaputt.
Ein deutlicher Vorteil von Enchanting ist die USB-Verbindung, die viel weniger stressig ist als bei Roberta.
Ich bekomme gerade Roberta unter Linux gar nicht mehr zum Laufen. Früher (Version 0.9 oder so) war bei Roberta eine eigene Java-Umgebung dabei, mit der es funktionierte. JEtzt steht da nur der lapidare Hinweis, man solle ein 32 bit Java nehmen. Bei mir wird der nxt-usb-Treiber nicht geladen. Wenn jemand eine Idee hat (ich habe es auch auf einem Lokalen Ubuntu ohne Proxy probiert, daran liegt es nicht), wäre ich dankbar.
Hallo Stefan,
die online-Version alleine reicht nicht, man muss zusätzlich ein Programm installieren, das die usb-Verbindung herstellt, und das funktioniert unter Ubuntu 18.04 nicht. Das ist das Problem.
Hallo!
Ich habe viel probiert: Tuxminds, auch deren Boot-CD, lejos…
nichts hat funktioniert, Problem war am Ende immer die USB-Verbindung.
Ich hatte mit dem Tuxminds-Entwickler gemailt, auch bei lejos war ich in Kontakt, der letzte Tipp war dann: Einen anderen PC verwenden, weil zu neue PCs wohl USB-Probleme machen.
Ich verwende also (immer noch) die XP-VM mit dem originalen Mindstorms drauf. Ich finde die Programmierumgebung sehr unschön und unübersichtlich, trotzdem kann man damit programmmieren und die NXTs sind halt da, warum sollte ich die wegschmeißen?
unter der 6.2 und Ubuntu 16.04 lief OpenRoberta einwandfrei. Vorher hatten wir mit dem usb-Anschluss unter lejos auch nur Schwierigkeiten.
In der letzten Ferienwoche werden wir auch testen wie das mit der V7 und Ubu 18.04 läuft.
Didaktisch ist OpenRoberta genial. Die SuS können auch zu Hause daran arbeiten und man erhält einen ersten Einblick in den Quellcode. Und man kann mit einer Oberfläche gemischte Hardware einsetzen.
Evtl ist ein Bluetooth-Dongle als Alternative zum USB-Kabel eine Option?
Ich habe jetzt rausgefunden, warum es mit einem (aktuellen) Ubuntu 18.04 nicht geht.
Erstens ist die Doku veraltet, aber zweitens funktioniert der nxt nicht mit Kerneln neuer als 4.15 . Der 4.15 war bei der ersten 18.04 Release dabei, wurde aber später geupdatet.
Details hier:
(der letzte Post enthält eine Lösung).
Wenn es erst mal läuft ist m.E. von den grafischen Sachen Roberta am besten. Enchanting ist von der Progrmamoberfläche genauso gut, aber der Roboter wird nicht so gut angesteuert.
Für Fortgeschrittene ist das textuelle Programmieren der Roboter natürlich schön, da gibt es (auch für Linux) diverse nxc-Implementationen.
Also werde ich nun wohl extra für die Roboter noch ein eigenes Linux-Image mit einem alten Kernel basteln, seufz …
Immerhin fällt mir dann eigentlich nichts mehr ein, wofür wir Windows brauchen, ich hoffe, meine Kollegen sehen das auch so!
Ich habe jetzt OpenRoberta unter LinuxMint Tina 19.2 zum Laufen gebracht. Notwendig war die hier https://github.com/OpenRoberta/robertalab-usbprogram-nxt/issues/4 beschriebene Lösung: Letztlich eine neue Version des Programms.
Das Install-script ist jedoch sehr kreativ programmiert, man muss es aus dem Verzeichnis starten, in das die Programminstallation erfolgen soll, etwa von /opt.
Zusätzlich musste ich die Gruppe lego in die /etc/security/group.conf eintragen.
Vielen Dank allen hier Beteiligten, eure Hilfe hat die Roboter vor dem Elektroschrott bewahrt.
was mich interessieren würde: Läuft das Programm bei Dir auch mit Netzwerknutzern?
Ich habe das Skript so geändert, dass in den udev-rules die „users“ gruppe die Rechte bekommt, da sind alle user drin. Aber zusätzlich müssen die Nutzer ja noch in die „dialout“ gruppe. Das Skript macht das ja nur für den Nutzer, der es aufruft. Hast Du das irgendwie hinbekommen, dass da auch die Netzwerknutzer drin sind?
Bei uns läuft Lego jetzt mit einem lokalen Nutzer und einer lokalen Roberta-Installation (letzteres, weil wir Robertalab hinter dem Proxy nicht erreichen), aber immerhin: Es läuft. Das Problem beschäftigt mich insgesamt nun schon seit 3 Jahren, seinerzeit hatten wir Robotik dann entnervt mit Windows gemacht. Issue 4 ist ja von mir, aber die Entwickler haben überhaupt nur reagiert, weil ich eine (recht verzweifelte) Mail ans Fraunhofer-Institut geschrieben habe, dass niemand sich auf Github rührt, und die haben dann wohl die Entwickler angestupst.
Ich habe es mit meinem Account, also als ldap-user der Gruppe teachers ausprobiert. Das hat funktioniert. Ist das deine Frage?
Ich nehme an, du meinst das Installscript. Meiner Meinung nach müssten zwei Wege funktionieren:
1.) Du baust die udev-Regeln des Installscripts so um, dass es eine Gruppe nutzt, in der alle Schülern und Lehrer sind.
2.) Du lässt die udev-Regeln wie sie sind und fügst die notwendigen Gruppen in /etc/security/group.conf auf dem Client ein.
Ich bin den zweiten Weg gegangen. Dort steht - ich glaube für die Arduino-IDE - auch die Dialout-Gruppe
Wenn ich das Installscipt anschaue, bestätigt das meine Meinung, dass die Fraunhofer-Institute auch gerne nur mit Wasser kochen. Am liebsten auch nur mit lauwarmen. Das was ich dort damals als stud. Mitarbeiter gesehen und auch selbst fabriziert habe, könnte jedenfalls wie dieses Installscript aussehen.
Bist Du unter V6.2 oder V7 unterwegs? Ich bin mir nicht sicher, ob das mit /etc/security/group.conf bei dem V7 Client auch so ist, aber das wäre dann ja sehr einfach, Danke.
cat /etc/security/group.conf
#[...]
#Dies sollte jeden User in der Zeit von 0-24h (also immer) in die Gruppen lego, dialout,.... eintragen
*;*;*;Al0000-2400;lego,dialout,cdrom,floppy,audio,dip,video,plugdev,scanner,vboxusers,lpadmin
#Administrator kommt noch in diese Gruppen...
*;*;administrator;Al0000-2400;adm,admin,lpadmin
#pgmadmin in diese....
*;*;pgmadmin;Al0000-2400;adm,admin,lpadmin
#alle Admins die im Infrastrukturprojekt sind, dürfen auch alles...
#ich weiß nur nicht, wie der Syntax für eine LDAP-Gruppe war:@Gruppe oder %Gruppe. Aber einer der Einträge geht.
*;*;@p_infrastruktur;Al0000-2400;adm,admin,lpadmin,activflash,sudo
*;*;%p_infrastruktur;Al0000-2400;adm,admin,lpadmin,activflash,sudo
[/code]-Tag --> -Tag natürlich weg lassen und davor und danach eine Leerzeile
Ich hatte zwischenzeitlich dringendere Probleme, OpenRoberta funktioniert mit einem Lokalen User im Linuxmuster7 - Netz.
Jetzt habe ich mich intensiv (anderer Faden) mit den Gruppenzugehörigkeiten auseinandergesetzt und es geschafft, dass Domänennutzer in der Gruppe „lego“ und „dialout“ landen.
Aber: Der Domänennutzer kann sich immer noch nicht mit dem Legoroboter verbinden. Auch dann nicht, wenn ich die Proxyvariable ändere.
Der Button bei OpenRoberta bleibt inaktiv, man kann nicht verbinden drücken!
Wenn jemand noch einen Tipp hat, ich bin völlig ratlos … Was ist beim Domänennutzer sonst noch anders als beim lokalen Nutzer?
wie hast du es geschafft, dass Domänenbenutzer der V7 in die Gruppe XY kommen?
Die Verbindungsproblematik kenne ich auch: Wenn man die Firewallregel „allow entire Netz“ einschaltet geht alles. Die Software, die die Verbindung zwischen Roboter und Browser herstellt wird offensichtlich vom proxy abgefangen. Ich habe versucht eine Regel einzurichten, die nur *.fraunenhofer.de ohne proxy zulässt bin aber gescheitert. Hat hier jemand einen Vorschlag?
Nur hat es nichts genützt. Ich brauche auch keine Firewall-Ausnahme, wir verwenden einen lokalen Roberta-Server. Der sch… Button des USB-Programms bleibt schon grau (also genau so wie vor dem Bugfix). Man bekommt erst gar keinen Token.
Ich habe jetzt auch noch dieses Problem lösen können.
Die Ursache lag diesmal bei mir selbst: Da ich es ja zunächst nicht hinbekommen hatte, die Domänennutzer in lokale Gruppen (vorgesehen von Roberta sind, wie hinlänglich bekannt, die Gruppen „lego“ und „dialout“) einzufügen, habe ich in meiner Not die udev-Rules für den nxt so abgeändert, dass die Gruppe „users“ den nxt benutzen darf, nicht die Gruppe „lego“. Denn jeder Domänenbenutzer ist auch in einer Gruppe „users“, jedenfalls wird das angezeigt, wenn man auf der Konsole „groups“ eingibt.
Offenbar gibt es auf einem Linuxmusterclient mit Domänenanmeldung aber zwei Gruppen „users“, eine aus der Domäne (es muss im LDAP Schema eine Gruppe users geben), eine lokale. Das Verwenden des nxt-Steins per udev-Rule geht aber nur mit einer lokalen Gruppe, nicht mit einer Domänengruppe.
Ich habe also die udev-Rule wieder auf „lego“ zurückgeändert (mitlerweile waren die Domänenuser Dank der Hilfe von Dominik @foer ja in diesen lokalen Gruppen), jetzt gehts.
Wir verwenden allerdings einen lokalen Roberta-Server, das Roberta-USB-Programm kann nicht mit einem Proxyserver umgehen.
Ich habe insgesamt über 2 Jahre daran gebastelt, dass OpenRoberta unter Linux im Schulnetz läuft, ich glaube, da muss ich gelegentlich einen Glühwein drauf trinken!
