Latest robot project – A desktop social robot

I have been working on a new robot project for the last few months.  I like desktop robots and having read about social robots like Jibo and Buddy I decided I would like to try and create a low cost version of one of these that can sit next to my computer and maybe interact with me and my children. I wanted to try and design some more complex components for 3D printing and thought that this project would be a good opportunity. I decided to give FreeCAD a shot as it looked like a promising open source 3D design package.  After negotiating the expected learning curve I was impressed with the range of functionality that FreeCAD has and I was able to design some cool looking parts for my new robot. The idea was to design a desktop robot with a display and a camera integrated into the head and use servos to pan and tilt the head to enable to robot to look around the room. As the project progressed, as is often the case, it evolved and the robot ended up with an extra servo that enabled the head to roll as well. I wanted to incorporate an accelerometer into the head to track its position and went with a cheap MP6050.  For the display I used an adafruit 2.2″ tft screen that I have used in previous projects. I had a webcam, that I stole from my mobile robot that I mounted in the head as well. I also used this project as an excuse to learn how to use kiCAD for pcb design. I used this to design a shield for the arduino mega to interface all of the sensors and servos.

Below is a picture of the finished robot.

Social robot

Social robot

I was particularly pleased with the lettering on the bottom servo housing, easy to do with FreeCad. I was also pleased with the bracket that connects the roll and tilt servos, as shown below.

Roll to tilt head bracket

Roll to tilt head bracket

The accelerometer mounts to the head and, using this library, is able to spit out roll, pitch and yaw angles.

MP6050 mounted to head

MP6050 mounted to head

After some calibration I have been able to control the servo positions using the accelerometer readings very reliably. A simple control loop for each servo is all that is required to position the head at any combination of roll, pitch and yaw angles.

I have a lot of work to do on the software, but I wanted to share the project now that the mechanical and electronic build is complete. I was going to use the raspberry pi for this project but I have decided to use my desktop computer for now, but I may decide to use the pi at a later date. Previously I was driving the tft screen from the pi but I am now writing to the screen from the Arduino. The screen will display a face, probably just simple shapes for now, to allow the robot to display some emotions.

I am also planning to design a robot arm it some point, and I would like this robot to be able to control the robot arm. I am thinking of possibly having a few modular parts, like arms or other sensors, that can work together. I am not sure how this will happen at that moment but its fun to think about.

Come back soon as I hope to have a video of the head moving around and controlling its position up here when its working.

 


 

Advertisements

New battery and some design revisions. BFR4WD MK2

Work was progressing with BFR4WD and I was experimenting with software for object/landmark recognition as well as developing BFR-Code for controlling the robot. However, I started having problems with the old NI-MH battery pack I was using to power the servos.  It wasn’t holding its charge for long and the servos were constantly struggling to move the robot. This battery pack had sometimes struggled to deliver the current required when all the wheel servos were working hard when it was working well. I decided it was time for a new battery. This led to a succession of design revisions and many parts of BFR4WD have been redesigned and rebuilt.

Lets start with the choice of a new battery. I looked into the various options available  and settled on a 6V SLA battery to power all the servos. SLA batteries are cheap, easy to charge and able to supply a lot of current if required. The downside is that they are heavy! During the original design of BFR4WD I made the decision to gear the servos to increase the top speed of the robot at the expense of torque to the wheels. This was fine using the previous battery but the additional weight of the SLA battery means this gear ratio would no longer be suitable. I decided to redesign the drive train for each wheel so that the required torque could be delivered. This meant designing some more 3D printed gears with a ratio that increased torque at the expense of speed. I ended up with a 20 tooth gear attached to the servo and a 24 tooth gear on the wheel axle.

I used this redesign as an opportunity to review the design of the wheel encoders as well. Whilst the previous design worked well, the encoders were mounted in a place the meant most of the robot had to be dismantled in order to adjust, repair or replace them. Looking into various options I settled on sticking with an optical encoder but instead of a slotted disk I would use a printed pattern. This design involves printing the encoder disk pattern onto transparency film using a laser printer. A slotted opto-interrupter looks at this disk and switches depending on whether a printed line is present or not. The final design ended up with the patterned disk attached to the servo gear meaning I could also do away with the third gear/slotted disk of the previous design. This has the advantages of fewer parts to print, fewer holes to drill and fewer moving parts. This all adds up to a simpler design which is lighter and runs more quietly. The picture below shows an encoder disk mounted to the servo gear.

