MyRobotLab
.bat launcher discussion
Why we use a launcher and what this thing do at this time
- autostart mrl+script when robot power on
- autoinstall mrl at first launch ( java -jar mayrobotlab -install X Y Z )
- delete myrobotlab.log at startup ( to send clean noworky )
- replace myrobotlab.jar by a previously automatic downloaded version myrobotlab-new.jar
- reinstall whole MRL if a "signal" is sent. Actually signal if missing repo.json. Signal is sent if myrobotlab.jar changed to be sure to update dependencies and resources like mrlcomm.
I think the 2 last points need must be optimized, surely by using the agent? Off course now the script is inside ressources folders, this subdirectory will be added to an exclusion list. All files can be replaced, the config files are safe
we should support both linux and windows. so, we should have a start_inmoov.sh also. In addition to this on linux, it's common to want mrl to start on boot with a particular script with a start/stop script in the /etc/init.d , it'd be nice to have a default unix start/stop script so you can run mrl like a true unix service.
Of course, Anthony had INMOOV_START.sh but I can't see it anymore. Thanks Kevin for creating a new one!
what is the plan to reinstall mrl dependencies if the jar was updated ( by agent or other thing ) . continue using the "batch trick" and optimise things, or not ?
"I think the 2 last points need must be optimized, surely by using the agent?" <=
The Agent is very under-utilized. We "could" be using it to maintain multiple versions, and multiple instances of mrl. In order to fully take advantage of this the directory structure would need to change somewhat.
Additionally a "Very Big" improvement would be a single Ivy/.m2 cache of all the "dependencies" .. this would allow mrl instances with different set of dependencies (opencv 1.2 1.3 etc..) to run without a complete copy of all the material - updates even when dependency changes would be minimal downloads.
But these are BIG changes and should be done i the next release.. so are we done "enough" with Manticore ? Can we get started with all the big improvements on develop ?
Hello Grog, I was hoping that OpenCV with face tracking, object tracking and filters would work for the Manticore release...
Gael Langevin Creator of InMoov InMoov Robot http://www.inmoov.fr @inmoov http://twitter.com/inmoov
2017-08-19 22:31 GMT+02:00 GroG [email protected]:
"I think the 2 last points need must be optimized, surely by using the agent?" <=
The Agent is very under-utilized. We "could" be using it to maintain multiple versions, and multiple instances of mrl. In order to fully take advantage of this the directory structure would need to change somewhat.
Additionally a "Very Big" improvement would be a single Ivy/.m2 cache of all the "dependencies" .. this would allow mrl instances with different set of dependencies (opencv 1.2 1.3 etc..) to run without a complete copy of all the material - updates even when dependency changes would be minimal downloads.
But these are BIG changes and should be done i the next release.. so are we done "enough" with Manticore ? Can we get started with all the big improvements on develop ?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MyRobotLab/inmoov/issues/70#issuecomment-323546189, or mute the thread https://github.com/notifications/unsubscribe-auth/AIF2x4huLKphHYPuPsVTtnhgpBNezhekks5sZ0YigaJpZM4NOK2k .
After manticore release - directory structure needs to change so that each "new" version utilizes the same repo, but has separate directory for new myrobotlab.jar. Agent webui had a ui you could switch and select the version of jar you wanted to use.
Changing to maven for development will be a big (an much improved) change. New versions should not require another download of the repo, which has always been a pain.
we can revive this ticket and advance step by step. I really like that we do not worry about the installation of mrl and that the program intuitively detects the conditions brought by the users.
Was thinking of those first steps, to talk about, maybe some are already handled by the agent
Step 1 - MRL need to know what was the last version running / take care of personnal builds numbers also.
Step 2 - MRL detect the version changed, what to delete ? ( ressources, serviceData.json ? ) what to keep at the same place ? ( aes keys / all json files / actual inmoov config files / audio cache ... )
How about dependencies changes inside service, if we keep the old serialized version ?
Right - there needs to be seperation between "user data" and data which is owned by the service (and subject to deletion/replacement)
But these details cannot be figured out before Nixie - moving ticket to Ogre