pushed 2 new things inside Inmoov service :
- rollneck servo Inside head ( usefull to use rollneck+neck+rothead into ik+tracking+vinmoov later )
- Eyelids separated & optional skeleton part
 
I need some confirmation about default pin to use
- hacked rollneck : pin 30 - left
- eyelidsLeft( or both eyes default ) pin 29 - right
- eyelidsRight pin 30 - right
 
Added an option to change hardcoded pins :
ex : i01.startHead(port,12,13,22,24,26,30)
todo : others skeleton parts

 

dom14

7 years 7 months ago

Hi, 

May be is it possible to used only one mega ? For my robot, it is works very nice. And used another nano with MrlComm for hand via serial com.

It is just idea.

Dom

hairygael

7 years 7 months ago

Rollneck and eyelids should be ported on head right side. That means we can use the available pins of the right arduino to set rollneck on pin 12 and eyelids on pin 22 and 24. Its very nice and very simple to add if you have the Nervo Boards on both Mega.

The other pins that you were considering will be used for the legs diy servos.(if possible for a simple configuration) But legs is still another story...

About rollneck inside inmoov service, I like the idea to set all servo from the head using the same arduino.
To follow the logic of all independent inmoov services. And simplify dev things.

I01.moveHead(neck, rothead, eyeX, eyeY, jaw,rollNeck)

or

I01.moveHead(neck, rothead, rollNeck)

So simple to use and understand ! Of course we can map rollNeck to an other arduino

Is your last word JP ? :)

( I like your other story, new book to write, so great book )

@dom thank , of course all is possible and like you say plug X servo to 1 arduino is worky, but we are using standartised bom electronics ( input + output ) based on associated services from long time ago. And lot of people use this bom. We cannot break all,first priority at this time is stabilize things for the next release.
maybe an other day evolution for all ? ( i2c etc ... )

Yeah, the InMoov services needs some revision to expand it's possibility. But as Anthony said, first priority is to fix things so builder that follow the bom can have it worky.

The current implementation is great for initialization following the BOM as everything could start with a single command (i01.startAll(leftPort, rightPort)).

But at the same time, this way is a bit stiff and just changing the default BOM limits and you need to contorsionate for the setting.

My view on this to keep that way, but also add alternate way of initializing the InMoov. Like attach(inMoovPart, Servo). That way requiere more manual initialization (starting the servo outside of the InMoov service) but can open up the possibility to use servo connected to any controller (raspi, adafruit16c, etc) and remove the need to have servo connected to a very fix set controller (like head must be on the left side arduino)

It's on my plan to do something that way, but the list of things I want to do is long and things get add on it faster than what I can do, lol

 

 

Yes i like Calamity idea for manual initialization to choice servo controler.

Put all servos in 2 mega, ok it is easy but i think it is not a good idea for all inmoov.

For DIY servo to controlling legs on the same mega right and left request a strong computer, with strong power supply...it is not good for autonomous InMoov.

My view is one arduino (DUE for example) to controlling legs and accelerometer and communication with MRL.

Dom

I also agree with the suggestion of Calamity, it will enpower possibilities to expend. But as I see it, its been almost 4 years that I wait to have a working release as good or even better than the version 1.0.107.

-voice control (only sphinx)

-vision tracking

-kinect working

-pir working

-servo posittions and speed working with all servos even during during tracking.

 

All the versions that were released since 1.0.107 couldn't do these fonctions, there was always something broken.

I strongly would like to have something working and fixed before things get deeply refactored again. We are close to have it ready for hundreds of users.

The number of users working with the Nervo board building a complete InMoov (2 Mega boards) is way over a thousand builders. If we create a i01.HeadLeft and a i01.HeadRight, they all could just plug the extra servos in a few minutes but it implies a refactoring.

We, humans, have two brainsides, it makes sense...

:)

Considering the leg, using the extra free pins on the two mega board, is a simple solution to progress for now. Currently during my test I use these pins for the legs with gyros.

But it's for sure, when we will need to calculate movements with accelerometers, we will need expension. As Dom and Vincent suggest, calculating PID on some extra Arduino coupled with accelerometer.

I totally agree with you Gael, that's why I use the latest stable version (LAMIAK) because the serial ports with MrlComm 55 does not work.
 
I see that MRL get bigger and bigger without having a real version finalized and especially stable and without bug.

As I said, one arduino Due could drive the 12 motors PID needed for legs. maybe it will need a new service "serial-arduino-servo" which recieve MRL positions command via serial and compatible with integrated movement

 

It's time for powered legs !

 

Vincent.

I understand the frustration of having bugs in the way. And I really wish we had a bug free software.

The thing is that we are not a lot of contributor and like everyone around, we all have our personal goal and schedule. Every contributor do their fare share of work on the project for fixing bugs and do request to add functionnality. Unfortunatly, it's no one job to do all the bug tracking and fixing. 

Complaining that e develop things and that some bugs remain is not really helpful

Last mrl core is very impressive about performances and stability. I m not afraid at all about next services like a leg service.

"service "serial-arduino-servo" which recieve MRL positions command via serial and compatible with integrated movement" I think I saw a thing like this one day : mrlcomm :)

And if we are afraid to dedicate a complete computation unit to whole robot, the little friend "Remote adapter" enter in the game. we can dedicate why not a linux standalone unit to do some important computation? everything will work out in the end

I will awnser tonight about work based on initial question, it was just a pin question

I see it, stable inmoov powerded by mrl it is not far

time to polish

GroG

7 years 7 months ago

Change is potentially both improvement and disruption.

I believe now the core group is aware we are "all" wanting a release.  

Not only did MRL change, but AcapelaSpeech and other cloud providers have changed and broken things.

We have a very clear strategy for dealing with this in the future.

Right now all new changes should be to satisfy the the requirements of  worky:

  • voice control
  • vision tracking
  • kinect working
  • pir working
  • servo positions and speed working with all servos even during tracking
  • virtual InMoov (thanks Calamity !)
  • packaged self-contained InMoov scripts inside of myrobotlab.jar (thanks Moz4r!)
  • beginings of solid integration junit tests for each build to preseserve Workyness (thanks Kwatters!)

Resistance is Futile !

GroG

@ Calamity, I really do not intend to complain, only worried to see things refactored when we are so close to a worky release.
It's like building a castle with cards, it feels awful when it collapse with the last card. And I know what I'm talking about.

Summer 1977,  I was 12 years old:

Let's polish a worky release!

 

 

I'm setting the InMoov service.attach()/detach() as Deprecated and add the enable()/disable() method for consistancy and wil review a bit the code to be sure everything goes in that way

I want to add theRollNeck to the vinMoov, but I will need some help. On my inMoov I used 90 degree rotation servo so I don't have the full range of movement. I need to know when the servo is at Max or Min range, how many degree (real angle) the head tilt toward the side. If someone can give me the answer it will be easy to add to vinMoov (It's already there, I just don't know how to translate servo position to head position)

moz4r

7 years 7 months ago

Hi Christian great idea ! on my Inmoov, full range is 5 > 138 (mg996r).

In the future I think we will us ik to control the head ? because it not easy to compute standardized head position with those 3 servo ( exemple "look at the sky" , if rothead is on the left.. ) an other thing to think about lol

The idea is to have a line representing where the robot is looking at, and control the line direction for the position of the head. 

What I really need to know is when your servo is a 5, or 138, how many degree did the head tilt.

 

The way rollNeck servo are mounted, the servo value probably dont correspond directly with the head angle