Hi,

I am trying to create my own InMoov services - or at least modify the existing ones. This is because I used Mats InMoov head which works a little differently to the "standard" InMoov.

I started by creating brand new services based on InMoov - but that just produced so many errors I didn't know where to start.

Next I loaded MyRobotLab 1.0.1723 (Kraken) and that runs fine standalone - but I can't modify it.

I managed to get my myrobotlab git repositry in Eclipse back to the 1.0.1723 release (I think) and tried to run the same toplevel script in Eclipse debugger that I had run standalone, but I get lots of errors (see attached log) and I don't really know where to start looking for a fix - if it was C or some other language I might stand a chance, but I am still learning Java :-(

Could someone point me in the right direction to fix this please?

Best Regards

Andrew

burtbick

7 years 8 months ago

I feel your pain:) I know that doesn't help much, but I'm wrestling with a number of Java related issues myself trying to get to a point where I could take a stab at getting some things fixed in MRL that I need to have working.

In my case I have issues with 64 bit Oracle Java running on Linux 64bit Mint 71.1 with intermittent crashes, not just in MRL but more often than not with MRL. If it was just limited to MRL crashes then I could work on debugging it with Eclipse but unfortunately Eclipse wants to crash randomly as well. With 32 bit Java running in VirtualBox on the same computer I don't have the crashes like I see on the 64 bit real machine, but it is much slower and I haven't been able to get Webcam access working yet in the VM so that is a non-starter as well.

And I have an older 32 bit machine that I have 32bit Ubuntu 15.10 installed on and 32 bit Java an MRL as well as Eclipse seem to run without crashing there, but that box has limited RAM and a slower CPU so that is also a PITA to work with.

Right now I'm trying to get Java, Eclipse, Arduino and MRL installed and working on a Win10 64 bit box but that has not been a walk in the park either. I spend as little time in the M$oft world as I can because I tend to find that it is slow and clunky plus the phoning home to Redmond for many more things especially with Win10.

For example for Arduino the recommended install path is via the M$oft store, but that is pathetically slow at least on this box, and along the way the Microsoft "Settings" applet suddenly refused to launch. I did get Eclipse and Oracle Java 8 64bit installed, but it is slow going.

There appear to be two camps as far as Java is concerned. Those who swear by it and those who swear at it:) I did a bunch of Java development in the very early days of Java, but haven't touched much Java code for the last 10+ years since I've been living in the C/C++ world. I've been looking at Robot Operating System, which I find doesn't crash for me, but the learning curve is much steeper than for MRL which is why I would prefer to get MRL working reliably for me in my environment.

But if I can't make that happen soon I'll have to dig into ROS and write some services to do what I want. If I can get Java tamed then I can at least dig into the code and see if I can correct some of the issues that I'm having. In your log file I see some of the same kinds of errors that I get when running MRL and trying to do some more complex operations.

One thing to take a close look at are the APIs that you are trying to call. When I first jumped in and tried to use a script for the Tracking service I was having all sorts of similar chokes.

Turns out that due to changes in the MRL APIs with recent versions the older scripts from before no longer work with out changes. And it wasn't immediately clear from looking at what was happening to know what the real problem was.

Kwaters helped out with a bit of Python code that got me started. For example you had to have certain services created and properly named before the Tracking service would run. E.g. the Arduino service, and X and Y servo services.

But in my case the X/Y servo services had to be specifically named "tracking.x" and "tracking.y". So even knowing that there are particular APIs that have been added or removed is not enough as you need to know how to use them and which ones need to be called in specific orders, etc.

So assuming that you haven't stumbled onto a real bug it is probably caused by needing to have certain services setup and properly named before you start other services that depend on them. And currently that is difficult to sort out unless you can find an example that is working with the version of MRL you are trying to use.

Hello burtbick

Tracking service have been suffering from the recent improvement we made to MRL. We try not to modify the API as much as we can, but sometimes it's needed to do so for code performance and to avoid confusion.

I have test the Tracking service last week-end. code. It is basically working, but the initialisation is acting strangely and as you said, required to have specific name service (and it should not be that way). 

