The PROBLEM: lower ball unit contains a spherical bot that contains lots of batteries and "level" weights but sometimes can not STOP fast enough
Drive a spherical bot as fast as you can (one with lots of extra batteries and ballast lead weights) then tell it to STOP on a dime. I get at least one toggle flip using worm drive motors, or just a lot of drift with just geared down motors. It would be nice to overcome the problems of plain physics here.
For those that are interested
The two part Styrofoam ball from Michaels was great in absorbing impact, so much so that it is now dead. That's alright because it forced the upper / lower unit to communicate via RF to obtain commands and indirectly orientation.
As the ball bot comes over an obstacle you get some unwanted acceleration, sometimes flipping around the motor unit housed inside the two part Styrofoam lower unit (held together with duct tape, so you can take it apart for battery charging). This lead to mis-orientation forcing the system design to institute a policy of checking upper unit / lower unit orientation check (upper says go forward and then determines the lower unit orientation based on how the upper unit needed to correct for balance). The problem was when you had the next obstacle so close that determining orientation was incorrect due to "climbing over effect" (more post obstacle acceleration / banging).
So since we now have a THREE comparison balance system we can accept the temporary impulse NOISE due to the "climbing over effect".
So I've moved over to a two part MEGA LARGE (13") PLASTIC RAT BALL from petsmart (you can also find them on the web cheaper). This ball has slots allowing for the reactivation of the THREE node IR communications sub-system. This is three bidirectional IR's picaxe-08M2 modules mounted near the wow-wee tri-bot wheels, and three bidirectional IR's picaxe-08M2 modules mounted at 120 degree spacing on the lower motor unit. This allows faster orientation determination between the upper and lower units. Each picaxe-08M2 has a IR tx led an a 38khz IR rx receiver. The stamps do not need to stop what they are doing for communications now, they just get a signal "tap" from the 08M2 module when something has arrived.
Now the bad part:
-The Styrofoam ball (when completely taped around the center of the seam) could actually make it through SAND and low WATER environments (even though the sand can get up into the tri-bot wheel bearings). This was impressive (NO VIDEO, just test environment). BUT the water could not be too deep as to float the system, or too long as to coat the ball making it too slippery (still need friction) for the tri-bot upper unit.
-The MEGA ball has slots, great for IR communication BUT REALLY BAD for SAND and WATER.
Maybe the slots in the MEGA ball might provide an interface for that Death Star weapon, will put this on the very END of the want list.
-Bowling ball - great for low Center of Gravity (CG) but does not provide enough friction surface for the tri-bot wheels and the tri-bot has a BAD time of trying to stop it (yes you try to stop a rolling car by yourself that don't have any brakes).
-Rubber ball - great friction, poor for lowering CG, really BAD with obstacles and BOUNCING.
-Styrofoam two part ball - ok for friction, good for an internal lower motor system thus lowering CG and making drive power at the same level as obstacles, good for internal motor braking, BAD when impacted by obstacles, REALLY BAD when obstacles get stuck to it (cactus thorns, old 7474 chips laying on the floor with legs pointing up)
-MEGA ball - currently working this one
What if you put some water in the rubber ball to give it some weight - but not too much? The movement of the liquid might be unpredictable though. Just an idea...
In the thread past you might notice:
Grandenurse post 38
"I was wondering if I had a little heavy steel ball inside my air filled big ball, would it help the balance standing still issue? "
Duane post 39
"I don't think the ball bearing tricks will work well. It won't be able to distinguish the force from acceleration from the force from gravity."
I agree with Duane, a heavy ball in the lower unit will not help.
The lower unit needs POWER to overcome obstacles. The upper unit is like a person-on-a-log, the lower unit is the log-in-a-river. It's hard to get the log in the river to run over another log in the river while the person stays on top.
POSSIBILITIES:
If this thing can run around as a single point of contact, with the upper unit capable of turning while the lower unit moves in a specific direction, then it has a real chance of winning the FIRE FIGHTING ROBOT challenge handled on the east coast each year. It would have a distinct advantage with floor surfaces (carpet, tile, obstacles, ...). The upper unit can house the sensors and FAN (put out the candle), so only the upper unit needs to turn if it finds the candle next to it!
If EVE (IT) could blow out the candle an then pick it up and return to the start location, I think that would be a first for the Fire Fighting Robot challenge:
NOW FOR THE NEXT PROBLEM:
Assuming you can stand to hear a plastic ball with slats move around on a hard floor that sound like a bunch of people trying to learn tap dancing, WHERE SHOULD IT GO.
Staying BALANCED, driving over OBSTACLES and FIGURING out where to go. The new problem is developing a MAP as you discover the environment, knowing where you are (kind-of).
Pick a spot on the floor, use your PING and COMPASS to create a MAP-ESTIMATE. Use your COMPASS and wheel ENCODERs to refine the information into a MAP. Scout around until you think the MAP is complete (constantly increasing the MAP-ESTIMATE into a MAP). Now go back to the original location.
It kind of looks to need "Taxicab geometry or Manhattan distance" because you can not drive over all the obstacles (you might make it over a pencil but not through a stud wall). Does this require a D* (D star) algorithm?
GENERAL NOTES:
--Glad to see forum back up, thanks to Parallax and those who fixed the issues.
--Tried to get lower unit to report POSITION information to upper unit for use in MAP and LOCATION. Found the middle-age erector-set plastic wheels were slipping to much in the 13" plastic ball to give reliable data. Changed wheels to the rubber beveled things found on a "SPRIG toy car" ($1 broke item at goodwill). Didn't know about SPRIG before but found it interesting. It was made in Canada and has a built-in GENERATOR and a 3F cap, some of you might want to look into these toys as parts sources.
--Simple Mapping Scheme using X-band, Ping, IR distance, and wheel encoder information, to determine what the environment is and where I am. Added I2C ram chip for map data (Prop, BS2px and Arduino internal ram too small). Basic map cell can be one of four values (UNKNOWN-ta, I'M-HERE-at, EMPTY-gc, WALL-cg). Map is refined as environment is visited, which means the cells MAY MOVE. The distance estimates from X-band and Ping are refined with information from IR and wheel-encoders. SOMETIMES wheel information shows ranging (X-band and ping) to be not-exact (due to wall surface construction and angle-of-orientation), so (as example) a cell that was marked as EMPTY-gc may change to WALL-cg.
Well it's close to Christmas so I guess I can use this forum to ask Santa for:
"I want a camera-pair that will interface with the Propeller, that will scan a room (much like my eyes and brain) and produce a MAP (image with depth to automatically generated room MAP)", oh and Santa I would like it no later then the end of the year.
Thanks, but I want a bit more from the robot platform. Since the ball bot does much better in a TALL rather than short structure (see balance information earlier in the thread), I've started stacking, which means I can add features. One key feature is map and then proceed. It is easy to just use a wall follower algorithm, it's harder and has higher value to get a handle on vision - to - map - to - maze tour, with dynamic tour change when an obstacle suddenly occurs that was not present in the initial mapping (like a Christmas tree falling down when the new kitten thinks those flashing things are more toys).
All of this COST power, and I've changed to a 10 minute test, 1 hour recharge all those batteries mode (which is much better than throwing single use batteries into the trash).
AS a MISUSE OF THIS THREAD
"Parallax Pet Products" - take four mini solar panels (mine are from the inside of a BIG screen TV that they were using in the AUTO BALANCE system), set them up for SOLAR (sun) tracking (each mini panel to an ADC input, ADC to BS2, BS2 to H-bridge, H-bridge to geared DC motor platform), then REMOVE the big solar panel that all of this was built for and put the BIG mirror (I had to cut the one from the BIG screen TV down) in it's place. Now you have a reflecting mirror in the yard so the sun light can be reflected into the window that the CAT like to sit in during the day. It can also be used to reflect light onto a "shadowed" brick wall, thus giving a big more warmth to the house during colder months.
Thanks, but I want a bit more from the robot platform. Since the ball bot does much better in a TALL rather than short structure (see balance information earlier in the thread), I've started stacking, which means I can add features.
Did you actually watch the video? Chris L8's bot used a Kinect and did some amazing mapping, far beyond simple wall following. If you're holding out for more than that (plus perfect balancing on a ball) then you might need to adjust your expectations. Realistically, most big projects are best accomplished in small achieveable steps. A steady diet of small successes keeps a project alive. If you try to tackle everything at once, you can drain your enthusiasm tanks quickly.
Yes I watched the video. I must have misunderstood the setup, is the laptop (PC) involved with the Kinect or is the Kinect interfacing directly with the Propeller? It looked like: a PC, some form of Linux, some Oracle database stuff, a Robot Operating System (ROS), some wifi, an operator telling it what to do, ....
I did not mean to accuse it of simple wall following (I was referring to a type of "algorithm").
I do understand project creep, where you keep tackling things that were not on the original scope of work. Project creep is a reality in research type projects, which this thing seems to be.
I think so far in this project there have been several "Steps":
1. Identifying which BALL to use and understanding where the Center of Gravity should be (different on flat smooth floors ..verses.. obstacle laden environments)
2. Identifying the balance detect sub-system and where these sensors fail (or at least give poor values), a collection of different types seemed to be better (Balls in a cup, X-Y pot, and accel/gyro)
3. Identifying the environmental detection sub-system (this is where we are now) so that better decisions can be made
Maybe a pair of Phil's cameras, a couple of servos, and a prop board doing some calculations. That module could then be interfaced to an prop board that then builds a map (might need the I2C external ram here) based on information from the first module. The second module could then also command the lower ball to move and in what direction.
I've not tried Phil's latest camera module, any suggestions?
LOG ENTRY: Hormones verses Neurotransmitters
The current design (which I know will compress much later in development) includes various processors each with it's own function. Communications between processors can take one of two types of path's: Hormones or Neurotransmitters. The "neurotransmitter" like path is just a wire (and associated return, or ground), with extremely quick communication at the cost of a bunch of wires and IO pins. The "hormone" like path is a serial bus type where multiple senders / receivers exist, but only one sender can be active at any point in time (different then blood based body sub-system where multiple hormones can be present at any point in time). The Hormone path takes less wires at the cost of speed of communications. DUE to the physical distances involved I can not extend an I2C bus (a hormone style) to all sub-system interfaces and may end up with a binary level High Baud Rate Serial structure (HBRS).
Why bring it up? Vision, Audio (tone detect band pass filters), distance sensing (IR, ping-sonic, x-band), tri-wheel motor control, lower motor movement, and balance detect sub-systems need to communicate. At times some sub-systems don't have QUICK needs to communicate (middle of the room, nothing around, balanced), and at other times they develop QUICK needs (about to run into something, falling over, ...). So need to determine what and how much (wiring, IOs, and NMI-IRQ-POLL protocols).
So I was thinking about a STROBE neurotransmitter that informs all sub-systems (excluding the lower motor ball unit) movement has occurred and they should update their state information. [IRQ needs]
And a PRIORITY neurotransmitter that informs all sub-systems (and indirectly includes lower motor ball unit) that a critical event has been detected (like starting to fall over) and ONLY critical processors should be using the Hormone communication busses. [NMI needs]
Would it be a good idea to use a propeller as a STAR type HBRS hub?
LOG ENTRY: low resolution B&W image converted to OBSTACLES (which includes walls)
Is this a graph theory problem? Scanning through a two dimensional array, looking for edge marks (video image differences), ending up with a set of vectors (really lines as they are (x1, y1, x2, y2) formats). Then take the vectors and some fuzzy logic to "guess" where and in what orientation the Obstacles are.
LOG ENTRY: Three eye vision system ?
Color camera gives nice pictures but not all that color information is required (some but not all). Understanding that one wall is orange and another is green is good, but the shades of orange (gets darker as the wall extends away from the camera and light source) are distractions.
Black and White camera gives good structure but doesn't distinguish between similar colors (two walls, different colors, but about same brightness).
Looking DOWN onto the floor is easier then trying to compute distance from two (horizontally level) distance separated cameras.
Why not three cameras? One looking down and out, the other two looking forward with linked servo (as one camera is pivoted CCW the other camera is pivoted CW in an equal angular movement). In the middle of the camera cluster is an Adafruit CROSS laser (PRODUCT ID: 1058). The image alignment is handled by a CROSS laser pulse while all three cameras collect an image. One of the forward looking cameras is a Black and White, the other is a color.
Each camera has it's own processor and extended I2C memory (or they could be ras-pi's which are cheap and already have the interface and memory).
LOG ENTRY: after you get the EDGEs detected, what is the object?
hmmmmmmmmmmmmmmm, what is it? Seems like the B& W information laid on top of the color information is useful, until you ask the question what is it.
Do you really need to know what it is when you've identified an obstacle?
Do I need the object database or just the determination that something is there?
Knowing that the floor is TILE verses rough CONCRETE is good because the speed of travel (and stopping) is better with the higher friction surface (can have a nasty fall on very smooth tile while trying to change direction).
Knowing the wall if DRYWALL or WOOD doesn't matter, it's a wall!
Knowing the obstacle is a PENCIL (#2 something that we use to use a lot) or section of REBAR doesn't make much difference. Knowing the size of the obstacle and it's orientation to the bot is very useful.
The only obstacles that seem like they really need identified is the sleeping DOG tail and/or the sleeping CAT tail. Misidentification that it was a piece of rebar was not good. Running over them had bad results (please note the bot weights less than 20 pounds, no animals were hurt or maimed), the cat now attacks the bot while it is in maintenance mode (the wiring has bite marks).
Knowing a surface coating of the flooring (water, oil, sand, ...) is very useful, and can add to the MAP as a OBSTALCE-cg (use to be WALL-cg).
LOG ENTRY: Soap !!!!!!!!! might as well be oil !
Non-experimental results: What happens when soap (for making bubbles in the back yard) is spilled on the tile floor and not cleaned up correctly? Friction is reduced and no matter how fast the tri-wheel base tries to react, the bot goes down!
Possible solutions: Increase the surface friction of the ball, Ban SOAP from the house, Improve the camera system to look for surface issues, or try conductivity sensors on the ball surface.
Solution 1: Increase the surface friction of the ball
Easy to implement, apply narrow strips of STAIR STEP NO SLIP tape. BAD part is it could start scratching the surface of the floor tile. NOT implemented.
Solution 2: Ban SOAP from the house.
Easy to implement, don't purchase any soap. BAD part is nothing will get clean (dishes, clothes, me, others, ...). NOT implemented.
Solution 3: Improve the camera system to look for surface issues.
Tried several experiments using down-looking & angle-looking camera and light source (lights on different pan-tilt then camera), trying to expose index of reflection/refraction of surface. Color has better results than B&W camera. Lights are a set of different LEDs (got a selection of different core color SMD leds), so I can select ALL of them or just specific colors. Tile surface has it's own problem, it is not a uniform single color and the grout boundary differs between high/low traffic areas (I think it's dirt but I don't want to scrub the floor again). Need more work.
Solution 4: try conductivity sensors on the ball surface.
Problem is the internal motor system runs on the inside of the ball, the floor is on the outside of the ball, both inside and outside don't want big bumps (sensor, batteries, transmitter). Any conductivity sensor (tape, pins, ...) would be on the outside of the ball and would be exposed to the environment and total weight of the bot (ball, batteries, motors, and entire upper unit), and may experience excessive wear. Not tried yet but may need to come back to this one.
The last one I have is from the bot camera itself, seconds in length as it toppled over due to the SOAP that got onto the ball.
I notice the view count goes up but seem to miss the responses to the "suggestions", so I can only assume that others like the information about success and failure, to know what to watch out for in the future.
LOG ENTRY: replacement of upper assembly
The upper assembly took the brunt of the SOAP fall. It had a NTSC camera, flash ADC (TI older part that's no longer in production), and interfaced with a psoc 5 board. Serial stream cameras can easily be replaced with parallel feeds, so NTSC is not a requirement. The psoc 5 board has been a pain because you are required to update the life long authorization-key every year (why, let me ask Sheldon maybe), so it's not a requirement. Looks like time to upgrade to a Raspberry pi and camera, because it's cheap enough and includes a big batch of video processing software with an on board video accelerator. The camera looks to be easy to mount to the adafruit Mini Pan-Tilt Kit - Assembled with Micro Servos PRODUCT ID: 1967, with the addition of a adafruit Flex Cable for Raspberry Pi Camera - 18" / 457mm PRODUCT ID: 1730. The raspberry pi documentation implies that I can run a second camera as long as it is a WEB USB style. Between the two cameras and the cross laser (I purchased mine last year, which was good because they ran out of them recently) a reasonable image / map should be able to be produced. The raspberry pi will not make decisions as this function has already been assigned to a propeller-1.
Sounds like a lot of delicate stuff on top of a ball balancer which by all accounts isn't actually working yet. I admire your optimism. Isn't that a bit like putting the cart before the horse?
This entire project (and the new things discovered) is just research. I've learned a lot.
The thing (EVE or whatever you want to call it) has undergone several revisions:
--Taller is better for balance
--Low CG is better for obstacle traversal
--Various processors (Arduino, Propeller, Picaxe, Cypress, Raspberry, ...) all have their "Best" places / function (though it would be nice if they used a single common interface language / user-GUI)
Each revision is better than the previous (like the NASA space capsule development).
Most of the time the unit is under going mechanical changes, repairs or redesign (and isn't working then)
I find your statement ..."by all accounts isn't actually working"..... a bit strong but understandable per your view (can't see it therefore it must not exist).
I started this with "a sharing basis", and continue to share information. If the information is incorrect, please let me (and the others) know with a friendly post. If you have one that is working (other than what you can just purchase, like the little things that a big company in Japan developed) please share it.
I think I said I would make a video / pictures available when it is working. I've not done that because the ENTIRE thing is not complete.
Comments
https://www.ri.cmu.edu/pub_files/pub4/lauwers_tom_2006_1/lauwers_tom_2006_1.pdf
http://www.princeton.edu/~wentzlaf/documents/Batten.2001.Class.Kickbot.pdf
In order for Kickbot to find people to antagonize, it needs some way to detect them, and an easy way to detect people is to look for motion.
I am keeping up too! I always read threads like this to learn new things...
http://www.hizook.com/blog/2008/11/11/rotundus-spherical-robot-makes-popsci-best-2008
The PROBLEM: lower ball unit contains a spherical bot that contains lots of batteries and "level" weights but sometimes can not STOP fast enough
Drive a spherical bot as fast as you can (one with lots of extra batteries and ballast lead weights) then tell it to STOP on a dime. I get at least one toggle flip using worm drive motors, or just a lot of drift with just geared down motors. It would be nice to overcome the problems of plain physics here.
Anyone know how I can add this death star beam t my lower ball unit?
http://img2.wikia.nocookie.net/__cb20111104205236/starwars/images/5/50/Superlaser2.jpg
The two part Styrofoam ball from Michaels was great in absorbing impact, so much so that it is now dead. That's alright because it forced the upper / lower unit to communicate via RF to obtain commands and indirectly orientation.
As the ball bot comes over an obstacle you get some unwanted acceleration, sometimes flipping around the motor unit housed inside the two part Styrofoam lower unit (held together with duct tape, so you can take it apart for battery charging). This lead to mis-orientation forcing the system design to institute a policy of checking upper unit / lower unit orientation check (upper says go forward and then determines the lower unit orientation based on how the upper unit needed to correct for balance). The problem was when you had the next obstacle so close that determining orientation was incorrect due to "climbing over effect" (more post obstacle acceleration / banging).
So since we now have a THREE comparison balance system we can accept the temporary impulse NOISE due to the "climbing over effect".
So I've moved over to a two part MEGA LARGE (13") PLASTIC RAT BALL from petsmart (you can also find them on the web cheaper). This ball has slots allowing for the reactivation of the THREE node IR communications sub-system. This is three bidirectional IR's picaxe-08M2 modules mounted near the wow-wee tri-bot wheels, and three bidirectional IR's picaxe-08M2 modules mounted at 120 degree spacing on the lower motor unit. This allows faster orientation determination between the upper and lower units. Each picaxe-08M2 has a IR tx led an a 38khz IR rx receiver. The stamps do not need to stop what they are doing for communications now, they just get a signal "tap" from the 08M2 module when something has arrived.
Now the bad part:
-The Styrofoam ball (when completely taped around the center of the seam) could actually make it through SAND and low WATER environments (even though the sand can get up into the tri-bot wheel bearings). This was impressive (NO VIDEO, just test environment). BUT the water could not be too deep as to float the system, or too long as to coat the ball making it too slippery (still need friction) for the tri-bot upper unit.
-The MEGA ball has slots, great for IR communication BUT REALLY BAD for SAND and WATER.
Maybe the slots in the MEGA ball might provide an interface for that Death Star weapon, will put this on the very END of the want list.
-Bowling ball - great for low Center of Gravity (CG) but does not provide enough friction surface for the tri-bot wheels and the tri-bot has a BAD time of trying to stop it (yes you try to stop a rolling car by yourself that don't have any brakes).
-Rubber ball - great friction, poor for lowering CG, really BAD with obstacles and BOUNCING.
-Styrofoam two part ball - ok for friction, good for an internal lower motor system thus lowering CG and making drive power at the same level as obstacles, good for internal motor braking, BAD when impacted by obstacles, REALLY BAD when obstacles get stuck to it (cactus thorns, old 7474 chips laying on the floor with legs pointing up)
-MEGA ball - currently working this one
Or maybe a pogo stick ... kidding mostly.
Grandenurse post 38
"I was wondering if I had a little heavy steel ball inside my air filled big ball, would it help the balance standing still issue? "
Duane post 39
"I don't think the ball bearing tricks will work well. It won't be able to distinguish the force from acceleration from the force from gravity."
I agree with Duane, a heavy ball in the lower unit will not help.
The lower unit needs POWER to overcome obstacles. The upper unit is like a person-on-a-log, the lower unit is the log-in-a-river. It's hard to get the log in the river to run over another log in the river while the person stays on top.
POSSIBILITIES:
If this thing can run around as a single point of contact, with the upper unit capable of turning while the lower unit moves in a specific direction, then it has a real chance of winning the FIRE FIGHTING ROBOT challenge handled on the east coast each year. It would have a distinct advantage with floor surfaces (carpet, tile, obstacles, ...). The upper unit can house the sensors and FAN (put out the candle), so only the upper unit needs to turn if it finds the candle next to it!
Assuming you can stand to hear a plastic ball with slats move around on a hard floor that sound like a bunch of people trying to learn tap dancing, WHERE SHOULD IT GO.
Staying BALANCED, driving over OBSTACLES and FIGURING out where to go. The new problem is developing a MAP as you discover the environment, knowing where you are (kind-of).
Pick a spot on the floor, use your PING and COMPASS to create a MAP-ESTIMATE. Use your COMPASS and wheel ENCODERs to refine the information into a MAP. Scout around until you think the MAP is complete (constantly increasing the MAP-ESTIMATE into a MAP). Now go back to the original location.
It kind of looks to need "Taxicab geometry or Manhattan distance" because you can not drive over all the obstacles (you might make it over a pencil but not through a stud wall). Does this require a D* (D star) algorithm?
Like normal I'll look for comments.
--Glad to see forum back up, thanks to Parallax and those who fixed the issues.
--Tried to get lower unit to report POSITION information to upper unit for use in MAP and LOCATION. Found the middle-age erector-set plastic wheels were slipping to much in the 13" plastic ball to give reliable data. Changed wheels to the rubber beveled things found on a "SPRIG toy car" ($1 broke item at goodwill). Didn't know about SPRIG before but found it interesting. It was made in Canada and has a built-in GENERATOR and a 3F cap, some of you might want to look into these toys as parts sources.
--Simple Mapping Scheme using X-band, Ping, IR distance, and wheel encoder information, to determine what the environment is and where I am. Added I2C ram chip for map data (Prop, BS2px and Arduino internal ram too small). Basic map cell can be one of four values (UNKNOWN-ta, I'M-HERE-at, EMPTY-gc, WALL-cg). Map is refined as environment is visited, which means the cells MAY MOVE. The distance estimates from X-band and Ping are refined with information from IR and wheel-encoders. SOMETIMES wheel information shows ranging (X-band and ping) to be not-exact (due to wall surface construction and angle-of-orientation), so (as example) a cell that was marked as EMPTY-gc may change to WALL-cg.
any comments about D* algorithm?
"I want a camera-pair that will interface with the Propeller, that will scan a room (much like my eyes and brain) and produce a MAP (image with depth to automatically generated room MAP)", oh and Santa I would like it no later then the end of the year.
keywords: Stereopsis, binocular vision, vision limited handicap assistance
Check out this thread http://forums.parallax.com/showthread.php/156644-Building-Arlo/page2 as a source of info re vision and mapping.
Jim
P.S. where abouts in AZ are you? I live in Anthem and work in Fountain Hills.
All of this COST power, and I've changed to a 10 minute test, 1 hour recharge all those batteries mode (which is much better than throwing single use batteries into the trash).
"Parallax Pet Products" - take four mini solar panels (mine are from the inside of a BIG screen TV that they were using in the AUTO BALANCE system), set them up for SOLAR (sun) tracking (each mini panel to an ADC input, ADC to BS2, BS2 to H-bridge, H-bridge to geared DC motor platform), then REMOVE the big solar panel that all of this was built for and put the BIG mirror (I had to cut the one from the BIG screen TV down) in it's place. Now you have a reflecting mirror in the yard so the sun light can be reflected into the window that the CAT like to sit in during the day. It can also be used to reflect light onto a "shadowed" brick wall, thus giving a big more warmth to the house during colder months.
Did you actually watch the video? Chris L8's bot used a Kinect and did some amazing mapping, far beyond simple wall following. If you're holding out for more than that (plus perfect balancing on a ball) then you might need to adjust your expectations. Realistically, most big projects are best accomplished in small achieveable steps. A steady diet of small successes keeps a project alive. If you try to tackle everything at once, you can drain your enthusiasm tanks quickly.
I did not mean to accuse it of simple wall following (I was referring to a type of "algorithm").
I do understand project creep, where you keep tackling things that were not on the original scope of work. Project creep is a reality in research type projects, which this thing seems to be.
I think so far in this project there have been several "Steps":
1. Identifying which BALL to use and understanding where the Center of Gravity should be (different on flat smooth floors ..verses.. obstacle laden environments)
2. Identifying the balance detect sub-system and where these sensors fail (or at least give poor values), a collection of different types seemed to be better (Balls in a cup, X-Y pot, and accel/gyro)
3. Identifying the environmental detection sub-system (this is where we are now) so that better decisions can be made
I've not tried Phil's latest camera module, any suggestions?
The current design (which I know will compress much later in development) includes various processors each with it's own function. Communications between processors can take one of two types of path's: Hormones or Neurotransmitters. The "neurotransmitter" like path is just a wire (and associated return, or ground), with extremely quick communication at the cost of a bunch of wires and IO pins. The "hormone" like path is a serial bus type where multiple senders / receivers exist, but only one sender can be active at any point in time (different then blood based body sub-system where multiple hormones can be present at any point in time). The Hormone path takes less wires at the cost of speed of communications. DUE to the physical distances involved I can not extend an I2C bus (a hormone style) to all sub-system interfaces and may end up with a binary level High Baud Rate Serial structure (HBRS).
Why bring it up? Vision, Audio (tone detect band pass filters), distance sensing (IR, ping-sonic, x-band), tri-wheel motor control, lower motor movement, and balance detect sub-systems need to communicate. At times some sub-systems don't have QUICK needs to communicate (middle of the room, nothing around, balanced), and at other times they develop QUICK needs (about to run into something, falling over, ...). So need to determine what and how much (wiring, IOs, and NMI-IRQ-POLL protocols).
So I was thinking about a STROBE neurotransmitter that informs all sub-systems (excluding the lower motor ball unit) movement has occurred and they should update their state information. [IRQ needs]
And a PRIORITY neurotransmitter that informs all sub-systems (and indirectly includes lower motor ball unit) that a critical event has been detected (like starting to fall over) and ONLY critical processors should be using the Hormone communication busses. [NMI needs]
Would it be a good idea to use a propeller as a STAR type HBRS hub?
END OF LOG ENTRY
Is this a graph theory problem? Scanning through a two dimensional array, looking for edge marks (video image differences), ending up with a set of vectors (really lines as they are (x1, y1, x2, y2) formats). Then take the vectors and some fuzzy logic to "guess" where and in what orientation the Obstacles are.
Math theory or computer science suggestions?
END OF LOG ENTRY
Color camera gives nice pictures but not all that color information is required (some but not all). Understanding that one wall is orange and another is green is good, but the shades of orange (gets darker as the wall extends away from the camera and light source) are distractions.
Black and White camera gives good structure but doesn't distinguish between similar colors (two walls, different colors, but about same brightness).
Looking DOWN onto the floor is easier then trying to compute distance from two (horizontally level) distance separated cameras.
Why not three cameras? One looking down and out, the other two looking forward with linked servo (as one camera is pivoted CCW the other camera is pivoted CW in an equal angular movement). In the middle of the camera cluster is an Adafruit CROSS laser (PRODUCT ID: 1058). The image alignment is handled by a CROSS laser pulse while all three cameras collect an image. One of the forward looking cameras is a Black and White, the other is a color.
Each camera has it's own processor and extended I2C memory (or they could be ras-pi's which are cheap and already have the interface and memory).
As normal, suggestions????
END OF LOG ENTRY
hmmmmmmmmmmmmmmm, what is it? Seems like the B& W information laid on top of the color information is useful, until you ask the question what is it.
Do you really need to know what it is when you've identified an obstacle?
Do I need the object database or just the determination that something is there?
Knowing that the floor is TILE verses rough CONCRETE is good because the speed of travel (and stopping) is better with the higher friction surface (can have a nasty fall on very smooth tile while trying to change direction).
Knowing the wall if DRYWALL or WOOD doesn't matter, it's a wall!
Knowing the obstacle is a PENCIL (#2 something that we use to use a lot) or section of REBAR doesn't make much difference. Knowing the size of the obstacle and it's orientation to the bot is very useful.
The only obstacles that seem like they really need identified is the sleeping DOG tail and/or the sleeping CAT tail. Misidentification that it was a piece of rebar was not good. Running over them had bad results (please note the bot weights less than 20 pounds, no animals were hurt or maimed), the cat now attacks the bot while it is in maintenance mode (the wiring has bite marks).
Knowing a surface coating of the flooring (water, oil, sand, ...) is very useful, and can add to the MAP as a OBSTALCE-cg (use to be WALL-cg).
As normal, suggestions???
END OF LOG ENTRY
Non-experimental results: What happens when soap (for making bubbles in the back yard) is spilled on the tile floor and not cleaned up correctly? Friction is reduced and no matter how fast the tri-wheel base tries to react, the bot goes down!
Possible solutions: Increase the surface friction of the ball, Ban SOAP from the house, Improve the camera system to look for surface issues, or try conductivity sensors on the ball surface.
Solution 1: Increase the surface friction of the ball
Easy to implement, apply narrow strips of STAIR STEP NO SLIP tape. BAD part is it could start scratching the surface of the floor tile. NOT implemented.
Solution 2: Ban SOAP from the house.
Easy to implement, don't purchase any soap. BAD part is nothing will get clean (dishes, clothes, me, others, ...). NOT implemented.
Solution 3: Improve the camera system to look for surface issues.
Tried several experiments using down-looking & angle-looking camera and light source (lights on different pan-tilt then camera), trying to expose index of reflection/refraction of surface. Color has better results than B&W camera. Lights are a set of different LEDs (got a selection of different core color SMD leds), so I can select ALL of them or just specific colors. Tile surface has it's own problem, it is not a uniform single color and the grout boundary differs between high/low traffic areas (I think it's dirt but I don't want to scrub the floor again). Need more work.
Solution 4: try conductivity sensors on the ball surface.
Problem is the internal motor system runs on the inside of the ball, the floor is on the outside of the ball, both inside and outside don't want big bumps (sensor, batteries, transmitter). Any conductivity sensor (tape, pins, ...) would be on the outside of the ball and would be exposed to the environment and total weight of the bot (ball, batteries, motors, and entire upper unit), and may experience excessive wear. Not tried yet but may need to come back to this one.
As normal, suggestions????
END OF LOG ENTRY
END OF LOG ENTRY
I notice the view count goes up but seem to miss the responses to the "suggestions", so I can only assume that others like the information about success and failure, to know what to watch out for in the future.
How is everyone else doing?
The upper assembly took the brunt of the SOAP fall. It had a NTSC camera, flash ADC (TI older part that's no longer in production), and interfaced with a psoc 5 board. Serial stream cameras can easily be replaced with parallel feeds, so NTSC is not a requirement. The psoc 5 board has been a pain because you are required to update the life long authorization-key every year (why, let me ask Sheldon maybe), so it's not a requirement. Looks like time to upgrade to a Raspberry pi and camera, because it's cheap enough and includes a big batch of video processing software with an on board video accelerator. The camera looks to be easy to mount to the adafruit Mini Pan-Tilt Kit - Assembled with Micro Servos PRODUCT ID: 1967, with the addition of a adafruit Flex Cable for Raspberry Pi Camera - 18" / 457mm PRODUCT ID: 1730. The raspberry pi documentation implies that I can run a second camera as long as it is a WEB USB style. Between the two cameras and the cross laser (I purchased mine last year, which was good because they ran out of them recently) a reasonable image / map should be able to be produced. The raspberry pi will not make decisions as this function has already been assigned to a propeller-1.
As normal, suggestions ???
END OF LOG ENTRY
The thing (EVE or whatever you want to call it) has undergone several revisions:
--Taller is better for balance
--Low CG is better for obstacle traversal
--Various processors (Arduino, Propeller, Picaxe, Cypress, Raspberry, ...) all have their "Best" places / function (though it would be nice if they used a single common interface language / user-GUI)
Each revision is better than the previous (like the NASA space capsule development).
Most of the time the unit is under going mechanical changes, repairs or redesign (and isn't working then)
I find your statement ..."by all accounts isn't actually working"..... a bit strong but understandable per your view (can't see it therefore it must not exist).
I started this with "a sharing basis", and continue to share information. If the information is incorrect, please let me (and the others) know with a friendly post. If you have one that is working (other than what you can just purchase, like the little things that a big company in Japan developed) please share it.
I think I said I would make a video / pictures available when it is working. I've not done that because the ENTIRE thing is not complete.
Thank you for your support, any suggestions?