Robot arm: feedback sensory (Skutter v0.2)

Some new components arrived today



The  funny looking thing with two lenses on it is a "Sharp IR Range finder" , accurate from 10 meters to 10cm, which I will come back to in a moment.

The tiny tiny tiny little black rectangle with little copper squares around the edge is a 3 axis +/- 2G accelerometer.



There is another item ordered which is currently out of stock, which is a second IR Range finder which is accurate from about 1mm to 10CM.

I am planning to use the two range finders mounted on top of the robot grippers. They are going to give the skutter / arm mounted on motorized base robot a sort of sense of sight.

The range finders fire a pencil thin infra-red beam at an object and then another sensor receives the reflection as the beam bounces back from the object.

This method is very reliable in that, as long as the pencil thin beam hits an object, the receiver will get this and will give an accurate measure of the distance from the sensor to the object.

The drawback is the beam is pencil thin, so if a thin object like a chair leg is just slightly off angle from the direction the sensor is pointing, the robot will not see it.

To get round this, I'm planning to use a kind of panning and scanning method where the arm will rotate on it base by a tiny fraction and then fire off a "ping". Something a bit like this (except without the de-materialisation)

This will require some further accurate feedback from the base to report back what angle the arm is pointing in.

The teeny tiny surface mount accelerometers are going to pose a challenge.

The idea with these is, like the g sensor in a smartphone, as a by-product of being able to measure acceleration they are also able to detect what angle they are at in relation to Earth's gravity. So, theoretically, by mounting them on the different sections of the arm they should be able to feedback where each arm segment is in space (with a bit of help from Pythagoras (geometry))