Encoder disk

Encoder disk

With the alterations to the gear ratio and the new design for the encoders I was also able to increase the encoder resolution from 180 pulses per revolution to 218.

A redesign of the encoder circuit was also required and I decided to use Sharp GP1S093HCZ0F opto-interrupters. These devices are very small and allow a very compact encoder to be built. A test on a breadboard allowed me to find the correct resistor values to use (10K and 220 Ohm) and test that the device could read the encoder disks as required. The pictures below show the breadboard version and the final encoder circuit which was built on stripboard.

Encoder circuit on breadboard

Encoder circuit on breadboard

Encoder circuit

Encoder circuit

To allow the new design drive train to fit in the aluminium box section I’m using to house it, I had to space the servos off from the box section by 3mm. I designed and printed a spacer that would hold both of the servos required for one side of the robot chassis.

Servo Spacer

Servo Spacer

A 3D printed bracket was designed that would mount the encoder circuits in the correct position and allow for some adjustment. These encoders are mounted in the centre of the chassis rail as opposed to the ends as in the previous design. This configuration makes them a lot easier to adjust. Shown below is the finished encoder arrangement mounted in the chassis.

Mounted encoder

Mounted encoder

This encoder design and gear configuration also meant that I could reduce the overall size of the robot. This design is now 40mm shorter in length but 10mm wider. This has the advantage of setting the wheels closer together along the length of the robot but spacing them further apart across the width of the robot. This helps when the robot is turning on the spot.

I had to fabricate all new chassis parts to fit the new design, one of which is shown below.

Chassis rail

Chassis rail

The picture below shows one of the chassis rails with the servos, gears and encoders mounted. I reused the end joining pieces from the previous design. I also changed the bushes that the axles run in from a push fit design to ones that glue into place.

IMG_1608

Due to reducing the overall size of the robot and the addition of a larger battery, space on the chassis to mount everything had decreased significantly. I was forced to start building upwards! I designed some 3D printed stand-offs that would allow me to mount another sheet of HDPE above the first, as shown below.

3D printed stand-offs

3D printed stand-offs

This meant that the two batteries could sit on the bottom layer which allowed good access to the connect / disconnect power to them. The Raspberry Pi, Arduino and USB hub could go on the top layer, again giving good access to connect to them. I also added a compass module to the robot. A CMPS03 that I have had lying around for a long time.  I designed and printed a mount for the compass and used a length of aluminium box section to raise the compass into the air. My experience is the further the compass is from any other components the better as it reduces interference.

The picture below shows the completed robot. So many things have changed with this redesign I think this will have to be referred to as BFR4WD MK 2. Initial testing confirms that I have much more torque at the wheels due to the change in gear ratio and better current delivering capacity of the battery. The encoders are working perfectly and I have increased resolution meaning more accurate positioning and speed control. The compass works and will be used for navigation. I am very keen to try some more map building using a mobile robot with the addition of data from visual images.

BFR4WD - MK2

BFR4WD – MK2

3D printing a new robot

I was very pleased with the way BFRMR1 turned out, but it had some design flaws that I needed to address. The servos used for the drive wheels were a bit too slow. The drive wheels were positioned near the centre of the robot to help limit the size of the turning circle, but meant that the robot would tip forwards when stopping. It also meant that I couldn’t mount anything to the front of the robot, such as a gripper. Wheel encoder resolution was also a bit limited. An idea started forming in my mind for a new robot.

The idea was to make a four wheeled robot, with each wheel driven independently. I wanted to stick with using servos to drive the wheels. I love servos. They are cheap and very easy to control. But they can be slow! My idea evolved to making a gearbox to speed the servos up a bit, whilst taking the hit of losing a bit of torque. However, for this new robot it wouldn’t matter too much as I was doubling the number of drive wheels.  I thought of several ways of gearing the servos. Drive belt and pulleys was the first option but I decided to go for gears instead. I could have bought the required gears but I thought that this project was as good an excuse as any to invest in a new piece of equipment, a 3D printer!

