New Paint Scheme

I haven't done an update for a while most of the activity with Robbie has been

trying different parts and arm designs between Hector and Inmoov as always there

are pros and con to each design. Inmoov has more activate development so the larger

part of Robbie is Inmoov. The main problem with the Inmoov design was the lack of

shoulder pan joint ROS moveit needs some form of pan joint for the kinematic solvers

to find a solution after trying different joint configuration Inmoov with the waist pan

joint worked just as good as Hector. Hectors biggest down fall was the gearbox the

worms slipped under heavy loads and the back lash was very high. I still have 2 of

these gearboxes in the elbows so i will have to fix that at some point

On the software side I have made large improvements in localisation and navigation

Robbie's ability to go through door ways has improved to the point where navigation to

any place in the house is possible. Using behaviour trees he constantly monitors the

battery if the battery is low he auto docks with the charger and will continue with the task

after charging is complete.

Robbie's arms are controller by a Adruino Due the pull up resistors need to be disabled

use this link https://raw.githubusercontent.com/bluesign2k/Arduino/d8d6d62853a5308c21b95dad4bdd64e358e857cc/hardware/arduino/sam/libraries/Wire/Wire.cpp

To mark the change from hardware testing back to robot development I have changed the colour

scheme to black and gold. I dont intend to change the design but rather improve what I have

The focus will be more on software and operational use

Harmonic Drive Update 3

Well I found some time to work on the harmonic drive the other day. I achived
about 5.8 Nm of torque reliably during testing the drive slipped when i applied a
17Nm load. When I examined the drive i found  the wave generator was not
forming the flex spline correctly I upgraded the drive to use 2 608 bearings but still not working as good as i hoped. After a bit of research i found a better wave generator design using a elliptical plug and a thin wall bearing the challenge was to design it in CAD then print it after a few tries I had a wave generator that worked at high speed and wouldn’t slip. My test drive is not up to the task of
testing so I need to reprint the whole thing again . Instead of using a gear motor I want to use a Nema 17 stepper motor and fit the encoder in the side. Below is the steering actuator from omni_bot2

Below is my latest wave generator, the flex spline is printed in nylon and is holding up well the print quality is bad with the teeth being a bit smaller then they should be

ROS Smach

After trying to get smach to work for a while I finally have a working program that
I'm happy with. Smach will now monitor the battery level when the voltage goes
below 11.8 volts Robbie will say he's hungry and navigate the charging station
and then using auto dock  to complete the drive. Robbie will then charge for a set
time then return to health monitoring mode.
Future upgrades will preempt any running navigation task and will stop the charge mode when the battery is full

Arm update

Earlier while running moveit and the Inmoov arm i noticed the object pick up
looked looked strange and i had a limited range where the pickup would work.
The shoulder looked like it needed a pan joint after changing the simulation with the extra joint pickup improved a lot. So i changed the real arm grafting a pan joint on to the inmoov arm proved to hard I had played earlier with the arm out of hector robot but i didn’t like the pan setup and the lack of tilt in the shoulder so i came up with this design the gearbox has a few problems like backlash in the gears the worms are weak and keep breaking (due to the backlash ). The lift joint
all the forces push the worm down the motor shaft loosening the grub screw.
The motor drive plate will need reenforcing because it bends due to the forces applied.

The good news is that ros Moveit works Robbie can pickup a object and place in another location(in simulation) I need to understand the grasp generator better
for a better pick up the performance of pickup  is dependent on the grasp

After a bit of thought the Inmoov arm will also work

Voice Recognition

Voice recognition under Linux is a pain, but then under windows it never worked very well. After a bit of playing around i found that the voice recognition program is not the problem but the quality of the sound that we feed into the voice recognition program, there is back ground noise, motor noise and other voices have different pitch(women and kids)so its no wonder the results are poor. The program hark has the features required all it needs is a microphone array. The kinect seems like it will do the job, But getting the microphone to work under with linux is the problem libfreenet only works with older kinects and only on some ports Robbie has 2 kinects a older one for navigation mounted low to the ground  and a newer one for face tracking mounted in his head. Before I can can move to the next stage I have to swap them over just sapping the leads over results in no microphones found. and swapping them will mean removing the mount from one and adding a bracket to the other

Dueling Chatbots

I wanted to test Robbie's chat engine but I was to lazy the type the questions so I
set up another chatbot  and had to 2 talk together the result was amusing to say the least they chated away for 5 minutes before one of them crashed, The biggest problem was they answered the question then asked one of there own which became 3 then 4 then 20 answers plus a extra question . Next time I try it the response will be limited to the last 2. The chat engine has been intergrated into the AI now  if i send a unrecognized  request it will go to the chat engine

Arm Encoders

