I'm going to be wiring up my inmoov in a week or so and I'd like to do it to 2.0 specs. A while ago it looked like Alessandruino convinced Gael that inmoov could be run with a single Arduino Mega instead of an Uno and a Mega. Is this the plan for 2.0? If so have the pin assignment been made for the entire inmoov on the Mega? For example the servo pins for the fingers on both the left and right hands. Maybe I'm confused about what the differences are between InMoov and InMoov 2.0. Anyone care to explain where 2.0 is going?
Thanks, Drew
Hi Drew.. I don't think we
Hi Drew.. I don't think we are going to move the whole inmoov on a single arduino mega board... The "standard" will be a UNO + 1 MEGA... The difference between inmoov and inmoov 2.0 is about the structure of the service... Now inmoov 2.0 is splitted in various services (head, hand, shoulder ecc..) ... Another difference is reguarding extra servos ( eyes and jaw at the moment) : they will be attached to the mega ( originally we were tinking to use a i2c board for controlling them) in old inmoov jaw was on the uno and eyes had not a good pin assignment)...
I suggest you to use pin assignment in the inmoov page, because it will work with both old inmoov and inmoov 2.0 since the only difference is about jaw and eyes... (eyes are not used in old inmoov)...
So you could use old inmoov until 2.0 is relased, then you'll have just to move the jaw from the uno to the mega and attach eyes to the mega...easy !!!
Let us know if it was clear as mud :)
Alessandro
P.S. : here is Inmoov page with pins assigment http://myrobotlab.org/service/inmoov
Thanks for clearing this
Thanks for clearing this Alessandro. I'll go with the dual arduino setup for now. At some point I may branch out and use i2c boards. When one starts adding servos for waist, hips, legs and feet that ends up as a lot of wires. Some with pretty long runs. Of course there's always jhack's method of placing small arduinos in the appendages.
Drew
Ale summed it up quite
Ale summed it up quite well.
Just a few things to add.
inmoov.getRightArm().getShoulder().setRest(39);
this is not quite ready yet - we need testers and cooridation
Ah, it get curiouser and
Ah, it get curiouser and curiouser...
I wish I knew more about Java. In c++ I would do something like having default constructors that did the standard arduino and pin assignment using default values for the arguments. For example:
InMoovHand::InMoovHand(Arduino a, int thumb=2, int index=3, int majeure=4, ringFinger=5, etc)
This way I could use two arduinos via
leftHand = InMoovHand(mega)
rightHand = InMoovHand(uno)
Or a single arduino via
leftHand = InMoovHand(mega, 2, 3, 4, 5, 6, 7)
rightHand = InMoovHand(mega, 42, 43., 44, 45, 46, 47);
This way we can still have default pin assignment for the servos but they can easily be overridden.
As for moving the servos at a given speed I guess one could send new commands to the i2c board anytime the position needs to change. Although that might be too heavy a load on the arduino.
The software side is definitely going to be fun once I get enough stuff put together.
Drew
I was a C++ developer before
I was a C++ developer before switching to Java - most of it is very similar, but initialization like that is not allowed in Java. At the moment there are simple methods like head = startHead("COM10")
All the defaults are set in that function, but ALL defaults are easily overridden by getting the part(s) your interested in.. head.getNeck().setPin(5) Other utilitarian starting methods can be created depending on need.
Really the board type has very little use. Graphically it displays more pins when board type is Mega .. but programmatically it should allow any pin values to be explicitly set.
The board type really is critical only when uploading a board sketch, and I am very interested in ripping this out of MRL and letting the Arduino IDE do all the uploading. There seems to be a lot of confusion in that area and some of the code I lifted from the Arduino IDE is not stuff I would want to keep.
As for the I2C stuff - I'm thinking about it in the context of a micro-computer (RasPi, Odroid, BeagleBoardBlack) being directly connected to I2C - with no Arduino in-between. Its possible to send I2C commands directly from these small computers - but it would be on a thread and subject to interruption/sleeping - which is not so important depending on the speed of the computer and the I2C task involved - the task we are interested in InMoov is moving a servo at a slow but smooth speed.
Using mega and uno was a poor
Using mega and uno was a poor choice on my part.
I was really trying to distinguish the difference between using a board that had more limited i/o that couldn't support all of the InMoov servos vs. a board that had more i/o that could support all of, or at least a lager part of InMoov.
+1 on moving the uploading to the Arduino IDE. For me uploading was the most difficult part of getting into MRL. Also you wouldn't have to chase all the different variants of boards that keep popping up.
I took a look at MRLComm.ino and am going to try implementing code that sends commands to the adafruit board instead of banging on servo pins directly.
I'm not sure that banging servos directly on a micro-computer wouldn't also be subject to the same interruptions as using i2c. Unless there's the ability to move the servo speed ramping into a realtime task it's still subject to the machine getting busy with other things.
What's your opinion on the way the servo speed control is handled now in MRLComm? The way it's implemented, speed is pretty indeterminate depending on what else is going on in the Arduino. Setting speed to something like 70 would yield different results on a faster vs. slower machines. I could look into tying the speed stuff to something like the internal clock or event interrupts.
Too little time, too much fun stuff to do :-)
Drew
Adafruit board is already
Adafruit board is already supported..
http://myrobotlab.org/service/Adafruit16CServoDriver
the MRLComm.ino is dynamically modified in order to support it - that's one of the reasons I've kept Arduino upload around so long.. but at this point I'm thinking it might be more worthwhile to create a large monolithic sketch with all possible dependencies (Servo lib / Ping / Adafruit Shield / Adafruit Servo driver lib / etc...)
I2C -
On a micro-computer it would be subject to interruptions.. that's why I said, "it would be on a thread and subject to interruption/sleeping" - but depending on the speed of the computer and the specific I2C task (moving servos smoothly and slowly) - this might be negligable.
not much should be going on with the Arduino - the sketch is designed to be a slave. It's point in life is to relay commands from MRL or send back data - no "real" processing.. each pass takes the command from MRL if there is one - and does it - then checks for any expected return data ... even polling data from pins it only polls from ones selected at the time - it will never read data which is not expected to be returned
Sure, you could look into changing MRLComm... but as I mentioned I'd be most interested into making it work monolithically more than anything else
EXACTLY - too little time !
I2C > microcomputer - subject to interruptions....
Hey peeps
Happy New Year
I realise that this is an old thread but I thought I'd add some info to the mix, in case it's not already known
For the multi core Raspberry Pis at least there is the capability to allocate a specific cpu core to be dedicated for specific tasks
So, for example it is possible to dedicate one core on a quad core Raspberry Pi 3 in order to solve the problem of thread interruptions
I've seen this demonstrated here (see around about the 5 minute mark)
I'm no expert, but from what I'm seeing in the demonstration, I believe that this solves the thread interruption problem, at least on the quad core Raspberry Pi
Any thoughts....?
Hey Grog, Happy New Year, did the problem for I2C servo speed control get a solution ? :)