After a bit of research I decided on a prusa i3 printer bought as a kit. I painted the aluminium frame and after a few days and a couple of long nights I had my printer assembled and working.

Prusa i3 3d printer

Prusa i3 3d printer

After calibration and a number of test prints, I set about designing some gears to form a gearbox.  I used OpenSCAD to design all the parts for the robot. To design the gears I downloaded a gear generator from thingiverse http://www.thingiverse.com/thing:3575. I started with a 25 tooth gear that would be connected directly to a servo horn, then a 14 tooth gear that would be connected to the wheel drive shaft. Attached to the 14 tooth gear is a 45 tooth gear with a finer pitch to drive an encoder disc with a 14 tooth gear attached. All of this together would increase the top speed of the servo and give me an encoder resolution of 180 pulses per wheel revolution. It took a few tries to get each of these gears right and some of the prototypes are shown in the picture below.

3D printed gear prototypes

3D printed gear prototypes

With all of the gears designed I made a trial gearbox. I wanted to use aluminium rectangular box section to house the gearbox. This means all of the gears are hidden and contained and also means that the gearbox could form a part of the robots chassis. The prototype gearbox just used a short section of the aluminium box as a test. The picture below shows the gearbox from the end with the encoder disc nearest the camera.

Prototype gearbox

Prototype gearbox

The final gearbox design used a long length of aluminium box section with two servos attached and two gearboxes within. This would form the drive for one side of the robot. Access holes were cut into the box section so allow assembly and adjustment of the gearbox and the picture below shows the view into one of the access holes. You can see the two servos mounted with gears attached and the drive shaft passing through the box section with its gear attached. The encoder discs are hidden.

One completed gearbox

One completed gearbox

I also designed and printed some bushes for the drive shaft to run in that clipped into holes drilled in the aluminium box section. The hole through the middle of these is slightly undersized so that they can be drilled out to exactly the right size for the shaft to fit in.

3D printed bushes

3D printed bushes

The encoders consists of a 28 slot encoder disc and a photo-interrupter to detect each of the slots as the disc turns. I decided on using sharp GP1A52LRJ00F slotted optical switches. These have photologic outputs so only a minimum of external circuitry is required to interface these with the Arduino. In fact only one resistor is needed so I used stripboard to make four encoder circuits that were then mounted inside the aluminium box section with the encoder discs turning between the sensors.

With two gearbox/chassis sections made I had two sides of the chassis. To join these together and make a complete chassis I needed to design some brackets. These brackets attached aluminium box section cross members to the gearbox sections to make a rectangular chassis. These are shown in the picture below.

Chassis bracket

Chassis bracket

One feature I wanted for this robot was the ability to separate the electronics and sensors from the chassis easily. To achieve this I decided to mount the Arduino mega, the Raspberry Pi, the batteries and the USB hub on a sheet of HDPE plastic that would then be bolted to the chassis with four bolts. Should I need to work on the chassis in the future I could just undo these four bolts, disconnect the encoders and drive servos from the Arduino and remove the electronics board. I also decided to mount the head pan/tilt mechanism to this board as well. The picture below shows the chassis with the electronics board attached.

Assembles chassis and electronics

Assembled chassis and electronics

The head pan/tilt mechanism consists of two regular servos and some 3D printed brackets. The picture below shows the bracket that attaches the pan servo to the electronics board.

Servo bracket for head pan/tilt

Servo pan bracket

Attached to the pan servo is the tilt servo via another 3D printed bracket. I designed a further piece that fixes to the tilt servo that the head can be bolted to, all shown in the picture below.

Head tilt servo bracket

Head tilt servo bracket

The head of the robot houses a sonar sensor and a webcam. See the picture below showing the assembled head attached to the pan/tilt mechanism.

3D printed head

3D printed head

