Showing posts with label sensor. Show all posts
Showing posts with label sensor. Show all posts

Saturday, August 31, 2013

Robot Explorer Log 7 Stall Sensor

Mercury tilt switch makes a 1-axis accelerometer
ROBOT EXPLORER LOG 7
DEVELOPMENT OF THE STALL SENSOR

The robot build took on more expansions, from 2 drive wheels to 4, the chassis was extended, sensors were restructured, and getting stuck either on the ice or in the marsh of primordial mud soup on other planets and moons was considered. This has led to the development of the stall sensor.
Parallax wheel has ellipsoid holes for encoding

The question initially put forth on the Parallax Forum here has garnered many thoughtful ideas and very interesting responses. We've supplemented the information with some of our own, and a short analysis about what can work and what can go wrong - Murphy's Law and Yhprum's Law.

HORIZONTAL LIGHT SENSOR
The use of a high mounted horizontal light measuring sensor could detect if the robot is still capable of moving left to right. This may not work on planets with little or no visibility due to atmospheric pollution and various "white out" storms. For example, some planets have dust storms lasting many months while other moons have thick pollution consisting of a mix with visually blinding methane and hydrocarbons. The adjustable and programmable light sensor which can set sensitivity requires three pins.

ENCODED IDLER WHEEL
Also considered is the use of a free spinning idler wheel which has encoding and contacts the ground. If the robot is moving and not stalled, the wheel will turn as it moves along on the ground. The new Boe-Bot wheels have eight holes which can be used to construct a home-made encoder. The encoder consists of a simple IR transmitter receiver pair, one on each side of the wheel. The encoder, because it's made up of a light sensor, could by happenstance end up useless if it becomes covered in mud, dirt, dust or crud. The encoder takes up two pins, one for the transmitter and one for the receiver.

TWO AXIS ACCELEROMETER
A two axis accelerometer could determine the forces of the robot starting and accelerating forward along one axis, and confirm left to right movement along another axis, which would not appear if the robot was held in mud. The accelerometer could also have other functions like measuring terrain slopes and inclines, and preventing robot tipping due to tilt. Since these accelerometers work well in sensitive seismometers, they will undoubtedly work for this application. The accelerometer can perform within an enclosed environmental capsule to maintain proper functioning of its built in heater. The accelerometer takes up two pins.

MERCURY SWITCH
Perhaps the cheapest and most simple approach is to use a side to side (or forward/reverse...) sloshing mercury switch mounted on the robot. This acts as a cheap one axis accelerometer, and can determine if the robot craft is still capable of quick accelerations, i.e. movements left to right, thus proving "it's not stuck" with a returned signal. This would take up only one pin and a small program can poll the status during a short test. This sensor is not effected by dust, atmosphere, or being covered in mud. It can also reside within a temperature controlled enclosure, not exposed to the elements outside. Keep in mind, mercury freezes at -38 degrees F. and boils at +674.11 degrees F. This agrees well with other sensors with a -40 deg. F. operating temperature limit. The mercury switch is a cheap, inexpensive, poor man's accelerometer and takes up only one pin.

UNSTUCK PROGRAM
Ok, so now we know the robot is stalled. What can we do?

The "Unstuck" program will help take care of that. The program is designed to alternate the drive wheels back and forth to generate momentum that should free the robot. This is similar to a stuck car when the driver can alternate putting the car in reverse and forward drive, rocking the vehicle back and forth, and building up enough momentum to break free.

Still stuck? If the planet has changing weather, such as changes in surface conditions, it may be possible to wait and utilize these conditions to better facilitate the "pulling free" process. The unstuck program will be tailor made to the conditions on the planet or moon. Conditions may include a cycle of freezing and thawing, a dust storm, particle rain, wind, temperature changes and other effects.

The Unstuck program requires no pins, however, it will make use of several sensors which require pins. The Momentum Driver remains in software, making use of four wheels and timing.

FANTASY IDEAS
There are some fantasy rescue ideas too:

QUADCOPTER
A tethered quadcopter takes to the air and helps pull the robot free from the mud.

JUMPING
The robot, using spring loaded underside flaps, jumps out of the mud.

SHADOW BOE-BOT & GRAPPLING HOOK
A rescue shadow Boe-Bot flings forth a grappling hook and wenches the robot free.

RESCUE ROPE
A 10-foot rope is anchored to the ground. After Boe-Bot advances 10-feet, the rope/anchor connection is auto-released and the rope is retracted. The robot anchors the rope again, advances another 10-feet and the process is repeated. Should the robot become stuck, the rescue rope is rewound, helping to pull the robot to safety.

NO COMPASS
As the planet may have no magnetic field, a compass cannot be deployed alone.

MAGNETIC SOLUTION
Electromagnets will work in space and on planets without a magnetic field. The Boe-Bot drops a small tethered weighted electromagnet from the front, to the ground. As the robot moves forward over it, the tether unwinds and the rear hall effect sensor detects the magnet, proving the robot has moved and is not stuck. The small electromagnet is retracted and the process repeats.

WIND SOLUTION
If Boe-Bot is on a wind planet, deploying a sail and waiting for wind to help pull free could be a solution. Aligning the sail's force vector with the inline direction of wheel travel could be helpful. Choosing a forward or backward direction for turning wheels can be useful and offers more options. A wind sail program can code the wheels to drive in the direction of the wind sail's force vector. This may need a wind direction sensor. However, a static wind sail will push the vehicle either forward or reverse. Alternating the driving momentum, both forward and aft, can make a wind direction sensor unnecessary.

LINKS
Parallax Forum
http://forums.parallax.com/showthread.php/149909-Stuck-Boe-Bot 
The Element Mercury
http://en.wikipedia.org/wiki/Mercury_element
Yhprum's Law
http://humanoidolabs.blogspot.com/2013/04/yhprums-law.html
Propeller C Activity Bot
http://learn.parallax.com/activitybot

