LOG ENTRY: status update
I've not seen anything posted as to someone-else solution or suggestions, so this is where I've got to:
1. The camera system is now a raspberry PI with camera option and openCV software, with a custom arduino board attached to the expansion port. The PI does all the video stuff and passes object summary out the serial lines to a propeller for decision actions. Objects are easier to detect using the various routines that openCV provides. The camera is mounted on an Adafruit pan & tilt assembly with the servos controlled by the arduino board. The arduino board is just an I2C SLAVE with bidirectional voltage level adaptor to/from the PI. The arduino also controls an Adafruit pan & tilt module with 15 leds. The LEDs are six banks: 3 UV, 3 Blue, 3 Green, 3 Red, 2 IR and 1 Laser. The PI can request the Arduino to move the camera, the leds and illuminate a target with specific color (the led banks). The LEDs and pan & tilt stuff helps when the unit is trying to identify if the floor has a film (oil, water, soap, ...). It bases the FILM covering decision on a REFERENCE floor section (yes, you need to tell it where a GOOD floor area is so it can scan various light frequencies across it).
2. The lower motor unit base was rebuilt using some flattened 1/2" copper pipe, with the axles moved to an out-of-aligned configuration. Balance uses a front and rear skid attached to the copper base. I think the previous assembly was getting some static build up (inside the big plastic ball, rolling around, with internal plastic skids).
3. The motors / bearings on the tri-wheel base are badly worn due to the weight of the upper assembly (erector set metal shield, three plastic plates acting as mounting platforms, batteries, and various processors). I think moving to heavier stepper motors would be good, but I have not made this move yet.
4. Experiments with the movement subsystem still show that an upper and lower system is easier to implement, though higher in total hardware cost. FOR discussion:
----A) A two wheel (two motor) bot must integrate the movement desire with the balance need.
----B) A three wheel (three motors) bot is stable (solving balance) so it only needs to deal with movement
----C) A one wheel bot can be built in several ways: it can have a single unit system (two or three motors) that try's to maintain balance and integrate movement
or
it can have a bi-unit system, an upper and lower system, where the lower system just works on movement, while the upper system works on just staying on top (balance)
5. Obstacle detection is easy when the obstacles are different color (like painted door threshold on a gray concrete floor) so the camera can respond. In reality this will not happen, so I think another pan & tilt assembly with a PING & IR's mounted would give a better solution. Parallax had a nice document talking about detecting objects by varying the IR frequency (I've not tried it yet but it should work). The other advantage to this addition is depth / height data. Unless the camera is modified for bi-view, distance will be a problem. The PING and IR should overcome this issue as they can be pointed to (using the pan & tilt) the object of interest and give range data.
6. Looking over a beer belly works because you can just move you but back to maintain balance. Extending the pan & tilt modules out so that they can look down out over the big lower unit ball, to see the floor or objects also needs some counter balance. I've tried a worm screw set inside a clear plastic tube with a set of glass marbles. The screw turns, pushing or pulling the marbles thus changing the center of gravity on the upper unit. There are many other ways to do this but I found the screw, tube and marbles in a kids toy and just like how it looks.
I hope this is informative and does not lead to another "uninvited visitors".
LOG ENTRY:
2. The lower motor unit base was rebuilt using some flattened 1/2" copper pipe, with the axles moved to an out-of-aligned configuration. Balance uses a front and rear skid attached to the copper base.
....
6. Looking over a beer belly works because you can just move you but back to maintain balance....
END OF LOG ENTRY
Pictures required for number 2, or it never happened...
Please, No Pictures attached for number 6....
Still reading this thread. Currently unable to contribute more than some funny remarks to hopefully keep you motivated...
LOG ENTRY: Generic low cost reproducible structure
Making a generic low cost reproducible structure that has: redesign ability, low weight, limited strength, easily accessible to others, AND low cost. This has lead me to using K'nex. The plastic doesn't interfere with the compass (magnetic issues), and the plastic can take a bit of beating. It does have some flexibility and is easy to replace a failed section. It's also allows for custom pieces using a heat gun / plastic welder (both available at harbor freight). You can mount the K'nex pieces directly onto a standard servo motor using the little bolts/nuts provided with the servo. K'nex does have their own motors (many colors, each color motor is a specific RPM output) but they need modified for processors (and H bridge) control.
As a note: H bridges seem to be a lot cheaper when you just go to Goodwill, purchase a RC toy (one or two dollars), and just cut (dremel with cutter blade) the H bridge circuit away from the receiver circuit.
LOG ENTRY: Change ball homebuilt motor unit to consumer available unit
The copper tube offset erector set motors and toy car wheels base was working better than the plastic version I started with. But no-one would build it (other than me for prototyping). The design allowed either end of the smashed copper tubes to drag on the inside of the 13" ball while the unit was moving or turning, thus creating three point of contacts (wheel, wheel, and contact plate)for it's own balance. This also helped when the unit was commanded to drive the ball over obstacles, as the contact plate helped to keep it from flipping over (yes I tried a two wheel version with balance controls but it never had enough dynamics). An alternate seems to be modifying a "Blue Hat Street Savage" rc toy car: removing the front wheels and replacing them with a curved skid plate (basically a LARGE serving spoon, as it has curves in both X and Y direction), THEN forcing the rear wheels close (they have A LOT of movement and your are forcing them to be as close to the front as possible with the battery weight above them). I used the handle (cut off the serving spoon) underneath the battery compartment and above the "wheelie" bars (which are attached to the back of the motor gear extensions) to FORCE the rear wheels where I wanted them. It seems to do ok but does not have the weight that the D cells hanging under the copper plate provided.
On a side note: from what I've read today, the vision (openCV) software and camera being used with the pi model B+ looks to be (but I haven't tested yet) compatible with the brand new pi model 2. The power of the model 2 might allow for the decision software to be ported from the propeller to the new pi, I'll need to see after I get one.
LOG ENTRY: marble mania extreme
The square silver "marble mania extreme" bars and their matching black connectors have proven to be a reliable building structure for the upper unit. Impact testing shows they survive 90% of the time. The K'nex assembly did not have the same results (would come apart and sometimes broke the ends). IMPACT testing is required because the upper assembly falls in those "didn't design the software for that event". The nice thing is the cameras (raspberry regular DEV-11868 and noir DEV-12654) are easy to bolt on the adafruit pan & tilt assembly, which can be attached (I used 4x40 nylon bolt and nuts) to the silver bars. The silver bars come in different sizes, of which one is exactly the correct size to mount a raspberry pi (I'm using a 1B+ and a 2). The same silver bar can also be drilled to handle a prop board.
I've attached a custom arduino to the raspberry pi expansion port using a custom I2C interface (base design documented on the arduino site). The pi can command the arduino the drive the pan & tilt servos to move the camera. It also can command the same arduino to drive a second pan & tilt assembly that has various LEDs (color banks). The arduino is also responsible for setting the desired color, as commanded.
Each pi-EYE (and it's arduino, servos, camera, and light source) reports to a common single prop, via serial line (using multiple copies of the serial object as I'm not COG over-used).
The lower unit (FEET) is an arduino mounted on a modified two wheel & skid plate toy, using three picaxe-08m2 with bi-directional IR assemblies.
The prop coordinates the EYE's, and FEET. Communication with the FEET is with a matching set of three picaxe-08m2 (and associated bi-directional IR).
For now I've removed the Cypress pSoc5. The Cypress was doing the "THINKING", but that effort was downsized and simplified then placed into the prop.
LOG ENTRY: Tilt/slip issues when trying to stop mid way on an incline plane
Moving up or down and then stopping on a steep incline plane has some real issues. Keeping the ball (FEET) from rolling and maintaining balance, while trying to keep a fixed location. The incline plane can not be real smooth as the ball looses friction, so I painted some marine skipsand surface on it. But as the angle gets bigger (more than 30 degrees) just stopping and holding location becomes a problem. Putting LONG arms with extended weights (like the pole for tight rope walkers) is no help. Hmmmmmmmmmmmmmm ?
Comments
I've not seen anything posted as to someone-else solution or suggestions, so this is where I've got to:
1. The camera system is now a raspberry PI with camera option and openCV software, with a custom arduino board attached to the expansion port. The PI does all the video stuff and passes object summary out the serial lines to a propeller for decision actions. Objects are easier to detect using the various routines that openCV provides. The camera is mounted on an Adafruit pan & tilt assembly with the servos controlled by the arduino board. The arduino board is just an I2C SLAVE with bidirectional voltage level adaptor to/from the PI. The arduino also controls an Adafruit pan & tilt module with 15 leds. The LEDs are six banks: 3 UV, 3 Blue, 3 Green, 3 Red, 2 IR and 1 Laser. The PI can request the Arduino to move the camera, the leds and illuminate a target with specific color (the led banks). The LEDs and pan & tilt stuff helps when the unit is trying to identify if the floor has a film (oil, water, soap, ...). It bases the FILM covering decision on a REFERENCE floor section (yes, you need to tell it where a GOOD floor area is so it can scan various light frequencies across it).
2. The lower motor unit base was rebuilt using some flattened 1/2" copper pipe, with the axles moved to an out-of-aligned configuration. Balance uses a front and rear skid attached to the copper base. I think the previous assembly was getting some static build up (inside the big plastic ball, rolling around, with internal plastic skids).
3. The motors / bearings on the tri-wheel base are badly worn due to the weight of the upper assembly (erector set metal shield, three plastic plates acting as mounting platforms, batteries, and various processors). I think moving to heavier stepper motors would be good, but I have not made this move yet.
4. Experiments with the movement subsystem still show that an upper and lower system is easier to implement, though higher in total hardware cost. FOR discussion:
----A) A two wheel (two motor) bot must integrate the movement desire with the balance need.
----B) A three wheel (three motors) bot is stable (solving balance) so it only needs to deal with movement
----C) A one wheel bot can be built in several ways: it can have a single unit system (two or three motors) that try's to maintain balance and integrate movement
or
it can have a bi-unit system, an upper and lower system, where the lower system just works on movement, while the upper system works on just staying on top (balance)
5. Obstacle detection is easy when the obstacles are different color (like painted door threshold on a gray concrete floor) so the camera can respond. In reality this will not happen, so I think another pan & tilt assembly with a PING & IR's mounted would give a better solution. Parallax had a nice document talking about detecting objects by varying the IR frequency (I've not tried it yet but it should work). The other advantage to this addition is depth / height data. Unless the camera is modified for bi-view, distance will be a problem. The PING and IR should overcome this issue as they can be pointed to (using the pan & tilt) the object of interest and give range data.
6. Looking over a beer belly works because you can just move you but back to maintain balance. Extending the pan & tilt modules out so that they can look down out over the big lower unit ball, to see the floor or objects also needs some counter balance. I've tried a worm screw set inside a clear plastic tube with a set of glass marbles. The screw turns, pushing or pulling the marbles thus changing the center of gravity on the upper unit. There are many other ways to do this but I found the screw, tube and marbles in a kids toy and just like how it looks.
I hope this is informative and does not lead to another "uninvited visitors".
As normal, any suggestions?
END OF LOG ENTRY
Please, No Pictures attached for number 6....
Still reading this thread. Currently unable to contribute more than some funny remarks to hopefully keep you motivated...
Keep up the good fun GrandeNurse.
-Tommy
Making a generic low cost reproducible structure that has: redesign ability, low weight, limited strength, easily accessible to others, AND low cost. This has lead me to using K'nex. The plastic doesn't interfere with the compass (magnetic issues), and the plastic can take a bit of beating. It does have some flexibility and is easy to replace a failed section. It's also allows for custom pieces using a heat gun / plastic welder (both available at harbor freight). You can mount the K'nex pieces directly onto a standard servo motor using the little bolts/nuts provided with the servo. K'nex does have their own motors (many colors, each color motor is a specific RPM output) but they need modified for processors (and H bridge) control.
As a note: H bridges seem to be a lot cheaper when you just go to Goodwill, purchase a RC toy (one or two dollars), and just cut (dremel with cutter blade) the H bridge circuit away from the receiver circuit.
As normal, suggestions?
END OF LOG ENTRY
The copper tube offset erector set motors and toy car wheels base was working better than the plastic version I started with. But no-one would build it (other than me for prototyping). The design allowed either end of the smashed copper tubes to drag on the inside of the 13" ball while the unit was moving or turning, thus creating three point of contacts (wheel, wheel, and contact plate)for it's own balance. This also helped when the unit was commanded to drive the ball over obstacles, as the contact plate helped to keep it from flipping over (yes I tried a two wheel version with balance controls but it never had enough dynamics). An alternate seems to be modifying a "Blue Hat Street Savage" rc toy car: removing the front wheels and replacing them with a curved skid plate (basically a LARGE serving spoon, as it has curves in both X and Y direction), THEN forcing the rear wheels close (they have A LOT of movement and your are forcing them to be as close to the front as possible with the battery weight above them). I used the handle (cut off the serving spoon) underneath the battery compartment and above the "wheelie" bars (which are attached to the back of the motor gear extensions) to FORCE the rear wheels where I wanted them. It seems to do ok but does not have the weight that the D cells hanging under the copper plate provided.
On a side note: from what I've read today, the vision (openCV) software and camera being used with the pi model B+ looks to be (but I haven't tested yet) compatible with the brand new pi model 2. The power of the model 2 might allow for the decision software to be ported from the propeller to the new pi, I'll need to see after I get one.
As normal, suggestions?
END OF LOG ENTRY
The square silver "marble mania extreme" bars and their matching black connectors have proven to be a reliable building structure for the upper unit. Impact testing shows they survive 90% of the time. The K'nex assembly did not have the same results (would come apart and sometimes broke the ends). IMPACT testing is required because the upper assembly falls in those "didn't design the software for that event". The nice thing is the cameras (raspberry regular DEV-11868 and noir DEV-12654) are easy to bolt on the adafruit pan & tilt assembly, which can be attached (I used 4x40 nylon bolt and nuts) to the silver bars. The silver bars come in different sizes, of which one is exactly the correct size to mount a raspberry pi (I'm using a 1B+ and a 2). The same silver bar can also be drilled to handle a prop board.
I've attached a custom arduino to the raspberry pi expansion port using a custom I2C interface (base design documented on the arduino site). The pi can command the arduino the drive the pan & tilt servos to move the camera. It also can command the same arduino to drive a second pan & tilt assembly that has various LEDs (color banks). The arduino is also responsible for setting the desired color, as commanded.
Each pi-EYE (and it's arduino, servos, camera, and light source) reports to a common single prop, via serial line (using multiple copies of the serial object as I'm not COG over-used).
The lower unit (FEET) is an arduino mounted on a modified two wheel & skid plate toy, using three picaxe-08m2 with bi-directional IR assemblies.
The prop coordinates the EYE's, and FEET. Communication with the FEET is with a matching set of three picaxe-08m2 (and associated bi-directional IR).
For now I've removed the Cypress pSoc5. The Cypress was doing the "THINKING", but that effort was downsized and simplified then placed into the prop.
As normal, suggestions?
END OF LOG ENTRY
How about some pics at least? You'll get more replies & comments if people can see what you are describing.
Without pics, it's pretty hard to suggest anything.
Moving up or down and then stopping on a steep incline plane has some real issues. Keeping the ball (FEET) from rolling and maintaining balance, while trying to keep a fixed location. The incline plane can not be real smooth as the ball looses friction, so I painted some marine skipsand surface on it. But as the angle gets bigger (more than 30 degrees) just stopping and holding location becomes a problem. Putting LONG arms with extended weights (like the pole for tight rope walkers) is no help. Hmmmmmmmmmmmmmm ?
As normal, any suggestions?
END OF LOG ENTRY
It is National Robotics Week, time for everyone to show some pics & video of their projects. Come on, GrandeNurse, play ball!
I'd bet that if people could actually see what you're working on, this thread would be much less of a monologue.
Edit: jump to 15:45 to see it function.