First I want to say that MRL looks teriffic and I have seen a lot of good things being done with it.  I've finally started building a robot based on InMoov, basically using InMoov design for the head to start but looking to incorporate my own designs for the rest of the body.

I've been trying to get MRL up and talking to Ardunio, but I have a couple of questions.

 

First I'm running on Linux, and not Windows.  I have MRL latest .1758 installed and all addons installed as well.

In examples I have seen on line when starting the Arduino service one of the views gets populated with the code for MRLComm.ino that should be copied and pasted into the IDE and then uploaded to the Arduino.

I have not been able to find where .1758 provides that code.  So after a lot of searching I found a reference to a spot on GitHub to download MRLComm, but it appears that is an old version (version 18 as far as I can see).  Since .1758 wants version 40 we have a failure to communicate so to speak.

Also the version that I downloaded has the baud rate set at 57600 instead of 115200, which I corrected.  I've done some testing by changing the Arduino MRLComm .ino file to send 3 variables and have verified that the result is correct, so I'm figuring that the real problem is that I have a mismatch between .1758 MRL and the MRLComm.

So my first basic question is how do I get the correct MRLComm library and .ino file to match the .1758 version of MRL?

Secondly, I'm traveling right now and didn't bring one of my UNO  boards with me, I just have a Nano board, which doesn't have much dynamic memory left after loading the MRLComm code, so that may become an issue after I resolve the MRLComm version, but I need to correct the MRLComm version mismatch first.

Thanks,

Burt

calamity

7 years 8 months ago

Hello burtbick, welcome aboard!

the examples you have seen are probably outdate one. Here a proper tutorial to upload recent mrlcomm to an arduino

http://myrobotlab.org/content/uploading-mrlcomm-arduino-0

the version 1758 is the latest version that was flag as stable. I suggest you to get the latest build.It's the development branch, so you may expect some bugs here and then, but it also include a lot of improvement compared to1758. You can find the latest build link on top of the shoutbox

MrlComm should work fine on the nano board. nano have the same memory as the uno. That should not be a problem.

Thanks.  Sorry about the second post, I didn't see the first post appear, and I would up answering my own question after digging some more and just going for it with the MRLComm from the latest stable build.

I'll give the development build a shot when I get back home where it is easier to try things.

I do have a question on how to get Tracking working:

I found a video by Alessandro Didonna that looked promising, but the python code that he had was giving me errors.  Specifically the line tracker.SetRestingPos(90,90); says that there is no such method in tracker.

Beyond that I can get opencv showing the output from the camera and select a point on an object to track but my problem is that I don't seem to be able to get the tracking.x (or .y) servo to attach, so things don't move.

If I create two servo objects, x and y I CAN attach to those servos and control them just fine.  But as soon as I load the tracker module things go south.  If I have the previous x and y servos still connected I can still manipulate them, but stll cannot get the tracker versions of the servos to attach.  Clicking attach does nothing.

If I don't create the servo objects before loading the tracker python script code then I still cannot attach to the x and y servos via tracker.

Is there an updated example of how to use the tracker module?

Burt

 

A bit more information on tracking problem I am having.

I see a number of these error messages in the log:

[runtime] ERROR c.m.i.FileIO [FileIO.java:994] can not find resource [/resource/Arduino/MrlComm/MRLComm.ino]

Leading up to:

23:10:51.657 [runtime] INFO o.m.s.Tracking [Tracking.java:319] rest
23:10:51.658 [runtime] ERROR c.m.s.Arduino [Arduino.java:1244] getDeviceId could not find device tracking.x
23:10:51.658 [runtime] ERROR c.m.f.Service [Service.java:2131] runtime error createAndStart(tracking, org.myrobotlab.service.Tracking) error
23:10:51.659 [runtime] ERROR c.m.l.Logging [Logging.java:19] ------
java.lang.NullPointerException
    at org.myrobotlab.service.Arduino.servoWrite(Arduino.java:2340)
    at org.myrobotlab.service.Servo.moveTo(Servo.java:367)
    at org.myrobotlab.service.Servo.rest(Servo.java:411)
    at org.myrobotlab.service.Tracking.rest(Tracking.java:320)
    at org.myrobotlab.service.Tracking.startService(Tracking.java:506)
    at org.myrobotlab.service.Runtime.createAndStart(Runtime.java:267)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.myrobotlab.framework.Service.invokeOn(Service.java:1315)
    at org.myrobotlab.framework.Service.invoke(Service.java:1253)
    at org.myrobotlab.framework.Service.run(Service.java:1676)
    at java.lang.Thread.run(Thread.java:745)
 

First off in Linux directory and file names are case sensitive.  In the installation on Linux there is a MRLDir/resource/Arduino/MRLComm subdirectory that contains MRLComm.ino where MRLDir is where MRL is installed.  As a quick check I made a new directory MrlComm and copied the files from MRLComm directory to the new directory.  Same problem.  So if the path in the error message is correct it looks like it is trying to find the MRLComm.ino file off of the linux / directory and not relative to the the MRL installation directory, but I haven't looked at the Java source to confim this.

 

In any case it appears that my problems with tracking is related to this failure.  Has anyone else seen this problem, and if so how did you correct it?  Perhaps the bleeding edge build will be worth a try to see if that corrects the issue.

Thanks,

Burt