MyRobotLab is a formidable programming tool but it is becoming more and more heavy due to the high level services such as InMoov and it will soon become InMoovLab.
MyrobotLab must be a tool to execute scripts in python language. It must manage the low level.
There should not be any high level services such as InMoov, Roomba, etc ... because it freezes the programming of python scripts and you can no longer program as you wish.
Because of this, I develop my own MyRobotLab without high level service. Too bad you do not follow this path.
Example of good service: Arduino, OpenCv, OpenNi, Servo DIY, Servo, Speech, SpeechRecognition, All low level for robotics programming.
Example of bad service that does not serve anything: All InMoov services, Roomba, ChessGame, all high level which freezes python scripts.
This is just my point of view, MyRobotlab remains a very good tool.
Thanks to all the developers.
Dom.
MyRobotLab is a framework
MyRobotLab is a framework ..
Services are the blocks within that framework ..
If you don't like a "block" you don't need to use it.
You can choose what blocks are most useful for you.
This has always been the design.
I'm glad your developing your own without high level services. Not every service is useful for every person or purpose. Not all services are at the same level of stability. You might want to share/post what you are doing to show others what you have done with "low level" services.
Cheers,
GroG
No problems Grog. All my
No problems Grog.
All my InMoov works without InMoov services. I can control every think with my python scripts.
The big problem with high level services is the software maintenance. You change always idea:
example: servo detach -> servo disable; servo attach -> servo enable... So what ??
and i have a lot of example like this.
But OK, it is just my view.
Software changes keep
Software changes keep software alive .. people come with new and better ideas, and change occurs... hopefully it improves, and get more strong. Its evolution ..
Dead software is very stable, if you want dead software use COBOL or use DOS.. this was once popular software - now it is dead - but very stable.
If you want to know the specific reason for the Servo attach/detach --to--> enable/disable change, it is here :
https://github.com/MyRobotLab/inmoov/issues/55#issuecomment-296042005
This post give me a
This post give me a borg idea, so long time I play with msdos
https://github.com/ianopolous/JPC
Ahahahaahaa :D :D :D Duke
Ahahahaahaa :D :D :D
Duke Nukem on MRL !
It's evolutions...but where
It's evolutions...but where do you stop ? In the end the python script is:
i01.start()
that it.
The behavior of InMoov will be the same for everyone. It will become a toy with an ON / OFF button.
It is not my view for robotic research.
Dom.
conceivably i01.start()is a
conceivably
i01.start()
is a place were "many people" can start - it might includ ProgramAb, Speech Synthesis, Vision, Tracking, and thing which the InMoov team consider worthwhile. We all are trying to evolve these complex systems into something which "many people" can begin playing with. We are trying to make these blocks approachable, and fun.
Some may feel the blocks you play with are too complicated. Some with think they are too simple.
MRL is framework which support both.
MRL is the playground.
Children may soon be comfortable playing with these blocks controlling a virtual InMoov
http://myrobotlab.org/content/blocks-mrl
Yet Academic Professionals have used MRL in their work.
Below are two references of two Phd thesis both utilizing MRL.
Both Children and Professors need to play and experiment, both can use MRL set of block. They get to choose what blocks they want to use.
In my opinion there is no
In my opinion there is no problem in building a inmoov service that can do all the basics on one click:
As you say it everybody would just click and the robot does the same thing. But what now? Nobody who is dedicated enough to build a whole robot will rest here. For me this is a solid and sain basis where everybody looks all the other servies (there are so much different services...) and tries to add it to its InMoov for a particular task or range of tasks.
And with a clean start there is a lot less frustration and there will be more people joining the community instead of using other robotcontroller.
For the changes of code, as GroG said they are necessary and for me it was always easy to change te cod to be worky with the new build if there is not a service missing like with Accapela Speech lately.
For info
I'm always amazed by how you
I'm always amazed by how you dispite everything that do not fit how you see things. It is not because you don't use or don't like some MRL block that make them bad things or useless thing for everyone.
MRL is a nice playground for everyone that want to play with it, or add their toys to share with other that want to play with them.
But you want us to throw away what you don't like and only work on what you want. You are free to play with the toys you want, but don't put in the garbages other people toys
And Dominique, you are a talented coder, but I still don't understand why you like to paint yourself in a corner by trying to develop some dead code. Manticore will have many great improvement over Lamiak. One of the most noticable improvement of the latest build over Lamiak that will affect what you do is the increase stability of the communication between MRL and MrlComm. In a recent conversation we had in the french forum, you claim that MRL cant compute 10 pid or so. You are right that with Lamiak it can't do it, but not for the reason you give but because the communication with MrlComm was not stable enough to withstand it. With the latest build, I can compute the position of about 15 servos by running simultanously 4 IK engines that not only compute the location of the 'arms' but also compute and react to the probability of collision with other part and items around and adjust their position so the robot can keep it's balance. That is far more computing and positioning of the servo than a douzen of Pid running and it work perfectly.
But again, you prefer coding from a code that is faulty just because you couldnot make one thing work like you want. Well, you are free to lose your time the way you want
Why i don't use Manticore
Why i don't use Manticore ?
Because i can't used MrlComm 55 on arduino mega serial port. I don't know why. If it 's work, so i can use Manticore.
Sorry.
yes, you said that many
yes, you said that many times, but you never give any useful information on what you are doing so we can reproduce the problem and fix it. Instead you insults the person who have try to see if it was working or not. Really not a good way to get any help
Bon Christian, la ça suffit.
Bon Christian, la ça suffit. Je reviens en Français car apparement l'anglais ne me réussi pas !!!
J'ai fait un post ici concernant mon probleme avec MrlComm 55. J'ai donné le test que je faisais...
Pour rappel, j'avais déjà signalé mon problème sur le site InMoov ici: http://inmoov.fr/forums/topic/mrlcomm-version-55/
Les tests qu'Anthony a fait ne servent à rien du tout. Il la fait uniquement pour se foutre de moi et m'enfoncer encore plus...
Donc, encore une fois: Je connecte à chaque ports séries du mega un nano contenant MrlComm 55. Le PC doit donc gérer 4 communications à travers le port USB. J'ai déjà essayé le noWorky, MAIS ça n'a jamais fonctionné chez moi. Je précise que je désactive la demande d'info pour soulager la com.
Le même test fonctionne sans problème avec MrlComm 41. C'est vrai qu'il y a beaucoup moins d'info coté protocole. Mais avoue que ça doit aussi fonctionner avec la version 55.
Bon, ce que je te propose, si tu est d'accord, et d'essayer de trouver une solution ensemble. J'essaierai de te faire des screenshots des problèmes. Peux tu me donner ton mail afin que j'ai plus facile pour t'envoyer mes rapports et screenshot ?
Dom.
PS: Dans ce post, j'ai juste donnez mon point de vue sur MRL, sur le topic "suggestion". Chacun est libre de donner des avis non ? sinon, ce n'est pas un forum...
As you say it is enough .So
As you say it is enough .So many time before to come here you blast out myrobotlab, people and the project in general. Too many times. That's enough.
So, time to delete your fork and work with us in cheerfulness, or time to leave . now
Dominique, tu as expliqué ce
Dominique, tu as expliqué ce que tu tentais de faire, mais pas comment tu t'y prennais. Montre ton code que tu utilises de facon a ce qu'on puisse rapidement répliquer ton problemes.
Pour moi le service fonctionne bien pour l'usage que j'en fais. Il est possible que tu utilise le service différamment et c'est tant mieux. Mais je ne peux pas passer des heures a essayer de deviner comment tu t'y prend.
Tu as le drois de donner ton opinion, mais suggerer de retirer les services que tu n'utilises pas et n'as pas l'intention d'utiliser N'EST PAS une suggestion constructive et va a l'encontre de la philosophie de MRL. Ca me semble bien egoiste de suggerer d'enlever le travail d'autrui parce que tu n'en vois pas l'utilité. C'est utilse pour d'autre personne
Je t'envois mon courriel en privé sur le site de inmoov.fr