With all of this done the robot is almost mechanically complete. I need to design and print some mounts for two IR sensors that will probably mount to the electronics board either side of the pan/tilt mechanism. The other job to do is to design and print a housing for a small screen and some buttons for controlling the robot without having to connect to it with another PC.

BFR4WD almost complete

BFR4WD almost complete

I have been developing software for the new robot alongside the mechanical build. I have modified the wheel control loop software from my previous robot to now control 4 wheels at the same time. A lot of the software from the BFRMR1 can be used in this project but one thing that I knew needed work was the communications between the Arduino and the Raspberry Pi. I was using serial communications but I never really liked the protocol I was using, that I developed so I can’t even blame anyone else for it. I am sticking with serial comms but wanted an improved protocol. Inspired by G-code as used on 3D printers I decided to come up with my own protocol to send commands in the form of strings to the robot. I’m calling it BFR-Code for now! The basic idea is that movement commands or requests for data can be sent to the robot along with some data to determine how to move. So a move command string will start with a capital letter M followed by a number to determine the type of move and then any data required proceeded by a capital D. So the command M1 D200 would drive the robot forward 200 encoder ticks. Error codes and data can be returned to the Raspberry Pi in a similar manner. This whole thing is a work in progress and I will make a blog post in the future with full details if this works out well.

For now I am continuing work on the software but I am near to making a video of the robot in action so check in again soon!

Carbon Fibre shell for BFRMR1 mobile robot

As mentioned in my last post, I have been hoping to have a custom carbon fibre shell made for my robot for a while now, to replace the aluminium shell. That time has come! I have a friend who has been making carbon fibre parts for a while now and he kindly offered to make a part for my robot. The first step was to create a model of the part I wanted, which I did myself. I used styrofoam (blue) to create a model of the shell of the exact size required. I used hot glue to stick several bits of styrofoam together to give me a rough shape.

Rough shape styrofoam model of robot shell

Rough shape styrofoam model of robot shell

This was then shaped by hand using sandpaper to leave the final shape required. The shaping involved rounding the corners and ensuring the top of the shell was as smooth as possible.

The finished styrofoam model of the robot shell

The finished styrofoam model of the robot shell

At this point the styrofoam model was given to my friend who spent quite a bit of time getting it ready to use to make a mould. This process included sealing the part with epoxy resin, covering it with body filler and sanding it to shape and several coats of a special resin designed for pattern making that can be sanded and finished to a high standard. A mould of the part was then made that could be used to make the carbon fibre part. The carbon fibre part was made and given to me ready for fitting to the robot.

I completely dismantled the robot to allow the new shell to be fitted. I had to round the corners of the base plate to match the rounded corners of the shell. I fabricated some angled brackets to attach the shell to the robot, which were fixed to the shell with epoxy resin. I had to cut the carbon fibre shell to accommodate the head servo, the TFT screen and an access panel at the front and rear. I fabricated some additional brackets to hold the access panels on to the shell, and also attached these with epoxy resin. To protect the lovely shiny surface of the carbon fibre shell, I cocooned it in masking tape before any cutting or drilling took place. With the shell finished I rebuilt the robot, mounted all the parts to the shell and fitted the shell to the robot base. Take a look at the finished product!

BFRMR1 with custom carbon fibre shell

BFRMR1 with custom carbon fibre shell

Close up of the carbon fibre shell

Close up of the carbon fibre shell

Side View of BFRMR1 with  carbon fibre shell

Side View of BFRMR1 with carbon fibre shell

Switch array mounted to new shell

Switch array mounted to new shell

I am very pleased with the look of the robot with the carbon fibre shell and it is very tough. The other advantage is that the shell is now very light. I weighed all of the aluminium parts of the old shell that I took off and they weighed 750g. The carbon fibre shell weighs in at 260g. This is a considerable weight saving, especially for a robot driven by modified servo motors and should reduce load on the servos and extend battery life.