Their actual operation should be very simple, but their sheer tiny size (I didn't realise just how tiny they were going to be) are going to make them extremely difficult to work with using only amateur's tools and methods.

More on this later as currently there isn't sufficient time to devote to this but there will be in three weeks or so. In the meantime, if anyone has any experience with using surface mount components but with hobbyist tools, please chime in

If those accelerometers work out for angle measurement this is going to be great.  Much less hassle than messing around with encoders on each axis. (Though you might still need encoders for the base rotation; that's probably a separate project in itself.)

I used to have access to an old PUMA robot set up in a corner of a university lab... a big boy's robot arm... I loved playing puppeteer with that thing on open days and the like.  (Exceptionally cool with the tool coordinates set up, but I'm going way off topic.)

By the way is that Sharp a GP212 or whatever?  Some of those models have an analogue voltage out, which means they need an A-D converter to read.  (I once built a bedside lamp that you could switch by waning a hand at it - PICAXE based.)

looks good - I assume you're planning to interface these via gpio on the raspi.

for the arm joint feedback (since the wiimote+ir led approach is a bit impractica ) I was thinking of small pots attached to an A-D convertor

accelerometer (digital output)

Distance Sensor 10-80cm

(Oops, where did I get the 10 meter idea from? 80cm seems to be the maximum for this particular range of devices; at least where it's under a tenner)

80cm is still a useful detection range but now I need to think about long range vision as I have short and medium range sorted.

Distance Sensor 10cm

The distance sensors are analogue devices.

From the datasheet for the 10-80cm range finder:



Examine the first graph. Firstly this shows that at distances of less than 10cm (actually about 6 cm, but 10cm is manufacturers specified value) the device will return a false reading. So for example a 2cm distance will cause an output of the same voltage as about 28 cm distance.

This is why we require a second, shorter range device that will be able to verify whether an object is closer than 10cm. If it is beyond 10cm the short range device will have a lower voltage output than the long range device (because the object will be out of the short sensor's range) that will then enable us to trust the long range value.

If the voltage from the short range device is higher than that from the long range sensor, we will know that the object is closer than 10cm and we will be able to trust the short range sensors voltage reading.

As the two sensors use the same IR frequency they will interfere with each other, so we will need to fire a ping from one, and then the other alternately.

[edit - adding more info]

There are two methods for using the output voltage to determine the distance.

Either use a look up table, where I:-

(step 1) experimentally determine the voltage by manually measuring distance from an object and then using the sensor and measuring the voltage.

(step 2a) Make a table of distance v voltage, and programmatically look up the distance at run time.

Or alternatively, repeat Step 1

(Step 2b) Draw a graph of distance v voltage. Work out the equation of the line on the graph. Program the robot to use this equation to determine distance.

SN said:

I was thinking of small pots attached to an A-D convertor

I was thinking of that for measuring the base rotation. If the accelerometers don't work out I'll try that for elbow, shoulder and wrist as well. The down side is they might be bulky but they should give effective measurements of angle nevertheless.

Mental note - I also need some sort of conductive foam for the grippers to determine pressure. (Where when the foam is not compressed the distance between two electrodes is 'far' and resistance is 'high' but when the foam is compressed the distance is 'close' and resistance is 'lower')

Apparently there are shorter and longer range versions of the Sharp sensors: see

http://www.robot-electronics.c.....ngers.html

Also the steep part of the curve allows you to measure up close (I read this somewhere on one of the robot forums) though only if you already know you're close... because one reading corresponds to two distances.  Bit of a bodge but apparently it works...

There are also ultrasound sensors at the above site.  I have a few, but haven't got round to using them so can't say if they're any good.  Range should be long though.

Have you decided what you're gong to use to read the analogue out from the IR sensor?  I gather the Raspi doesn't have A-D convertors built in, but an arduino or something would probably do it.  (My picaxe one was OK but might not be fast enough)

Oh by the way I occasionally had trouble with the Sharp (though I had an earlier version than any of these) - it just turned out I needed more decoupling capacitors on its supply.

morphy_richards said:

conductive foam for the grippers to determine pressure.

QTC pills perhaps - I've seen these but never had an excuse to try them.  Don't know how rubbery they are though, that is whether they're suitable for use drectly on the gripper's fingers.  Reliable wiring might be a bit tricky too!

Gripping force can in principle be measured by measuring the current through the gripper's motor as it closes.  I suspect this is only usable with high-quality motors and the right sort of gears though.  "Robot compliance control" might be the right sequence of buzzwords (I haven't looked at any of this since the early '90s).

SN said:

I assume you"re planning to interface these via gpio on the raspi.

Yep. Trying to get my head round how that will work given this information. Here is the GPIO Wiki

8 GPIO pins (as well as 2 UART, 5 SPI which can also be reconfigured as GPIO) means I have 15 I/Os to play with.

I"m not too familiar with what UART and SPI actually do yet, some of these might be more useful to the robot in their intended mode rather than being reconfigured as GPIO but 15 bits of input / output doesn't seem like a lot a lot. Unless I get a Gertboard I will need to come up with ideas for something that can encode values from 2 (possibly 3) distance sensors, 3 accelerometers, one potentiometer.

It will also need to drive 2 motors individually on the base, either forwards or backwards. Speed control would also be nice.

It also has to tell the 2 (or possibly 3) distance sensors to ping.

It would be nice to have some redundancy in case we come up with some more sensors or other kit that the skutter robot can be equipped with.

All with the GPIO. Will it be possible? I"m sure it will.

morphy_richards said:

Im not too familiar with what UART and SPI actually do yet

The SPI connections are actually quite useful. Serial Peripheral Interface is a widely adopted standard that allows several devices to be addresses independently on the same bus. So for example you could have a number of SPI enabled A/D IC's connected to a single pin and each of them could be individually addressed without the need for extra GPIO pins. If you want more GPIO's you can use a SPI IC that will give you several GPIOs from a single SPI connection.

... I do like the arduino a2d idea, extra advantage that it gives me something I can actually do until a Pi turns up.

One option for expanding the usability of the GPIO would be to use a PISO (parallel in, serial out) chip to serialise a load of digital inputs. I'm doing this for another (arduino) project where I have an arbitrary number of sensors/values (actually reading counts from a number of counters where I don't want to use the arduino to watch for signals, just to report the counts by polling the counters at appropriate intervals.) and I detect how many items I have by setting the high bit high (so reading 7bits/chip instead of 8bits) and daisy chaining the PISOs. Then I read till I get a high bit 0 and I know that I have read to the end of the chain.

That could provide a pluggable and extendable sensor interface requiring no more than three GPIO pins for as many digital sensors as you like. The downside is the time to read the data serially which may or may not impact your application.

Going the other way you would use a SIPO (serial in, parallel out) to do the same thing in reverse.

..d

@davidman & Darren, thanks for the info re GPIO. That's already starting to shape my ideas for how this will pan out in the future.

@Ravenous; the sonar is a great idea too, especially as it's kind of low-res, as it were, it can be used to detect objects like legs walking too close & enable the robot to take evasive action.

A down side is most of the sonar sensors I've seen are in the order of £20. I'm trying to keep the cost of this down as much as possible with the idea in mind that smart kids could go out and have a go themselves and with that in mind hacking and bodging pre-existing cheaper gadgets, toys and lower range components seems to be the way to go to me.

Having said that I just came across these two little beauties:

Ultrasonic reciever

Ultrasonic transmitter

(cost of both together under a fiver)

Which we can check the data sheets for and then chuck on the mental equivalent of the back burner to stew for ideas for a while.

I just chanced on this website which does a complete 6m range working rangefinder module for £12

Directed Sonar Sensing for Mobile Robot Navigation by John J. Leonard at MIT 

In chapter 1.1 "the navigation problem" (the weekend experiment)

"At 5:30 pm on a Friday night, we power-up the robot in an arbitrary

starting position with a blank memory|i.e. no a priori map. We tell
the robot \use the next few days to travel at your leisure around your
environment to make a map of the accessible space on this floor of the
building, without harming yourself or the environment." We turn on
the lights and leave. On Monday morning, we return to find the robot
back at its starting position, ready to execute commanded trajectories"

[...]

"To our knowledge, this test is beyond the capability of any robot in existence

today, using any sensing modality"

That smacks of a gauntlet being flung down! A challenge!

Ok you got me here !!!! the Software defined radio part of the forum.

My Welding shop fights combat robots. So we have an extra tank drive robot waiting for its brain. I just found the this servo controller the: Micro Maestro 6-Channel USB Servo Controller (Assembled)  to drive the DC motor controllers, and our pan tilt head, like simple hobby servos.  Judging by the conversation the RPi has IO directly on what pins? Or WHATS the Pin out on the first 100 that have been made?

So I can attach optical encoders to the wheels. Im the Rover BOT with GPS, we are trying to send it to the corner store for BEER... The robot has been sold bag of chips.

If your classes designed USB device suppling all the power to the gyro and Range finders on a PCB. 5v? So all they would need is to wire over to the RPi headers. Or make a USB sensor packs out of an Arduino . write an Arduino to mount as a custom usb device that feeds the sensor data to the RPi when plugged in.

Im Using ROS, sorry Ive been looking at cameras.

http://www.ros.org/wiki/Sensor...../Cameras 

Mathison

sold

kj6dzb

Trying to summarize what you said to see if I understood.

Your welding shop makes combat robots. You are making a robot at the minute from some parts you have that you want to be smart enough to get shopping?

Your suggestion of designing USB interfaces for the sensor modules and then patching to the GPIO in due course is interesting. How much do you know about designing USB equipment? From what I have learned this can be quite complicated with things like device ID's needing to be issued and variations in voltage levels etc.

You are investigating using video and GPS and there is something called "ROS". (What's ROS? The site looks like some sort of wiki/open source robot community)

Looks interesting!

How far have you got using video with robotics?

morphy_richards said:

"To our knowledge, this test is beyond the capability of any robot in existence

today, using any sensing modality"

That's a 1990 PhD thesis

There's newer stuff.  There's a 1996 e-book "where am I" (search for that and the authors names Borenstein and Everett).  Might be old now but has a (very) long survey of the available technologies and ideas at the time, and is probably still readable.

And a list of the main author's papers here, all downloadable I think:

http://www-personal.umich.edu/.....papers.htm

I haven't done a search for this stuff in years, but I'm sure there's other new stuff.

Also have a look at http://www.showusyoursensors.com/ there's some localisation & mapping stuff on there, though I think they use a lidar rather than sonar.

The tiny accelerometers  have been giving me a headache trying to work out how I'm going to use them. My soldering skills and my patience just are not going to be up to the task. The advantage of them costing 70p each (or thereabouts) just doesnt kmake up for sheer fiddliness and this video fills me with fear!



As an alternative, there are loads of "Arduino Accelerometers" listed on ebay at about £3/£4 each. The downside of this is that it would add about £15 to the total cost of the robot instead of about £3.00.

Who knows about reflow soldering and surface mount? What can I do to bodge something that would just about get the job done?

This video is really interesting...



And from the youtube comments, apparently if you have a chisel soldering iron you don't even need a hot air gun.

Has anyone ever tried anything like this?

… and if I got my PCB and component and did like the above video but put it on the base of an upturned iron, would that work?

[edited because that just sounded silly]

...or perhaps not on the base of an iron; clearly the heat wouldn't make it through the PCB to the copper very well and would be uneven as well.

Made a bit of progress regarding adding feedback for rotation of the arm shoulder. I found a large (physically large) 1K potentiometer that was being chucked out by Science. It's been sitting around gathering dust and waiting for a purpose for a while and I realised that the shaft is about the same size as the shaft that in the shoulder that rotates. I prized off the casing and managed to extract the piece of board with resistive track on (and realised why it was being chucked out - looks like it was connected to some sort of HT power supply that fused the track at one end. Never mind it's still useable but it's no longer a potentiometer, its now just a variable resistor).( I may replace it if it turns out to be unreliable as a measurement device.)


So, basically as the arm rotates at the shoulder the "brush" moves along the resistive track and resistance changes. I can use this with a fixed resistor to make a voltage divider and that can then be converted to a digital value by an analogue to digital converter which can then be used by the Raspberry Pi GPIO.
It's a bit wonky from time to time, I need to add something to ensure the brush continually makes contact with the track (you can see the effect of this if you watch the video below here) didnt get anymore time to fiddle as I had to leave to go for dinner with the Inlaws. Next thing to do is test this with an Arduino to act as an A2DC and see if I can specify exact angles to move by.

http://www.youtube.com/watch?v=vVyfEYL0GCA
{edit - managed to get images to show as thumbnails in posts again but I cant work out how to embed youtube video }

I connected the rotation sensor to the analogue input of an Arduino and then used the serial.writeline() command to create a CSV file. The CSV file shows time in intervals of 100 mS and the "analogue value".

I then manually rotated the arm using the proprietary software (starting at the leftmost angle and rotating to the rightmost)


Looking at the graph plotted from the CSV file it looks like this method has some potential but there has been a problem around 3500 mS, 1400 mS and 18900 mS - it looks like a kind of mechanical issue where the contacts in the sensor are shorting out as it rotates. If I can fix that issue I think we should be in business.

Assuming that I can fix the shorting out issue, the next step would be to make a table of the value from the analogue input and the angle of rotation. I should then be able to plot that and create a function that will allow me to accurately specify an angle for the arm.

Knowing the base angle will then allow me to start experimenting with IR rangefinder that's attached to the claw / gripper. Assuming I keep the armat a fixed height I will be able to plot the value from the rangefinder against the angle of the arm. That would allow me to do a kind of sensor sweep, if I put an object in range in the arc of the arms sweep and see if it would be able to detect it.

Why do you want to use that pot, because it fits the arm well?

Looks like the slider's coming off occasionally - maybe some switch cleaner or WD40 might help? Also if you repeat the experiment several times do you get the same shape every time?

Another way to measure rotation is to put an optical encoder in somehow (I remember finding a link about this somewhere) and keeping count of the rotations. Might need a separate device to count them though, which adds more expense.

Industrial systems apparently use resolvers, which are precise and probably massively expensive and complicated. (I've heard of them on a course, never had the chance to play with one though.)

I will repeat the experiment - I'm squashing most of this stuff into lunch breaks so keep rushing through things...

That's exactly why I'm using that potentiometer - it's a snug fit. Also, apart from prizing the potentiometer apart it's a really simple operation to fit it to the arm. I haven't used an optical encoder because mechanically it is a lot more involved. That instructables optical encoder mentioned previously somewhere method would take hours to do.

You could be right about the slider thing - every now and then you hear a sort of "crikking" noise as the slider / brush does something unpleasant inside the arm so I was wondering if that could be part of the issue. Poor thing.

I may need to go back in there and solder on an improved 'brush' as well. (Still easier than opening up each gear box and drilling holes and then carefully positioning optoelectronics)

Also - with the encoder method I'm not sure how I would be able to determine where the arm is to begin with... I mean I would be able to accurately judge how far it moves but I don't know how the arm would be able to say "I am here". With a varying resistance you that that as an absolute value.

Repeated experiment.

Forward then back again this time ...

Ok that wasn't so good. The big gear wheel continually jams against the pot terminals and after a few back and forth rotations it breaks the thing.
How about this as an idea... Print out a disk which kind of gradually increases the black level as it goes around. Ie it starts as white and gets greyer as you go round it. Fix that to the non moving bottom. A small enclosed LED shines down and a small photoresistor that are both mounted through the rotating big gear thing picks up the reflected light fromvthe graduated grey disk..? That should also be small enough to use on every joint of the arm, not just the base.
Edit - fix the gradually greyer paper disk to the moving part and fix the optoresistor / led unit to the none moving part to prevent mechanical failure.

that would make it more suitable for the mag too, as its less destructive