Moveit is running nicely but the real arm and simulated arm have a different angle at first I thought it was just calibration  and the lack of rigidity in the system
it ends up it's all of the above and the potentiometers that i use for encoders. The potentiometers are linear types but they are not true linear there is a small variation in the angle to signal which can be up to +/- 6 degrees the start, end and middle being accurate. There is not much point in fussing with calibration with that much error. I have 2 choices magnetic encoders or a look up table for the angles, the encoder will be for a later date so for now I'll use a look up table. For the rigidity and smoothness of operation bearings are the only way to go. Using the fake robot in Rviz shows that a extra joint in the shoulder gives better performance  I  will try and add a shoulder pan joint to Robbie

Robbie's arm moving

Here is a video of Robbie moving his arm to random points selected in RVIZ I have cut out the planning stages they can last up to 10 seconds for complex solutions.
Robbie can drive to a selected point
move his arm to a selected point
that leaves grasping  then the butler is online
"Robbie get me a beer"

ROS Movit

At last I have ROS Moveit working, after writing the action servers it all came together. The simulation mode is great for testing learning to use it will be a challenge. I did have one problem that cause me a headache for a while. The simulator worked but when it came to using a real robot it failed the problem was you have to modify the demo launch file not just use move group launch. The demo launch file you remove static transformation and the robot state  publishers.
I still need to tune the joint angles and reduce the error in movement to the required angle. Its very interesting to watch Robbie move his arm and avoid obstacle's  in his way.
The next challenge is to recognize a object and pick it up move it. That will require a Kinect but Robbie’s kinect is too low to be of use. So I stuck one in his head a Asus camera would be better as it's smaller but the jinect was only $30 against $300 for the Asus. It makes him look strange once every thing is working we will have to do a redesign not just on the head but also the arms.

Elbow Mod update ver 3

After a some testing I found the version 2 of the elbow mod to be lacking
when power was removed to joint sagged when power was applied the joint would snap into position after a few day trying to control the joint the plastic started to fail. The arm was tearing it self to pieces the solution would be motor breaking and velocity control. Another idea is to use a worm screw gearbox but the original Inmoov gearbox is not suitable but the  Hector   robot has a gearbox that would work with some modification I had some parts laying around from a previous idea
they wern't of good quality and  I didn't have enough filament to reprint or the bearings required so i made some PLA bushes. Not wanting to use a motor and controller I opted for the standard servo with feed back. The good news is it works
and I have nearly 160 degrees of rotation the servo handles the load fine but the feedback is a little jittery later I will change the servo with a motor and the feedback will be solved. the elbow pivot is a little high. I want to do some testing with the complete arm before i reprint the parts. What i really need to know is if the arm can reach and pick up objects for a table. The original hand is very limited
so I replaced the hand with a claw, the arm now has 6 DOF  and a gripper all with feedback and controlled through action servers. Of course that brings in it's own problems as the joints have to get to there goal with a high degree of accuracy before moving on to the next goal.

Robbie Navagation Test Smach

Running with the action server was one goal but using ROS smach and the ability
to use multiple goals  or way points to get to the target was always the plan
in the attached video shows Robbie moving in a triangle to achieve a target.
Next we are going to add arm actions to the routine

Autonomous Navigation

Robbie's first autonomous  navigation run the goal is navigate through a door
in this run the door is 110cm wide but getting through was quit hard. A lot more work
will be required adjusting the parameters. Robbie has a habit of spinning in place trying
to find a solution. The cost map and size of the robot have a large bearing on behavior

Here is a picture of Robbie in Rviz showing the gap after the infatuation of the cost map 

when there is no clear path through,  the robot will spin in place to find a clear path.

now the fun starts learning to drive  by setting nav goals

Robbie the cartographer

Finally received the new encoder disc's after fitting them the problem of erratic
reading changed side after 3 days of work the encoder are running well. The main cause was the disc was not aligned and running true, the axles are only threaded rod
which gives a little movement i put a layer of tape around the rod and every thing started to work as expected.  That doesn’t mean there are no more problems, after adjusting the encoder counts Robbie was again running straight  but long for a 1 meter move he went 1.16 and for every turn he over shot by 22 degrees. Once i examined the data the distance travelled in real life matched the distance and angles
in his localization, the extra distance came from deceleration when i have a spare day I will adjust the PID loop to be more responsive.  The deceleration issuse will not impact navigation to much so the first task was to make a map.  To my surprise the maps were the best best we have ever achieved they still need a lot of work for them to be perfect (we are using a kinect not a laser scanner) before we can do long range navigation. Robbie was able to navigate in the garage with out crashing into the walls the localization on the map was good. Over the next couple of days I want to run more navigation test and a few videos I want to see how he goes up the ramp and through the doors. I will need to work out a good position for the arms just hanging down is not good the hand can get caught on object.