Hello all! I have been following the InMoov and MyRobotLab projects for a couple years now. This was the main reason I bought a 3d printer and I started with a hand and forarm. Then life got busy and I took a break for a bit. Since the beginning of the year I have been plugging away on the head, torso and shoulders.
Before I start with my topic, I wanted to send out a thousand thank you's to everyone who has contributed to these two communities. Gael (@hairygael) has been an amazing thought leader with all his creative designs and community support. Greg (@GroG) has built out a massive code base that provides the underlying framework to enable development which bridges the gaps between the digital and physical worlds. I see a lot of great work currently being submitted by Kevin (@kwatters), @astro and many others. However the list of contributors over the years is far too long to call out individually. Thank you all for your dedication, curiosity and patience. You have all made this world better.
Now to bring it back on topic, one of the design decisions I have been focused on achieving is to keep the various components somewhat isolated with their own PCA9685 servo controller. This design is similar to @ray.edgley. This will simplyify the wiring throughout the body and will help improve isolated experamentation with each significant component (head, left arm, right arm, torso). I have had no issues with getting the components connected and individually managed through MyRobotLab.
My challenges begin when I try using some of the aggregate services like InMoovHead as that seems to have a strong opinion on how the servos are connected. Since my background is build engineering, I happily jumped into the code and started tweaking to eliminate the hardcoded dependencies on particular named controllers (i01.left) and instead provide my PCA9685 (headdrvr). Although I seem to have some success, I keep finding implementation nuances that seem to be different between the Adafruit16CServoDriver ServoController implementation and the Arduino ServoController implementation that seems to be causing some issues. For example, when the onServoSetSpeed() method is called from the Adafruit16CServoDriver it seems to be setting the velocity attribute on the servo pulled from the servoMap. However in the Arduino implementation, it appears to put a message on the bus with the new speed that is interpreted by MrlComm (still a little fuzzy here).
I am happy to keep hacking my way through here, but I wanted to throw my current status out there in case there were any fundamental flaws in the way I am thinking about this problem. If I am heading in the right direction, I will send a follow up post once I have something fully working with all the necessary code changes. I'd be happy to submit a pull request upstream if that would be helpful as well.
Thanks!
Ahoy hewjoe ! And Welcome
Ahoy hewjoe ! And Welcome !
Thanks for posting :)
Nice progress you've made there. And you can always compare with me, I've been working on this project for 7+ years with Gael and others - and as of yet... I still have not built an InMoov. So in a way your light-years ahead ;)
For the PCA9685 topic .. Oh My ! Perfect timing. "Manticore" - the previous release of MyRobotLab did not support non-Arduino controllers. You can bet "Nixie" (https://www.patreon.com/myrobotlab) the release we are working on will ! Kwatters and I have just finished a big refactor of the Servo service - and I, after reading your post got my PCA9685 servo controller out - and will be attaching it to my raspi.
I believe Mats had this working in Manticore, but it was as you mentioned, incompatible with InMoov.
Without "real" hardware I usually cannot help very effectively, but I do have these ! (I think Ray might have sent them to me..)
If your interested to follow along - most of the activity will be on the "develop" branch or myrobotlab.
Your welcome to clone, fork, examine, comment, or contribute in any way you wish.
I'll keep your post updated with my progress.
My setup initially will be with a raspi 3b +
http://myrobotlab.org/content/work-e-has-grown-antenna
http://myrobotlab.org/content/work-e-watchdog
http://myrobotlab.org/content/emoji-service-preview
Thanks GroG for the quick
Thanks GroG for the quick response! I am currently building off the develop branch of the project and will plan to continue to do so. I am encouraged to hear this is in line with the direction you wanted to take the platform.
My approach so far has been fairly brute force to achieve worky. I would then be able to isolate the meaningful changes into something cleaner which could be contributed back. As it will take me some time to absorb the whole ecosystem, it is somewhat of a scatter shot at first.
I like the idea of having RasPi driving the system and have a few spare Pi 2, 3, 4 hanging around to play with. It has been a bit mixed results in my experience as Pi's threading can cause some lag where Arduino does one thing really well. We may find that a PCA9685 with a feather on its back would provide a cleaner USB interface for the Pi as compared to I2C directly from the PCA9685. I don't know what I expect for results, but the problem tells me I need abstracted connections. I'm pretty sure I see all the primatives in place for this.
I will keep you all posted with my progress. As you mentioned, these fun projects tend to take much longer than you originally expect. I keep reminding myself it is about the journey and not the destination. I had a lot of fun with the kids putting on all their old halloween costumes on the robot. We all agreed that Captain America looked best, but there were quite a few others that brought out different personalities in the bot.
Hmm Feather ... I've glanced
Hmm Feather ... I've glanced at this before - but didn't really think about its applications
https://www.adafruit.com/product/2928
Hmmm so you think raspi i2c communication get disrupted more than its serial ?
I'm usually keen about removing code and hardware when possible - small "directed" systems are typically a lot easier to trouble-shoot.
I am currently building off the develop branch..
Excellent ! You appear to speak with a Software-ese accent...
are you a code-slinger by trade ?
I'll be trying direct rasp3b+ --direct--> PCA9685 --> Servo route first, we can compare results
I have some web ui and other work to do with our RasPi service also.
What hardware is currently connected for you and captn A?
The stability of USB over I2C
The stability of USB over I2C for multiple (4) PCA9685 is still unknown, but I have run into issues before with choppy performance when I tried migrating multiple neopixel light strips from Arduino to Pi. It also required a higher level of maintenance as it would sometimes not start, or stop which required that I logged into the Pi to troubleshoot and reset. Since the application was a hands off lighted staircase for my parents, I eventually moved back to Arduino which did its 1 job really well. I keep this in perspective as I look at new projects.
I like the WORK-E project you have! I did something similar last halloween with a 24V Razor dirt quad being re-purposed as a mobile base. At the time, I attached a skeleton frame and chased the kids using lynxmotion PS2 wireless remote, linear actuator for steering, some relays for power and polarity, and a DAC to manage the throttle. I had reused the original controller, but now that you pointed out the sabertooth motor driver, I may have to upgrade. It was a fun project, but I would eventually like to use it for some real SLAM/self-driving fun.
My background started in systems administrations with a lot of development mixed in over the years. I tend to lean more towards interpreted languages like Perl back in the day and Python more recently. However I am comfortable with Java and C variants. These days I build end to end development pipelines in AWS with all the DevOps goodies. I was happy to see the Jenkinsfile in your project :).
For reference, I currently have the following assembled and working independently in my InMoov.
Next step is to get interactive using the InMoov services, which has led me to some hacking.
WOOHOO ! I have gotten
WOOHOO !
I have gotten Joystick not only to run on the RasPi. I need this because I need a joystick to control the wheelchair base - now with a RasPi brain.
There were many problems initially getting this to work. First, we did not have the proper arm7l native binaries (since this interfaces hardware). I tried using libraries from the raspian repo - but these are jinput natives on a very old version of jinput ... they did not support all the features of my joystick.
I went to https://jinput.github.io/jinput/ .. cloned the repo, built the binaries, then loaded them into a package and published it @ mrl's repo here http://repo.myrobotlab.org/artifactory/myrobotlab/jinput-natives/jinput-natives-armv7.hfp/2.0.7/
In order to get myrobotlab.jar to install the correct binaries from the repo to the raspi, mrl needed to identify it was running on a raspi, then use that info to download the correct binaries.
It did correctly identify the RasPi when it started, however, it used the wrong service dependencies and grabbed the wrong binaries FAIL ! :(
The problem was information was being packaged in myrobotlab.jar during build time and it would package the information of the build server platform. FAIL :(
With some hacking I removed the build process which embedded incorect platform info in to the jar, to force myrobotlab.jar to query platform info during "runtime". It "tried" to query, but in order to do so it ran into a chicken egg bootstrap problem .. and exploded. FAIL :(
I realized the issue would require a re-design of a getMetaData() function and a whole lot of busy work. I discussed the re-org with guru-kwatters ... made a plan and after lots of work.
BOOYAAAA !
This is my Logitect Wireless RumblePad 2 working on the raspi, viewable through the webgui.
YAY ! \o/ WORKY !
The big ass pr is here https://github.com/MyRobotLab/myrobotlab/pull/715
It looks like some tests are failing - so that will need to be addressed, then kwatters will need to review, and at some point it will be merged into the develop branch.
After that, if not redirected with a squirrel, I should be able to look into PCA9685 Servos from RasPis
Adafruit16CServoDriver
Hi
Over the years I have tried many different configurations of my InMoov. To my experience the RasPi works well for simple tasks. But when it comes to image processing, speach and speach recognitions it's not the best choise. I currently use an Intel NUC for those parts and a Raspberry PI for the head and one for the body. A bit overkill now since both are only driving servos thru PCA9685, but my original intent was to only use two Raspberry PI's and no PC. I'm currently not using any Arduino.
I use 4 PCA9685. One in each arm, one in the head and one in the body. All are connnected directly to a RasPi. The main logic is on the NUC and I send servo movements to the RasPi's using the Service API
http://myrobotlab.org/content/myrobotlab-api
All computers run their own instances of MyRobotlab.
Using i2c thru an Ardoino is slower than connectng it to a RasPi, since all i2c command are sent over the serial interface,
Using a Feather board compared to other boards would just limit the number of servos you can connect to each board, The PCA9685 supports 16 servos, but the Feather board sets the limit to 8. However it should work without any software changes since it's the same IC.
My InMoov has been resting for a long time now, and I'm working on other projects, so I have not been very active here for a while.
/Mats