Sunday, August 25, 2013

Robot Explorer Log 4 Light Sensor

Parallax Penguin Robot light system. Credit: Parallax
VERY SENSITIVE ROBOT EYE
ROBOT EXPLORER LOG 4

 

USING THE TLS230 LIGHT TO FREQUENCY SENSOR

A study of interplanetary and moon conditions shows that specific locations will have much less lighting than on the Earth. Even a robot explorer on the Earth can experience dawn to dusk like conditions of less intensive lighting. How does one effectively measure sub lighting conditions?

In the left schematic, the phototransistor or CaS cell will measure the intensity of reflected light. This is good for determining the surface reflectivity of the ground. The top cell can be turned skyward to create a baseline reference. The system uses only 2 pins and is based on ambient planetary or moon light levels.

The schematic at right shows a system that provides the light source, to be shown on objects. The reflected light is detected. This system can be used for obstacle detection and avoidance in dark conditions.

The interest here is in measuring the ground material based on the lighting conditions. The typical IR combo transmitter receiver pair could do detection by transmitting IR light like a flashlight and looking for its reflective signature.

Perhaps a better approach is to read the signature from available light if the probe is operating in known minimal dawn or dusk conditions, and use a more sensitive programmable light to frequency chip manufactured by TI.


TSL 230 R
The program sets the sensitivity level, while two sensor chips, one a reference chip and the other chip viewing the unknown ground material takes readings for analysis. Such great sensitiviy and programming convenience comes at a price, by using more pins. Two chips use six pins. A transmitter receiver obstacle avoidance/detection IR system will typically use three pins.

One good, tried and true, method is that system used by the Parallax Penguin Robot. The schematic shows two systems utilized by this beloved little robot. It's a very powerful walking robot with many applications. The circuit uses RC methods to determine resistance which in turn is based on the level of light.

The Propeller program below is a snippet from the Parallax demo coded by Paul Baker and can be found at the link.




CON
  _clkmode = xtal1 + pll16x
  _XinFREQ = 5_000_000
  pin = 0 'pin connected to tsl230 output
  cbase = 1 'pin connected to S0 (S1 connected to cbase + 1)
  scale = %10 'scale value for tsl230 (=off,%01=x1,%10=x10,%11=x100)
  ctrmode = $28000000 'mode value for counter to operate as a frequency counter
OBJ
  term : "tv_text"
PUB go | old
  dira := %11 << cbase 'set scale pins to output
  outa := scale << cbase 'set scale value
  term.start(12) 'start terminal
  frqa := 1 'set counter to increment by one
  ctra := ctrmode + pin 'start counter
  repeat
   waitcnt(80_000_000 / 10 + cnt) 'wait for 100ms
   term.dec(phsa) 'output counter value
   term.out($0D) 'line feed
   phsa := 0 'reset counter value

Another program variation may be useful, as seen below. This depends on two objects, tv_text and tsl230.

tsl230 DEMO.spin
CON
_clkmode = xtal1 + pll16x
_XinFREQ = 5_000_000
OBJ
term : "tv_text"
lfs : "tsl230"
PUB Go
term.Start(12)
lfs.Start(0,1,10,true)
repeat
waitcnt(80_000_000 / 10 + cnt)
term.dec(lfs.GetSample)
term.out($0D)

AND yet here is another even more simplified demo. These programs were not found in the OBEX but rather on the Parallax Forum along with other code, including an object update by Mr. Degn. (see links)

CON
        _clkmode = xtal1 + pll16x
        _XinFREQ = 5_000_000
OBJ
  term : "tv_text"
  lfs  : "tsl230"
PUB Go
  term.start(12)
  lfs.Start(0,1,10,true)
  repeat
    waitcnt(80_000_000 / 10 + cnt)
    term.dec(lfs.GetSample)
    term.out($0D)


LINKS
Penguin Robot Society PRS 
http://www.p-robot.com/

Penguin Parallax Forum
http://forums.parallax.com/showthrea...061#post977061

Penguin Sticky
http://forums.parallax.com/showthread.php/97288-Penguin-Resources

Penguin Manual with Schematics
http://www.parallax.com/Portals/0/Downloads/docs/prod/robo/27313-6PenguinDoc-v1.0.pdf

Parallax Manual for TSL 230 R
http://www.parallax.com/Portals/0/Downloads/docs/prod/audiovis/27924-TSL230R-v1.0.pdf

TSL 230 R Chip Apps
http://www.thereminworld.com/Forums/T/26460/a-one-chip-theremin

TSL 230 R Sparkfun Source
https://www.sparkfun.com/products/retired/8940

TSL 230 R Data Sheet 
http://www.sparkfun.com/datasheets/Sensors/TSL230R-LF-e3.pdf

Forum Downloads for tsl230.spin & sts230 DEMO.spin
http://forums.parallax.com/showthread.php/117955-TSL230-Program-Question

Bug Fixes to tsl230 Object by Duane Degn
http://forums.parallax.com/showthread.php/148769-Bug-Fixes-to-TSL230-Object-in-Propeller-Tool-Library 

Saturday, October 6, 2012

Tuning Paradigmic Light

Example of Retuned Paradigimic Light by objective count increase
TUNING THE PARADIGMIC LIGHT MACHINE
There are currently several ways to tune Paradigmic Light.

1) Increase the number of objects (stellar in the above example)
2) Increase the limiting magnitude
3) Match the intensity to the proper sized avataric representations
4) Increase the accuracy of placement
5) Use a reference field when working
6) Calibrate and recalibrate the light sensor on multiple baselines
7) Work on the avataric placement of large to small 
8) Engage Accentuation
9) Transport to a different medium