Hello all,

I'm working through object tracking and keep encountering a couple of issues.   I am experienced in several programming languages, Arduinos, and animatronics and have gotten this to work before using OpenCV and Processing, but now I have a nearly complete InMoov and feel it is important to learn MRL from the basics so I know how it all works.    

But I'm having some trouble and there are a few too many moving pieces for me to get a complete picture of what is happening.   

Basic set up is a simple Ubisoft SD camera on a 2-servo pan and tilt mech.  

I'm running MRL 1.01.1165, the latest 32-bit Java 8.77.  (I set this up on 3 different computers to troubleshoot). 

When I configure manually, the servo sliders and camera work properly and in the correct directions. The X and Y pids have options in them as they should. 

My Python scripts (both the very basic one from the tutorial and the more advanced one from the information link) are properly configured for servos, ports, etc.  I have not altered PID settings in the script.  The Arduino is running version 27 of the control IDE and magic number is happy.  I am using the 3 default OPenCV filters from the script. 

I then shut MRL down, terminate the extra java process and start again using the Python script that has been modified for ports and pins. 

The Python script loads and runs and I get an initial response from the Pan &Tilt and camera.  The camera tracks in the correct directions.  I can get the camera to lock on an object that is very near the center of the camera image.  

But then the camera drifts off into space and one of two things happen.  Either I get a Limit out of range error and the Arduino stops communicating, or the camera just moves off of the object and becomes unresponsive.  I do not see any relevent error messages in the log file.

I noticed that in the latest version of MRL, when I run the Python script for object tracking, there is only one PID (not PID2) and there are no options to adjust servo movement.  This is different then when I set up PIDs manually.  Also, when I un-comment the setPID lines in the Python script, I get a Python Traceback error, so I haven't changed those settings.  Apparently there is something else I have to uncomment to alter the default 5.0, settings.   

I have tried:

3 different computers. (There were some 64-bit Java issues) (Windows 10 and Windows 7)

4 different Arduino units (mega and R3 Uno)

Different servos (all digital)

3 different cameras

Different USB ports

Several Arduino pin-out combinations.

The InMoov Nervo board, a servo shield, a proto shield or direct pins to the servos.  


By most accounts and my own experience, this should be a piece of cake, but I'm missing something obvious.  I've put a really stupid amount of time into troubleshooting this and very much want to get it working so I can get back to my currently-motionless InMoov. 

Any ideas?  





6 years 6 months ago

Hi Scott

I think that there is some issue with both PID2 and Tracking. 

1. Tracking doesn't use PID2 the way it should be used. For example when it executes the compute method it checks if it returns true or false. True means that a new calculation has been done and false that the output values are unchanged. But Tracking reports false as "x data under-run" or "y data under-run"  .

2. PID2 has an issue that cause values to be reset when the setPID method is executed.

3. The input and output values to PID2 are not set the correct way. Facetracking will return a value between -.5 and .5 depending on where it detects a face. 0 is in the middle. That should make the servo move to position 90 ( If only P is set and I and D is 0 ). But it will move  to position 0.

4. Since the error above exists, the PID values have been set in a way that the P portion doesen't make much difference, and if the servo moves to the correct postion, then it's because of the I portion.

5. The sample scripts needs to be updated, since Trackning has been changed to use PID2, not PID.

So at least five issues may cause Tracking noworky.

I started to work on Tracking, found the problem in PID2, but wasn't sure how to correct it, so the problem still exists. And since Tracking uses PID2, I wanted PID2 to work before continuing with Tracking. But the I ended up doing other changes,

Thanks for posting. Since you also experience problems, I will try to solve it. I may need some help from kwatters or grog.

Sorry if I went a bit technical, but I just wanted to write down my findings to make it easier to get Tracking back to a good state,


Hi Mats,

Thank you very much for the quick response.   

I thought that the script I am using is invoking the original PID, not PID2.  There is only lone tab though, (called PID), so it is entirely possible that it is pulling PID2 and if you say tracking uses PID2, that seems likely. The lack of controls in that tab scream PID2.  Gael suggested I roll back to a prior version of MRL, so I am going to try that.  

This is very similar to getting OpenCV working under Microsoft Visual Studio.  Any time one of about 30 related versions change, even Windows OS related updates, the thing fails.   The difference here, though, and the reason why I am so enthusastic about it, is that I can rev-lock this once it is working.  You can't really rev-lock Visual Studio because there are so many dependancies that are integrated to the OS.  

And speaking of version issues....what version of Java are you using?   

I will keep banging on it!   








On my PC with Windows 10 I use this:

java version "1.8.0_66"

Java(TM) SE Runtime Environment (build 1.8.0_66-b18)

Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
On my Raspberry PI 2 I also use Java from Oracle, since it's 8 times faster than the default java.
Don't remember the exact version but it's 1.8.... something.