I have also been working on the software for the robot. I have modified the way the Arduino and the Raspberry pi interact and I have tried to move some of the real time processing to the Arduino. As such, the Raspberry pi now sends commands to the Arduino, via serial, to instruct the robot to carry out a particular movement. This could be move the head to a given position or drive forward/turn a certain distance. When the move is complete the Arduino then returns a packet of data containing up to date sensor readings. On top of this the Arduino is also monitoring the sensors as the robot moves, detecting potential collisions and stopping the robot if necessary. The Raspberry pi can inspect the returned data packet to check if the robot moved the required distance and if not, check which sensor triggered and act accordingly. This allows much more accurate control of distances moved and sensor thresholds to stop the robot and frees up the pi to do other tasks if required.

I have also been playing with the TFT display, nothing particularly special at the moment but I can switch between modes and start and stop the robot using the buttons, and display the status on the screen. Some pictures below.

Mode select displayed on the TFT screen

Mode select displayed on the TFT screen

IMG_1534

Status displayed on the TFT screen

I am currently improving the obstacle avoidance code and working on some basic behaviours for the robot. One of which, as shown above, is finding food mode. My idea is that the robot will search out objects of a certain colour which it will identify as food. It will then navigate to the object to satisfy its hunger. Other modes such as play may involve the robot looking for a ball or similar object. When I am happy with the obstacle avoidance mode of the robot I will make a video, stay tuned!

BFRMR1 build complete

This robot came together very quickly. This was partly due to the fact that I had all the parts I needed already and partly due to this design being a relatively simple one. From my last post to having a robot ready to test took about 3 weeks. Since then I have been modifying software from my humanoid robot for use on a mobile robot. The parts that needed fabricating for my new robot included a base plate to mount everything to, new brackets for the wheel servos and encoders, a bracket for 3 sharp IR sensors, a mounting plate for the Arduino and a new pan/tilt arrangement for the camera and sonar sensor. I wanted to use 40mm castors at the rear of the robot as I have found these to roll really well on carpet. This lead to possibly the trickiest part of the design. I had to raise two sections at the back of the base plate to mount the castors to so that the robot was level and didn’t have a huge ground clearance, which may have made the robot look odd. The picture below shows the finished base plate, painted black.

Finished robot base plate

Finished robot base plate

The other brackets and components were fabricated and painted black as well. I decided to modify two servos for use in the head pan/tilt arrangement. I wanted to get a signal from the internal pot to use as feedback of servo position. This involved opening the case of the servo and soldering a wire to the centre pin of the internal potentiometer, which can then be read by the Arduino via an ADC. I knew that this would not be as accurate as using an external potentiometer as I did with my humanoid robot but I was willing to make this sacrifice at this stage to simplify the mechanical design of the pan/tilt arrangement. With all the parts ready for assembly I took a picture of all the components laid out because I’m sad like that and I think it’s cool!

BFRMR1 components ready for assembly

BFRMR1 components ready for assembly

The next task was to assemble the robot. I also needed to make and attach encoder disks to the wheels. These were designed on the computer, printed onto card and glued to the wheels. The assembled robot is shown below.

BFRMR1 ready to roll

BFRMR1 ready to roll

Another view of BFRMR1

Another view of BFRMR1

I still plan to make, or have made, a cover for the robot to hide and contain all the wires and electrical components. This is a work in progress but testing and software development can still continue on the robot as it is.

At the moment I am still testing and modifying software to display data from the robot on a screen and control the robot manually from either a PC or the Raspberry Pi. My goal with this robot is to have several modes of operation that can be selected between. For example; obstacle avoidance, wall following, colour tracking etc. This is very much a work in progress but when I have something working I will make and post a video. That’s it for now, back to software!

Arduino shield and tidier wires

If you have read some of my previous posts you will know that the state of the wiring on my robot has been causing me distress. It’s not that the wiring was causing issues as such, it’s just that I knew there was a better way of doing it. My design had the Arduino board mounted on the base with many wires connecting it to an interface board mounted on the rear of the robots torso. The better way to do it would be to use a shield that connects to, and sits on top of, the Arduino and mount the Arduino to the rear of the robot torso. So I set about designing and building a shield to meet my needs.

