Eine nette Zusammenfassung der ich zustimmen kann:
http://ask.slashdot.org/comments.pl?sid ... d=38417836
Kritik auf /.
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
Kritik auf /.
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer
E Hoffer
Re: Kritik auf /.
Comment about the 10ms.
The communication between the actuatoren/sensoren is based on a sample rate of >10ms (USB).
For BlueTooth this is typical 15 to 30 ms, however in the literature you will find 40 to 50 ms as rule of the thumb. Bluetooth is a protocol for streaming use and not for semi real time use.
This has not some much to do with the quality but more with the nature of this interface.
There are faster (semi) real time interface available on the market but the price is much higher: see for example the National Instruments website.
Beside RoboPRo (work flow oriented concept with data flow as inter process synchronization ) fischer technik also support MS-RDS with message flow oriented concept.
The communication between the actuatoren/sensoren is based on a sample rate of >10ms (USB).
For BlueTooth this is typical 15 to 30 ms, however in the literature you will find 40 to 50 ms as rule of the thumb. Bluetooth is a protocol for streaming use and not for semi real time use.
This has not some much to do with the quality but more with the nature of this interface.
There are faster (semi) real time interface available on the market but the price is much higher: see for example the National Instruments website.
Beside RoboPRo (work flow oriented concept with data flow as inter process synchronization ) fischer technik also support MS-RDS with message flow oriented concept.
Re: Kritik auf /.
Hello Defiant,
I agree , concerning the electrical wiring and connectors.
Ich bin damit einverstanden, über die elektrischen Leitungen und Anschlüsse
grub
Marspau
I agree , concerning the electrical wiring and connectors.
Ich bin damit einverstanden, über die elektrischen Leitungen und Anschlüsse
grub
Marspau
Re: Kritik auf /.
And in every thread about ft+RDS you read that it is not even actively supported...so please stop these Ads.vleeuwen hat geschrieben: Beside RoboPRo (work flow oriented concept with data flow as inter process synchronization ) fischer technik also support MS-RDS with message flow oriented concept.
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer
E Hoffer
Re: Kritik auf /.
@Defiant,
Probably you are not well informed or did not contact fischertechnik about the MS-RDS support. Hereby a small update:
The FtService from Microsoft on CodePlex is already a long time out of date (it was full of errors and never good).
However there is a replacement that has support from fischertechnik. Contact fischertechnik about it.
Probably you missed the presentations during the FT-convention or the FT-meeting in Munster.
First of all, fischertechnik is partner in the MS Robotics Developer Studio project.
There is support for the FtxxServices by fischertechnik.
-) FtTxService for the TX-C
-) FtTlService for the TL-C
-) Ft16Serive for the Robo Interface family (Robo Int, Robo Connection box, RoboInt extension module_stand alone).
-) FtTrailSensor activity which implement a complete state machine for the fischertechnik trail sensor.
-) FtDifferential drive service
For the moment we are busy to rewrite the FtTxService.
In case of question about MS-RDS and the integration of the fischertechnik interface, please contact fischertechnik.
There is also a FT-bot simulation example.
See also the LinkIn group "Integration of Fischertechnik interfaces in MS-Robotics"
The FtTxService and the Ft-Bot simulation are in use during the Ontario Skill competition 2011 and 2012.
Probably you are not well informed or did not contact fischertechnik about the MS-RDS support. Hereby a small update:
The FtService from Microsoft on CodePlex is already a long time out of date (it was full of errors and never good).
However there is a replacement that has support from fischertechnik. Contact fischertechnik about it.
Probably you missed the presentations during the FT-convention or the FT-meeting in Munster.
First of all, fischertechnik is partner in the MS Robotics Developer Studio project.
There is support for the FtxxServices by fischertechnik.
-) FtTxService for the TX-C
-) FtTlService for the TL-C
-) Ft16Serive for the Robo Interface family (Robo Int, Robo Connection box, RoboInt extension module_stand alone).
-) FtTrailSensor activity which implement a complete state machine for the fischertechnik trail sensor.
-) FtDifferential drive service
For the moment we are busy to rewrite the FtTxService.
In case of question about MS-RDS and the integration of the fischertechnik interface, please contact fischertechnik.
There is also a FT-bot simulation example.
See also the LinkIn group "Integration of Fischertechnik interfaces in MS-Robotics"
The FtTxService and the Ft-Bot simulation are in use during the Ontario Skill competition 2011 and 2012.
Zuletzt geändert von vleeuwen am 19 Dez 2011, 21:51, insgesamt 1-mal geändert.
Re: Kritik auf /.
I'm not really interrested in RDS and no I wasn't on any convention this year.
But you might wand to write your info here (that it is not outdated): http://www.roboternetz.de/community/thr ... post525535
-
Since I'm on Pandaboard I can't use RDS anyway. But I'm actually not using ROS either, I have my own.
But you might wand to write your info here (that it is not outdated): http://www.roboternetz.de/community/thr ... post525535
-
Since I'm on Pandaboard I can't use RDS anyway. But I'm actually not using ROS either, I have my own.
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer
E Hoffer
Re: Kritik auf /.
@Defiant,
That information is not correct. Did they contact fischertechnik about this issue first?
I think that the info on the fischertechnik website, the Microsoft RDS forums, the LinkIn group and the supporting website for the FtxxServices is enough.
There is also exhange of information between the users of the FtxxServices.
The most important conclusion that there is support from fischertechnik for MS-RDS.
There are users not only in Germany but also in Canada, US, Mexico, Russia, Netherlands, France.
The message flow oriented concept of MS-RDS, the CCR (concurency), the DSS (decentralization), VPL (Visual Programming Language) and the 3D simulation environment, knows a lot of advantages.
The FtxxServices brings several general purpose interefaces for actuators and sensors under the scoop of MS-RDS.
In fact it does not represents a single robot with dedicate sensors and actuators but the FtxxServices represent more flexible general purpose interfaces.
The FtxxServices are still prototypes. This because of the relatif small number of users and they are free of charge.
The development of a professional product including full documentation and didactical material will cost a lot of time and resources.
In case your PANDA-board is able to communicate with a Windows PC and has a well defined driver on dotNET framework level (managed code) then is the integration into the MS-RDS platform eassy to do.
That information is not correct. Did they contact fischertechnik about this issue first?
I think that the info on the fischertechnik website, the Microsoft RDS forums, the LinkIn group and the supporting website for the FtxxServices is enough.
There is also exhange of information between the users of the FtxxServices.
The most important conclusion that there is support from fischertechnik for MS-RDS.
There are users not only in Germany but also in Canada, US, Mexico, Russia, Netherlands, France.
The message flow oriented concept of MS-RDS, the CCR (concurency), the DSS (decentralization), VPL (Visual Programming Language) and the 3D simulation environment, knows a lot of advantages.
The FtxxServices brings several general purpose interefaces for actuators and sensors under the scoop of MS-RDS.
In fact it does not represents a single robot with dedicate sensors and actuators but the FtxxServices represent more flexible general purpose interfaces.
The FtxxServices are still prototypes. This because of the relatif small number of users and they are free of charge.
The development of a professional product including full documentation and didactical material will cost a lot of time and resources.
In case your PANDA-board is able to communicate with a Windows PC and has a well defined driver on dotNET framework level (managed code) then is the integration into the MS-RDS platform eassy to do.
Re: Kritik auf /.
Bin einverstande!
Kurz und knapp: FT Mechanik ist sehr gut Elektrik mittelmäßig und die Sensoren schlecht.
Kurz und knapp: FT Mechanik ist sehr gut Elektrik mittelmäßig und die Sensoren schlecht.
http://py4ft.weebly.com Programmiere Fischertechnik mit Python
Re: Kritik auf /.
Hallo,
was die Elektrik (hauptsächlich Verdrahtung) betrifft, bin ich gespalten.
Auf der einen Seite scheint die "Verdrahtung" - wenn man es so nennen kann - bei Lego einfacher. Klick und weg.
Aber: Man braucht (teure) Spezialkabel, man kann sie nicht in beliebigen Längen herstellen (eine Crimpzange zum selber Herstellen kostet ein Vermögen).
Bei großen Industriemodellen sieht man sehr schnell, welches System flexibler ist.
Außerdem "sieht" man nicht mehr, wie die Technik funktioniert. Auch, wenn es lästig ist: Bei fischertechnik ist ein Stromkreis zu "sehen", man braucht eben 2 Adern, damit ein Motor läuft. Bei dem Encoder bzw. bei den Sensoren ist es ähnlich - Versorung +/-, Rückmeldung - das ist eine in der Industrie ebenfalls weit verbreitete Methode, Sensoren anzuschließen.
Bei Lego ist das nur ein Kabel - da wird alles auf eine "Black box" reduziert.
Natürlich ist es Ansichtssache und vom persönlichen Geschmack abhängig, welches System man bevorzugt. Ich persönlich finde aber, dass es didaktisch wertvoller ist, wenn man einen Stromkreis nachvollziehen kann - diese "plug & play" Steckverbindungen tragen m.E. zu einer gewissen "Verdummung" bei.
Die Probleme mit den Steckern kann ich nicht nachvollziehen. Das Stecksystem ist identisch mit den bei Modelleisenbahnen verwendeten Steckern (2,6 mm) und wurde (wird?) dort millionenfach eingesetzt. Ich habe sicherlich Kabel im hunderter-Bereich, und wenn man sie exakt nach Anleitung (mit der umgelegten Litze) herstellt und sauber verschraubt, hat man wenig Probleme damit.
Das in dem Beitrag angesprochene Problem mit dem Herausziehen am Kabel zeigt mir, dass man sich heutzutage keine Gedanken mehr macht, wie man etwas optimieren kann. Man nehme den mitgelieferten Schraubendreher - wenn man den in die Querbohrung einführt und als Hebel benutzt, kriegt man jeden Stecker wieder raus, ohne am Kabel zu ziehen. Einen Stecker (sei es ein ft- oder ein Netz- oder sonstiger Stecker) darf sowieso niemals am Kabel herausgezogen werden.
Zu den Sensoren - da kann Abhilfe geschaffen werden. Schickt einfach eine Wunschliste an Knobloch - wenn die Stückzahlen eine sinnvolle Fertigung zulassen, ist da alles möglich. Und unterschätzt nicht nicht Technik, die in den Sensoren steckt - es macht einen Unterschied, ob man mal schnell für sich selbst einen Sensor zusammenbastelt oder ob man das in 1000er Stückzahlen zuverlässig herstellen möchte.
was die Elektrik (hauptsächlich Verdrahtung) betrifft, bin ich gespalten.
Auf der einen Seite scheint die "Verdrahtung" - wenn man es so nennen kann - bei Lego einfacher. Klick und weg.
Aber: Man braucht (teure) Spezialkabel, man kann sie nicht in beliebigen Längen herstellen (eine Crimpzange zum selber Herstellen kostet ein Vermögen).
Bei großen Industriemodellen sieht man sehr schnell, welches System flexibler ist.
Außerdem "sieht" man nicht mehr, wie die Technik funktioniert. Auch, wenn es lästig ist: Bei fischertechnik ist ein Stromkreis zu "sehen", man braucht eben 2 Adern, damit ein Motor läuft. Bei dem Encoder bzw. bei den Sensoren ist es ähnlich - Versorung +/-, Rückmeldung - das ist eine in der Industrie ebenfalls weit verbreitete Methode, Sensoren anzuschließen.
Bei Lego ist das nur ein Kabel - da wird alles auf eine "Black box" reduziert.
Natürlich ist es Ansichtssache und vom persönlichen Geschmack abhängig, welches System man bevorzugt. Ich persönlich finde aber, dass es didaktisch wertvoller ist, wenn man einen Stromkreis nachvollziehen kann - diese "plug & play" Steckverbindungen tragen m.E. zu einer gewissen "Verdummung" bei.
Die Probleme mit den Steckern kann ich nicht nachvollziehen. Das Stecksystem ist identisch mit den bei Modelleisenbahnen verwendeten Steckern (2,6 mm) und wurde (wird?) dort millionenfach eingesetzt. Ich habe sicherlich Kabel im hunderter-Bereich, und wenn man sie exakt nach Anleitung (mit der umgelegten Litze) herstellt und sauber verschraubt, hat man wenig Probleme damit.
Das in dem Beitrag angesprochene Problem mit dem Herausziehen am Kabel zeigt mir, dass man sich heutzutage keine Gedanken mehr macht, wie man etwas optimieren kann. Man nehme den mitgelieferten Schraubendreher - wenn man den in die Querbohrung einführt und als Hebel benutzt, kriegt man jeden Stecker wieder raus, ohne am Kabel zu ziehen. Einen Stecker (sei es ein ft- oder ein Netz- oder sonstiger Stecker) darf sowieso niemals am Kabel herausgezogen werden.
Zu den Sensoren - da kann Abhilfe geschaffen werden. Schickt einfach eine Wunschliste an Knobloch - wenn die Stückzahlen eine sinnvolle Fertigung zulassen, ist da alles möglich. Und unterschätzt nicht nicht Technik, die in den Sensoren steckt - es macht einen Unterschied, ob man mal schnell für sich selbst einen Sensor zusammenbastelt oder ob man das in 1000er Stückzahlen zuverlässig herstellen möchte.
Gruß
Thomas
Thomas
-
Dirk Fox
- ft:pedia-Herausgeber
- Beiträge: 1845
- Registriert: 01 Nov 2010, 00:49
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Kritik auf /.
Hallo zusammen,
in Punkto Elektrik kann ich thkais nur zustimmen: Wenn ein Stecker zu locker oder zu fest sitzt, kann man ihn leicht mit einem feinen Messer etwas auf- oder einer kleinen Zange zusammenbiegen, und das Herausziehen mit dem Schraubendreher ist auch kein Problem (bei den alten Steckern konnte man ihn sogar quer durchschieben). Das beherrschen 7-Jährige - warum das jemand nicht gelingt, der beruflich mit ft arbeitet, kann ich nicht nachvollziehen. Und dank der zweifarbigen Stecker und farbigen Leitungen lässt sich eine Schaltung in der Regel auch gut nachvollziehen. Wird es komplexer, helfen Klebezettel mit Aufschrift an den Kabelenden oder auf den Steckern.
Auch die Kritik an RoboPro teile ich nicht vorbehaltlos: Sicher, die Programmierumgebung hat ihre Grenzen, aber ich bin sehr überrascht, was damit alles funktioniert - auch durchaus komplexe Algorithmen bewältigt RoboPro anstandslos. Besonders gut gefällt mir die Möglichkeit, parallele Prozesse zu starten und diese interagieren zu lassen; das ist wirklich sensationell einfach (während meines Studiums ging das nur mit unbezahlbaren Transputern). Für Funktionsmodelle ist das fast immer völlig ausreichend, und einige Modelle gelingen beeindruckend professionell. Tatsächlich schwach ist das "Human Interface" (z.B. keine Verarbeitung von Zeichenketten; keine Möglichkeit, Buchstaben einzulesen oder einzugeben; keine über Koordinaten ansteuerbare grafische Ausgabe; keine Smartphone-Apps zur Bluetooth-Kommunikation mit dem TX).
Auf die Mechanik lasse ich gar nichts kommen: Bisher habe ich (von einem einzigen Modell abgesehen, aber das ist auch nur eine Frage der Zeit
) immer eine befriedigende Lösung gefunden.
Bleibt die Kritik an den Sensoren. Ja, da hätte ich tatsächlich einen Wunsch: Eine geeignete Art von Gleichgewichtssensoren wäre eine feine Sache. Vielleicht auch ein Schallsensor. Und eine Kamera wäre genial...
Beste Grüße,
Dirk
in Punkto Elektrik kann ich thkais nur zustimmen: Wenn ein Stecker zu locker oder zu fest sitzt, kann man ihn leicht mit einem feinen Messer etwas auf- oder einer kleinen Zange zusammenbiegen, und das Herausziehen mit dem Schraubendreher ist auch kein Problem (bei den alten Steckern konnte man ihn sogar quer durchschieben). Das beherrschen 7-Jährige - warum das jemand nicht gelingt, der beruflich mit ft arbeitet, kann ich nicht nachvollziehen. Und dank der zweifarbigen Stecker und farbigen Leitungen lässt sich eine Schaltung in der Regel auch gut nachvollziehen. Wird es komplexer, helfen Klebezettel mit Aufschrift an den Kabelenden oder auf den Steckern.
Auch die Kritik an RoboPro teile ich nicht vorbehaltlos: Sicher, die Programmierumgebung hat ihre Grenzen, aber ich bin sehr überrascht, was damit alles funktioniert - auch durchaus komplexe Algorithmen bewältigt RoboPro anstandslos. Besonders gut gefällt mir die Möglichkeit, parallele Prozesse zu starten und diese interagieren zu lassen; das ist wirklich sensationell einfach (während meines Studiums ging das nur mit unbezahlbaren Transputern). Für Funktionsmodelle ist das fast immer völlig ausreichend, und einige Modelle gelingen beeindruckend professionell. Tatsächlich schwach ist das "Human Interface" (z.B. keine Verarbeitung von Zeichenketten; keine Möglichkeit, Buchstaben einzulesen oder einzugeben; keine über Koordinaten ansteuerbare grafische Ausgabe; keine Smartphone-Apps zur Bluetooth-Kommunikation mit dem TX).
Auf die Mechanik lasse ich gar nichts kommen: Bisher habe ich (von einem einzigen Modell abgesehen, aber das ist auch nur eine Frage der Zeit
) immer eine befriedigende Lösung gefunden.Bleibt die Kritik an den Sensoren. Ja, da hätte ich tatsächlich einen Wunsch: Eine geeignete Art von Gleichgewichtssensoren wäre eine feine Sache. Vielleicht auch ein Schallsensor. Und eine Kamera wäre genial...
Beste Grüße,
Dirk
Re: Kritik auf /.
@Ford:
Du wirst aber zugeben müssen, dass es mit der grafischen Oberfläche intuitiver ist...
Multithreading-Systeme gibt es wie Sand am Meer. Wenn es aber darum geht, das "kindgerecht" umzusetzen, wird die Luft dünn.
Du wirst aber zugeben müssen, dass es mit der grafischen Oberfläche intuitiver ist...
Multithreading-Systeme gibt es wie Sand am Meer. Wenn es aber darum geht, das "kindgerecht" umzusetzen, wird die Luft dünn.
Gruß
Thomas
Thomas
Re: Kritik auf /.
a)
The controller in the TX-C contains only one CPU, so real concurrency is not possible at that level.
b)
Java with JNI is, because of the virtual machine, relative slow as environment for semi real time control engineering.
Java runs on a virtual machine and JINI provides this virtual machine of a bridge to the underlying hardware.
c)
MS-RDS is offering real concurrency in case there are more cores (multi core processors) or CPU's (more PC in a network) available.
The dotNet framework is faster than the Java JNI. This because the intermediate code is translate into low level code and this code runs directly on the underlying system, without a virtual machine.
b) and c) only in the online mode.
d)
The target of RoboPro is generating machine code for the TX-C controller.
It is a close system. It is very suitable for work flow oriented programming with data flow as inter process communication and for normal low and mid range audience for fischertechnik computing. It is a good product for individual users.
Because of the structure of RoboPro, the user has only the facility of visual programming.
At the other hand, MS-RDS knows a complete different concept.
MS-RDS is supporting real concurrency (CCR) and decentralization (DSS).
Message flow oriented programming, which has a complete different approach and way of problem solving then work flow oriented programming. Message flow oriented programming is an abstract way of programming; the end user is able to stay with his thoughts very near the real problem; it is easy to understand for children too.
The end user doesn’t need to have a good knowledge of low level programming languages like: C, C++, C#, VB, Python, Java etc.)
MS-RDS allows also text based programming to create new visual building elements (activities) for the VPL (Visual Programming Language).
This makes MS-RDS VPL very suitable for technical education from the age of 10 years.
The controller in the TX-C contains only one CPU, so real concurrency is not possible at that level.
b)
Java with JNI is, because of the virtual machine, relative slow as environment for semi real time control engineering.
Java runs on a virtual machine and JINI provides this virtual machine of a bridge to the underlying hardware.
c)
MS-RDS is offering real concurrency in case there are more cores (multi core processors) or CPU's (more PC in a network) available.
The dotNet framework is faster than the Java JNI. This because the intermediate code is translate into low level code and this code runs directly on the underlying system, without a virtual machine.
b) and c) only in the online mode.
d)
The target of RoboPro is generating machine code for the TX-C controller.
It is a close system. It is very suitable for work flow oriented programming with data flow as inter process communication and for normal low and mid range audience for fischertechnik computing. It is a good product for individual users.
Because of the structure of RoboPro, the user has only the facility of visual programming.
At the other hand, MS-RDS knows a complete different concept.
MS-RDS is supporting real concurrency (CCR) and decentralization (DSS).
Message flow oriented programming, which has a complete different approach and way of problem solving then work flow oriented programming. Message flow oriented programming is an abstract way of programming; the end user is able to stay with his thoughts very near the real problem; it is easy to understand for children too.
The end user doesn’t need to have a good knowledge of low level programming languages like: C, C++, C#, VB, Python, Java etc.)
MS-RDS allows also text based programming to create new visual building elements (activities) for the VPL (Visual Programming Language).
This makes MS-RDS VPL very suitable for technical education from the age of 10 years.