I have modify the initialisation with an alternated method that is more in line with the recent way of using different services together.

So if you have already setup servo, arduino and openCV services. all you need is to use Tracker.attach(servox, servoy) and Tracker.attach(opencv) before using the Tracking service (by example using faceDetect())

 

 

Thanks calamity:)  Yes, I have seen the impact of the APIs changing over time.  That has indeed been part of my frustration with seeing smoothly working tracking in 2 or 3 year old videos but then not being able to achieve the same results using example code from those working demos.

Having finally beaten Win10 into submission and having Java, Eclipse, Arduino and MRL all installed and basically working I'll try tracking again running on Windoze since at the moment Java doesn't appear to be crashng there.

I have builds 2020 (initialization was not working as it did with 2000) and just downloaded 2023 and have done basic servo tests with 2023.

Thanks again,

Burt

Running on Windoze 10 64 bit. MRL 2023 build

So I have created and connected an Arduino service named ard

Then created servoX and servoY and connected them to the appropriate pins.  I've been able to test and verify that the servos move fine using the sliders (and with Python code as well).

Then I created opencv and added Gray and PyramidDown filters.  First time I created the LKOpticalTrack filter in opencv, but after the Tracker.attach(servoX, servoY) and Tracker.attach(opencv) calls it did NOT appear that things were connected in that I could select a point in the video widget, but there was no movement from the X and Y servos no matter what I tried.

2nd try I waited until after Tracker.attach(servox, servoy) and Tracker.attach(opencv) calls before adding LKOpticalTrack to opencv but no change doing it that way.

Playing around with opencv changing tracking (e.g. remove LKOpticalTrack and adding faceDetect) eventually causes a failure with a frameGrabber exception Could not get pixels.  But not a full crash.

So is there something else that I should be attaching, or a different order to get things to work and play well?

Thanks,
Burt

I was finally able to get something close to tracking working.  I missed adding Tracker.startLKTracking()  after the two attach calls.

That said, the first two times that I tried it with the atted startLKTracking() call the MRL gui locked up.  No errors in the dos box where I had started it from, it was showing that video streaming was still going on.

But it is working much better than it was in my earlier testing, so there is some light at the end of the tunnel:)

I'll do some more testing running this on Linux, assuming that Java doesn't choke on me.  But it definitely appears to be an improvement.

Thanks,

Burt

 

calamity

7 years 8 months ago

Glad to see that you got some progress

sometimes the gui for tracking (or other services) tend to lock. I'm really bad with Swing and don't know how to fix that. But trying to resize the gui unlock it. worth a try next time you have MRL gui lock up

I've been having multiple cases of the MRL gui locking up as soon as I start the tracking. 

No fatal crashes, the GUI just becomes unresponsive other than clicking 'x' to close.

It worked that one time before dinner, even though it took about 3 tries restarting MRL before it didn't lock up, then the head did track my shirt quite well, stopping when I stopped moving and starting when I moved again. 

Before this version the head would kind of appear to try to track but would then run off the rails and stop looking at the celiing at either end of travel.  So this is definitely MUCH better.

I'll try resizing the gui and see if that lets me do anything other than close the MRL gui and start over.

Also, adding filters to opencv seems to be inconsistent.  I get some multiples added when I'm just adding Gray and PyramidDown and LKTracking.. And sometimes at the end if I click on LKTracking it doesn't appear to be applying the Gray and Pyramid down filters.  I'll see if I can work out adding the filters from the Python code instead of using the UI to do it.  Maybe that will make it more consistent.

Back to testing on Windoze, and then I'll see if I can get it to work long enough to test on Linux again.

Thanks,

Burt

Yeah I have notice the multiple filters appearing in the list. The bug is mostly cosmetic. I have watch at the filters and they are used normally, without duplication. But everytime a new filter get add, the list is add with all the filters without clearing it first.. Of course it bothersome if you want to play with the filters,but otherwise without much consequence

I've been doing some more testing.  Most of the time when the GUI locked up resizing it gets it going again.  A couple of times that didn't solve it, but mostly it's a workaround.

