A small update on my InMoov build


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
GroG's picture

Great update Mats .. I'm

Great update Mats .. I'm really excited about the connectivity between the 2 RasPi(s)..

It needs refactoring, but have you connected 2 instances before ?  Is this how you plan to operate it ?

Distributed Processing is so cool !

Mats's picture

Distributed processing

Yes Grog.

I tested connecting two instances before. It's more than a year ago, and it was a success. I didn't test all services and all methods at that time. I was just happy to see that it really was supported by the framework. http://myrobotlab.org/content/headless-head

So now it's time to start testing distributed processing for real. I guess that some things may fail, but thats's OK. I'm in this project to learn, and to contriibute to the development of InMoov and MRL.

I have had some problems connecting to my WiFi network because of the distance between my router and the PI's. But I will work that out. I also currently have some problems with connecting the PI camera to the Raspberry PI 3. I know that both the camera and the PI are worky, so it's probably a software problem.  

All the servos in the body and head are connected now. I just need to get  WiFi worky and make a demo script to show it. Currently working on putting a servodriver in the right arm. Left arm and hand are in for a major redesign so that the sensors will fit.  

hairygael's picture

Very great progress Mats! I

Very great progress Mats! I like the disposition of your hardware in the back.

Mats's picture

Distributed processing

All of my problems with the PI3 was because of a to small power supply. The camera and USB ports are worky again. The WiFi problem is probably bacause I was at a to long distance from the router. I have moved to a location closer to it and now it works fine. Right arm is also worky now with a servodriver in the lower arm. It drives the 5 fingers, the wrist and the biceps. 

So I moved on to testing distributed processing. I wrote a little about my tests about a year ago and was realy impressed with how easy it was to use. You can find that blog entry here: http://myrobotlab.org/content/headless-head

Continuing my tests, I tried to start an Arduino service, on the host where the listener is. The Arduino was started before the RemoteAdapter. And I hit a problem with serialization. I have sent a no-worky. The problem has to do with serialization of the Arduino service, since it uses DeviceMapping.

23:40:48.685 [HeadRpi] ERROR c.m.f.Service [Service.java:2131] HeadRpi error NotSerializableException - org.myrobotlab.service.data.DeviceMapping java.io.NotSerializableException: org.myrobotlab.service.data.DeviceMapping

In DeviceMapping I find this comment:

// transient too help prevent infinite recursion in gson 
// encoding since Arduino will have a reference
// to itself as a device
transient DeviceControl device;
 
I think this is the part that prevents serialization, but if it's not transient then gson will run into a loop when it tries to serialize the Arduino service. I think that I have hit the same problem in other services too where I had to mark some part transient to prevent this loop. 
 
I'm not sure how to resolve this conflict. Any ideas ? Newer version of gson perhaps ? The current version 2.2.4 is from 2013-05-13 and the latest release is 2.7 from 2016-06-14. Worth a try ?
 
/Mats 

 

Mats's picture

gson 2.7

I tested using gson 2.7 but tha't didn't solve the problem. If I remove transient from Devicemapping I get an infinite loop even with version 2.7 of gson.

Reading about alternate soltions here, but I want to discuss pros and cons before making any changes.

http://stackoverflow.com/questions/4802887/gson-how-to-exclude-specific-...

/Mats