OK,
I've gotten some help working though some of the issues I've run into, and figured out a couple of others by digging though various examples and source code, and determined that things are changing so fast that a lot of things that worked before in previous versions, no longer work (or at least not in the same way). APIs are in flux and that makes it even more confusing for someone coming in new to MRL.
So here's a tracking script based on what Kwatters gave me early on (with changes to make it run cleanly and some other tweaks to experiment with setting velocity and PID values.
=== Start of script ===
xPin = 3; # Head X-Axis Servo
yPin = 4; # Head Y-Axis Servo
arduinoPort = "/dev/ttyUSB0";
cameraIndex = 0; # These all need to be created ahead of time o/w we get null pointer exceptions.
# Index 0 is if there is no external camera, 1 is the index if there is already a camera on the computer.
# create the servos that will control our x and our y tracking.
x = Runtime.createAndStart("tracker.x", "Servo");
y = Runtime.createAndStart("tracker.y", "Servo");
x.setPin(xPin);
x.setVelocity(20);
x.setRest(90);
y.setPin(yPin);
y.setVelocity(30);
y.setRest(125);
y.setMinMax(70.0, 160.0);
y.map(0, 180, 70.0, 160.0);
theMinY = y.getMin();
theMaxY = y.getMax();
print 'theMinY', theMinY;
print 'theMaxY', theMaxY;
controller = Runtime.createAndStart("tracker.controller", "Arduino");
controller.connect(arduinoPort); # now create the tracker service.
tracker = Runtime.createAndStart("tracker", "Tracking");
tracker.pid.setPID("tracker.x",5.0,1.0,0.1)
tracker.pid.setPID("tracker.y",5.0,1.0,0.1)
# uncomment if your camera is rotated 90 degrees
# tracker.addTransposeFilter();
tracker.connect(arduinoPort, xPin, yPin, cameraIndex);
tracker.startService();
tracker.startLKTracking();
=== End of script ===
This "amost" seems to work. But there is one thing that I see right off the bat. I had mentioned this buried in an older topic so it probably has gotten lost.
After the script has gotten things going In the tracker.opencv tab in the filters 'current' list I have multiple PyramidDown/Gray entries with an LKOpticalTrack entry followed by 3 more pairs of PyramidDown/Gray filters. Is this normal? I would expect at most one PyramidDown, one Gray and one LKOpticalTrack in the list.
Attempting to change the filters (e.g. remove or add) seems to break things so video is no longer processed by LKOpticalTrack. But even then if I have cleared the current list and added PyramidDown and Gray back in the LKOpticalTrack no longer shows active video, just a still frame. And it's as if the PyramidDown AND Gray are both still applied. In this test case I have just Gray and LKOpticalTrack filters set as current. When Gray is selected I have a full color live video stream appearing in the video widget. If I click on LKOpticalTrack it shrinks to the size when PyramidDown is install and is a Gray still fame from before.
I tried to go back to the 1723 MRL build which Gael had indicated on the InMoov site as working well, but trying to get tracking working in that build using some examples I found as well as disecting the InMoov script(s) from Gael I am missing something since it throughs a NULL pointer exception but I haven't yet been able to figure out what I could be missing in the setup.
Looking at the issues for the latest build I see that Tracking is not listed as ready for release, so I'm probably trying to beat a dead horse here trying to get it working without digging into the underlying code and seeing if I can sort out what is breaking it.
When I say that it is almost working for me. There are times when I can have the camera see an object and I click on it in the video widget then the head starts to try and track the object. If I move the object back and forth a bit the head will move back and forth a small amount and then finally stop looking straight at the object. That would be the sunny day case. But then other times it seems to ignore the object and winds up partking at a limit point.
Note I'm still not certain that the PID values are actually doing anything for me, I need to try a bit more when I'm fresher, but the way the head seems to oscillate back and forth in a manner different from videos I've seen with older versions of MRL doing tracking makes me thing that PID isn't working properly for me.
So are there any other suggestions on how to track down what might be going on, or should I just move on and either write my own code to interface openCV with the arduino to test out tracking and then hopefully in the near future some of the remaining issues that I'm seeing with Tracking in MRL will be cleared up?
Thanks,
Burt
Noted a few days ago also the
Noted a few days ago also the problem with openCV and the duplication of filters in the filter list. And run into the same problems trying to create a proper sequence of filters.
Something is broken there with the latest releases.
Thanks. confirms I'm not alone:)
Thanks,
That confirms that there is an issue beyond just my configuration. If I have some time to dig though the code maybe I can spot where the problem is. But if it winds up taking too much time then I'll have to look at other options and come back to MRL in a bit to see if things have stabilized.
One of the biggest annoyances is the shifting APIs. They change from version to version of MRL, which makes writing Python code fun, NOT! It would be a bit easier if there was a wiki, or other docs that clearly says in version abc2 this API has changed and you need to make the following changes to any code you had for version abc in order for it to continue running properly.
IMHO this is a problem for newbies since many examples that are out on the web and YouTube show things working well, but they are for the most part all very old verisons, and in many cases they don't even list the version of MRL that is being used.
Burt
Hi Burt and Welcome, Thanks
Hi Burt and Welcome,
Thanks for your detailed posts, rarely do we get so thorough response.
Yes,
It would be nice to have a wiki, and api, and other docs, and a horde of graduate cs students to do our bidding, and a million dollars. But we don't. Your "spending too much time" on things is a fraction of the time others have spent on the system as a whole.
With that said,
Yes we are working on stabalizing things, but it is a balance, and we have very limited resources. Previously, we did not even have 2 branches - we only had one. Previously, we did not do any for of release, now we do.
Here a list of things we are working on now :
We do have a concept of "service page" - http://myrobotlab.org/
In the swing gui - you can right click on the service - and (info) will take you to the service type page (if it has one)
Some have examples of Python code - but since its on the web site - it can be different from the release. We are working on stabalizing this.. but that too take "a lot of time"
We would like to have a video in each service page - "but that takes time"
I do like your idea of having the version in the video, mrl has it clearly in both swing and web guis.
If your looking for simple function signatures you can always use the web gui's rest api to query the services.
Above .. I just started mrl with the webgui - it shows 2 services running runtime & webgui
I can look at the data which webgui contains with the following url (this represents its "state")
This tells you what port its listening on, if its using local resources, what the start url is ... and many other details regarding display (which it's in charge of .. since its a GUI)
if you add one / at the end, the data which comes back is all the methods you may use -
So, for the webgui you'd use http://localhost:8888/api/service/webgui/
Th
The webgui has many methods ..
this url will list all of the webgui methods - their parameters, parameter types, and return types.
Any service can be queried in the same way.
You can even call the method from the url .. for example
http:localhost:8888/api/service/webgui/getPort will return 8888,
and you can set the port with
http:localhost:8888/api/service/webgui/setPort/9999
All of this is accessable from Python too..
e.g.
webgui = Runtime.start('webgui','WebGui')
print(webgui.getPort())
webgui.setPort(9999)
print(webgui.getPort())
Granted, it does not tell you the why or when you would use the method, bit it is never out of sync, since it reflects the current running system.
Thanks for the additional info
Don't get me wrong, I think that MRL has some great potential, and I can appreciate that there's not a big development team behind it.
One problem I have with the WebGUI at least with build 2000 is that quite often Firefox gets locked up when the WebGUI is present. Not all the time, but enough to be annoying for sure.
If I open the WebGUI in Chrome instead it doesn't lock up Chrome when the problem comes up, but Chrome reports that a script has stopped, so the end result tends to be the same. Again not every time, but enough to be annoying.
So I haven't spent a ton of time in the WebGUI because of this, but I'll take another look to see.
What I was thinking about would be a Wiki where "power users" of MRL could put some notes, including some sample Python code with what version of MRL that code runs well on. Perhaps with write access limited to those users to start.
One other thing that happens from time to time, with build 2000 and maybe the older one (1723) is when I start MRL it crashes. Once in a while I may need to try starting it up to 3 times before it "takes". This is with Oracle Java 8 JDK installed on Linux Mint 17.1.
Generally after it has once started it seems fine even if I exit and restart, but sometimes just getting it to start up the first time is problematic. Note that this is a fresh reinstall of Java 8 after completely removing the previous installation and also no OpenJDK present.
Thanks again,
Burt
MRL Logfile
When you start MRL there is a logfile "myrobotlab.log" beeing created in the install folder.
It may give some clue to why MRL doesn's start.
Also make sure that when you install a new version of MRL, you do it in an empty folder.
The logfile gets appended to, so it's a good idea to delete it before starting a new MLR instance to keep the size of it down, and make it easier to find any problem during startup,
Thanks
Thanks Mats,
I know about the log file, and the fact that it is appended on each run. Today MRL was starting fine each time I worked with it, plus when it has choked it has had some different things listed in the log file so no clear culprit.
I'll nuke the logfile and see if I can capture anything usefull when it fails in the future.
The WebGUI, unfortunately, WAS causing problems as I have seen quite often. In Firefox it causes Firefox to pretty much lock up until I can manage to kill MRL and click on the WebGUI tab and close it, then if I minimize and bring the Firefox window back up then the WebGUI is gone, and after a couple of minutes Firefox is fully responsive again.
With Google Chrome when the WebGUI chokes Chrome pops up a message about the page being unresponsive with options to Wait or Kill the page.
The Firefox issue could be something about my specific installation, but since both Chrome and Firefox seem to be having issues with the WebGUI then there is probably a buglet lurking somewhere.
I'll check the log file to see if there are any clues there.
I was able to grap the API data and copy it off before the WebGUI choked, so I have that to refer to.
When I install a different version of MRL I have been doing so in a fresh directory so there should be no confusion with any old bits laying around.
Burt
in more recent builds of MRL
in more recent builds of MRL I believe the WebGui is not one of the services which start by default.
If you don't want it to start, or if you want other services to start by default, you can pass that information on the command line.
java -jar myrobotlab.jar -service arduino Arduino servo01 Servo
starts an Arduino & Servo service - called arduino & servo01 respectively .. nothing else should start, except runtime...