I was seeing some strangeness on Windoze, so I went back to the 64 bit Linux box and completely nuked anything and everything java and reinstalled Oracle's latest JDK which was a couple of builds newer than the previous one.  This seems to be behaving better on Linux.  I still get some chokes with MRL but no where near as bad as it was.

I had a couple of runs where the tracking was nearly perfect except it was refusing to track in the Y direction.  I wrote some script code to automate things so that is consistent with each run.

When it worked well it was tracking a small can side to side.  Very smoothly and without much hunting.  In my script I set the PID values for x and y based on what I had seen in the InMoov script(s).

But then I exited MRL (no changes to the script that had been running perfectly.

Restarted MRL and then ran the script again.  This time the head started searching and moved back to looking at the ceiling again.  I tried restarting MRL a couple more times with pretty much the same result, I can eventually get it to track horizontally, but not as nice as it was doing, and sometimes the head moves to full up Y positiion, other runs it is down lower.  But so far I can't get it to exactly duplicate how well it was running on the earlier run.

These runs were without changing the script code at all.

Have you seen any erratic behavior with tracking, or have any suggestions of what I could look at to see what might be happening?  At this point I don't know if it is something to do with OpenCV or the MRL tracking service.  Note that my Y axis can be ajusted manually using my Y servo service so it doesn't appear to be anything wrong with the Y axis itself.

Thanks,

Burt

 

calamity

7 years 8 months ago

Hello Andrews

The errors you get is because your code contains errors and eclipse couln't compile some part of MRL. Thus giving error at runtime. Fix your code and it should work. You should not code base on 1723 code. You are missing out all the improvement and bug fix make to MRL since that time (that's 300 commit old). One of the most frequent error I see when using fresh source in eclipse is that eclipse do not seem to use utf8 by default. switching to utf8 and rebuild will probably fix all the errors. Also make sure you clone the repo.

Now I don't find comments like "fix your code" help and in my experience can often come back and bite you on the ass!

The full story is I tried the latest MRL and wrote my own services but couldn't get them to run, so I went back to approved InMoov method.

On the InMoov site it says to use only approved and tested releases of MRL as often commits to the MRL trunk can and do break InMoov, there are lots of comments on their forum about this.

So I downloaded and installed the approved Kraken jar and this ran the InMoov script quite happily on my installation. Hence I reverted to the Kraken release in Eclipse.

There are errors in the code when i try to run MRL because one of the MRL files tries to import stream.collectors but can't find it - this is MRL code not mine!

But the Kraken jar does run on my machine and I thought that was the wonderful thing about java - you can run it on any machine?

I would quite happily accept that my Eclipse setup is not correct which is why it can't find stream.collectors and why I came here for help on getting things running not ridiculous unhelpful comments like "fix you code"

If anyone else could provide some helpful encouraging comments I love to here them.

Best regards
Andrew

Hi Andrew

Start Eclipse. Select Java perspective. Rightklick on myrobotlab and select properties.

In the Resource tab, select Text file encoding => Other => UTF-8.

That should fix the utf-8 problem. 

But I also think that you have a problem with repo and myrobotlab repositories beeing out of sync or that the classpath needs to be updated.

If you want to struggle with version 1723, it's your choise, but all other developers are on the latest release. 

If you get errors when using your script, it's much easier for us to help you if you are on the same release as we are.

Andrew

All you provide was a log file and said it not working. The log file show that some class have not been compiled, so it cannot be used by MRL. You did not provide any information about the errors that you are seeing or any information on how you setup things. So yes, the best information I can give you is that you need to fix those errors to have things working. 

If you follow that information page http://myrobotlab.org/quick_start it will work. I use the mrl code on a daily basis and everything compile fine. So if you have errors it's because you did or didnot do something. 

But please don't complain if you got a vague answer to a vague question.

Thank-you Calamity.

Re. "The log file show that some class have not been compiled,"  Now that's the kind of advice that is helpful :-)

Anyway putting all that aside, having asked for advice I thought it only fair to test it....

I deleted my git repository and started again, after some initial sound issues that were to do with my machine, MyRobotLab is now running my InMoov script and my bot even chats to me :-)

Now to start editing.....

Getting Started