I started with a template made by someone else, no use re-inventing the wheel. I used the one found here http://circuitfun.wordpress.com/2012/01/02/arduino-mega-shield-template-in-eagle-improved/, which I must say is very good!  I then added parts to meet my requirements. I added connectors for all of the servos, connected to the PWM pins. I also added connectors from the ADC pins to interface the potentiometers, with a few spare should I wish to connect anything else at a later date. Connectors from a few digital pins allow sonar sensors to be connected as well as the hand switches. As a bonus I added the servo power switch circuit to the shield so I could do away with the small separate circuit that was performing this task. I then completed the board layout and fabricated the board.

Having completed the board and tested it I would say it was a worth while project. I have got rid of a load of wires from the rear of the robot and cleared some space on the base of the robot. I did have the batteries slung beneath the base which I didn’t like, so these have moved to the top of the base. All in all, this set-up is much tidier and this makes me happy. The picture below shows the Arduino and shield in situ.

Arduino and shield mounted to the rear of the robot torso

Arduino and shield mounted to the rear of the robot torso

Encoders

I have been doing some testing on my robot, in particular the wheels. I noticed, as expected, that the wheels do not turn at the same speed even when given the same command. This is a common problem and means that the robot does not drive in a straight line. The problem is even more evident when the robot is driving on carpet, as the rear castor takes a while to straighten up, meaning the robot drives on a curved trajectory. The solution to this issue is to add wheel encoders.  I have designed and built encoders in the past so I had a pretty good idea of what was required. I once designed an encoder that fits inside a servo housing, replacing the original electronics. The servos motor could be driven via a motor controller, as you would a normal motor, and the encoder would give feedback of the speed, allowing closed loop control. This design used an infra-red reflective sensor shining onto one of the gears inside the servo which had alternating black and white stripes painted onto it. When combined with a schmitt trigger, this set-up gave a series of pulses, the frequency of which was proportional to the speed of the motor. I didn’t want to use this exact design on my humanoid robot. I didn’t want to modify the servo to run as a normal motor as more hardware would be needed in the form of a motor controller. I decided to use a variation of the design but with the encoder external of the servo, shining onto the wheel itself.  The resolution of the encoder would not be as good doing it this way but it was a sacrifice I was willing to make.

I decided to use the QRD1114 sensor. This is a popular sensor and is used for line following robots quite a lot. It can detect the difference between black and white surfaces, due to the way the IR light reflects or is absorbed by the surface. I wanted to incorporate a schmitt trigger into the design to ensure the output of the encoder is a clean, square wave. I have designed and build these in the past using a comparator and a bunch of resistors. However, after some research I found a buffer chip that will do the job without any external components. The part number is SN74LVC1G17DBVR. It’s a tiny, surface mount chip, perfect for the job. The circuit schematic for the encoder is shown below.

Encoder schematic

Encoder schematic

I designed the board for the encoders and fabricated them. For the wheel I needed a disk with alternate black and white stripes printed onto it. I designed the pattern, using  Inkscape and printed it on a laser printer. I cut out the design and glued it to the wheel. I mounted the encoder so that the IR sensor was shining onto the striped pattern. I cut slotted holes to mount the encoder to allow for adjustment. The pictures below show the encoder mounted on the robot.

Side view of encoder mounted to robot

Side view of encoder mounted to robot

Encoder aligned with the wheel

Encoder aligned with the wheel

This set-up gives around 40 pulses per revolution of the wheel. I have connected the signal from the encoders to an external interrupt on the Arduino and set it up so that an interrupt occurs on a change of state. This means the count is incremented every time the encoders sees a change from black to white or vice versa.

I am happy with these encoders. The resolution is not brilliant but is more than sufficient to keep the robot driving in a straight line. I have written a control loop for each wheel, just proportional control at the moment, to keep the wheels spinning at a constant speed.

excitingtechnology.net

Facts and Thoughts on Technological Progress

Turing's Radiator

Pleasantly Warm Topics in Computational Philosophy

Mind the Leap

One small step for the brain. One giant leap for the mind.

Steve Grand's Blog

Artificial Life in real life

jimsickstee

Hi, I'm Jim. Read what I write and I'll write more to read.