Moving forward, I'm injecting some requirements to make the thing useful:
A. EVE (IT) must be able to move over a level flat tile surface at a speed of at least one foot per two seconds without falling over
B. EVE (IT) must be able to move over a standard door threshold (3 inch wide, 1 inch tall, not an incline plane) within 30 seconds without falling over
C. EVE (IT) must be able to move over a non-level putting green like surface, with a max incline of 30 degrees (in reference to level) at a rate of at least one foot per two seconds without falling over
D. EVE (IT) must be able to carry at least a two pound object (size of a soda can) as a payload at a height of at least two feet above the floor and still meet requirements A, B ad C
E. EVE (IT) may be allowed to use a docking platform for loading and unloading payload (EVE does not need to pick-up the payload off the floor)
These basically allow the thing to go get a small glass of milk from a floor based mini-frig and bring it outside. Navigation, door opening, obstacle detection are left up to the different implementation designs.
A real world application might be: go get an insulin pen, or go get some type of medication and bring it out to a person in need but not in distress.
I've been wanting to do a balance bot for a while, specifically a wheel bot. Once I get this one behaving itself, I'll see if I can add the other dimension. A couple of Vex omni-wheels and a small kids ball should serve as the drive easily enough.
Moving across the door threshold (an obstacle that doesn't move) seems to be a Collision problem in physics. There is a bit of inelastic collision due to the hardness of the materials involved, and redirected forces (ball with forces on the floor and the threshold, while the threshold is redirecting some of the balls forward moment force back towards it). Drive up to the threshold and stop then it seems to not have enough power (friction, torque, ...) to get over the threshold. Lean into the threshold (with training wheels because the systems response is not fast enough yet) and then try to get over it and sometimes it makes the crossing (mostly not). Lean AND extend a weight over the threshold and it gets better success but still not 100%. BUT Drive fast enough and the balls forward force will overwhelm the redirected force from the threshold and run across it (threshold), BUT has a tendency to BUCK off the tri-wheel base. Placing HOLDING arms that extend from the tri-wheel base DOWN over the ball look to be (I've not taken the time to fabricate the arms & rollers) an option to keep the tri-wheel from being BUCKed off.
WELL I was concerned about BALANCE and wondered if I could find anything useful in HUMANs that I could port over to this simple little robot (inner-ear balance detection, muscle response, .....). I now need to worry about dementia!
"Balance problems are an early indication for dementia and Alzheimer’s disease, according to Dr Li Wang and fellow researchers from the University of Washington. In an published article entitled : Performance-Based Physical Function and Future Dementia in Older People Li Wang, MS; Eric B. Larson, MD, MPH; James D. Bowen, MD; Gerald van Belle, PhD. Arch Intern Med. 2006;166:1115-1120, the University of Washington researchers studied 2,288 over 65 year old people who at the onset of the study showed no signs of dementia. People were enrolled from 1994 to 1996 and followed up through October 2003. A 6 year period. After six years 319 individuals had developed dementia, 221 of them had Alzheimer’s disease."
Yes I think the little robot has dementia as it has balance issues and doesn't seem to remember what I asked it to do.
WRT bumps, this Airwheel video shows it going over some rough Terrain at the beach. Probably helps that the rider is flexing his knees to absorb some shock. https://www.youtube.com/watch?v=0ceXcijODLo
I'm editing some one else's ball bot web picture as a discussion basis:
Adding the FINGERs from the tri-wheel base down over the ball would help keep the bot from bouncing off the ball.
The fingers would also provide a mounting point for an IR send/receive sensor [RED circle in picture] (to communicate with the heavy motor system inside the ball [see previous post for concept]).
Adding shocks/springs to the upper assembly might help in absorbing the impact energy [BLUE ovals in picture].
uhhhh, lets try changing the payload a bit:
.....from:
...............D. EVE (IT) must be able to carry at least a two pound object (size of a soda can) as a payload at a height of at least two feet above the floor and still meet requirements A, B ad C
....to:
...............D. EVE (IT) must be able to carry at least a HALF pound object (size of a SMALL soda can) as a payload at a height of at least ONE OR MORE feet above the floor and still meet requirements A, B ad C
CAREFUL when making the stock tri-wheel motor control board HUM when changing over to a 9 DOF. At least mine died when the software watched the 9 dof and tried making the stock board drive the motors at a high rate as the system bounced over a sequence of obstacles. My guess is balance and motion due to the bounce oscillation got the wrong results.
Guess it's time to replace the stock board with a custom set of three H bridges. I have made these before but was trying to keep the base unit stock (well mostly, I did remove the motor control processors and solder my own control wires for the three motors and three sensors).
As a note, I did not get this failure when I was using the BALL-balancer thing, could be the reaction of the ball did not see all the vibrations that the 9 dof does.
My implementation with the BALL-balancer thing (CROME ball bearing moving in a 4" ABS end cap with three side touch contacts) did not use any filtering (just checks for a TAP verses TOUCHing). The mass of the BALL seemed to help absorb some of the energy that the system was being exposed to when trying to cross an obstacle (door threshold, ...). The 9 DOF sees everything, so some Averaging or Filtering is a must.
Looking back though the forum:
"http://forums.parallax.com/showthread.php/126312-Balancing-Bot?highlight=ball+balance
post #16
Hanno wrote:
Big bots are easier to balance than short ones- try balancing a broomstick on your hand, then a pencil.
It's relatively easy to get a bot to balance in place for up to a minute. It's much more complex to have it moving around for an extended time. The key is to quickly and accurately control the motors.
You really should use a gyro and accelerometer- fused using a Kalman filter. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Motors should be relatively powerful and strong, with minimal backlash- and they must have decent resolution."
Has anyone else got their single ball bot to balance, if so what about moving across an obstacle?
Well since this looks more like a LOG book with experiments (success and failures), I'll post my current status:
1. Tomorrow I'll try to etch and assemble a replacement THREE motor H-bridge control board for the tri-bot (don't really care if it is form fit replacement) with sensor power control (the original wow board could turn the sensors on and off for power saving).
2. Next week (assuming #1 works) I'll integrate both the 9 DOF + FILTER "9DF" and the older BALL-balancer "BB" sub-systems, where BB is an override (and check) of the 9DF
I'll just be happy (and possibly terminate the effort) if the rebuild system can safely move across the obstacles (and if it does, I might even try a ERCO figure 8 across the threshold, but don't hold your breath for that).
For anyone that is still trying, picking up things from the floor using a single ball bot is like trying to get into a canoe FROM THE SIDE without sinking it. It seems to take a lot of counter-balance and timing.
Thanks, but I only shoot video when there is a functional product. I will post when it's time.
Currently the bot has had three major rebuilds, based on changes to structure needs and design sub-assembly relocations. There are multiple processors (BS2=tri-bot-motors+sensors, Prop=9dof+BALLb+convert+EMIC2, Arduino=lower_unit-motors+RFrx, Cypress-psoc=camera_vision+RFtx) because I find it easier to not worry about timing / integration issues, just a few communication / signaling things. A final version can not afford the power consumption that these things are doing. The robot claw (sparkfun stuff) use to be controlled by the arduino but was removed when I went to the TWO locomotion sub-assemblies (tri-bot up, little motor thing in the lower).
The main bot ball use to be a yellow rubber PLAYGROUND ball but now is a MICHAELS two part hollow Styrofoam bigger ball (about 12"). The lower locomotion unit can fit inside the center of the Styrofoam ball. It is arduino based and gets commands from the RF. I could not find a low cost clear plastic ball so I went to the two-piece Styrofoam. It was too much effort to glue DOLLAR store plastic salad bowels together for the lower unit because I had to brake them to get to the arduino after a test. This also meant that the communications had to change from IR to RF.
The IR concept was great (at least I liked it). The upper tri-bot based system rode on-top of the bot ball and commanded the lower unit to go / stop .... Three IRs were setup around the bot ball. IR1 would pulse (SONY format) a command, and the receiving IRx (Picaxe-08M2) unit would inform the arduino. The arduino would now know what it's orientation was in respect to the upper tri-bot (IRtx1 sent but IRrx2 received). The arduino could also respond back to the upper tri-bot based BS2 (via a picaxe-08m2) so it would now know it's orientation in respect to the arduino. That really helps when the upper tri-bot system wanted to go FORWARD and it knew the arduino was 180 degrees turned from it's direction. This also allowed the upper tri-bot to "scamper" on the bot ball, the upper unit only needed to stay on top (balance). Anyways that went away because the IR doesn't work with the Styrofoam ball.
Now the lower unit receives a command (via RF) and performs that task. The upper unit needs to figure out what the lower units orientation is based on how it has to react. Example: UPPER commands GO FORWARD, lower starts moving FORWARD (as it sees forward), the UPPER now notices that it is moving sideways (lets say to the LEFT), so the UPPER commands STOP and updates it's movement table (I want this ===> translated ===> you do that). This TWO part system is more complex but allows the BULK weight (batteries and a 3lb scuba weight) to be very low and that weight is directly on the drive motors.
The bowling ball experiment (mentioned early on in this thread) told me that the bot was going to have a real problem trying to change the speed/direction of MASS that it didn't directly control. Looked to be a lumber jack on the river log issue, the person could change it's (the log) speed and direction as long as they keep Center-of-Mass, Friction, and Momentum in check.
Anyways one of the H-bridge circuits didn't come out of the acid tank correctly (I think the operator didn't verify the coating), so I'll try to etch again tomorrow.
LOG ENTRY: "DOWN THE STAIR STEPS design issue test":
OK maybe I should have done this test way back when we started this thread. "Sit on the top stair step holding your processor with your tilt detector and an attached LCD" Start bumping down the steps like your ball bot should (that means you don't fall over). Just slide forward until your BUTT falls to the next lower step. Notice the display? Yep the accelerometer/gyro says Z axis movement but then when you hit the steps it repots (incorrectly to my thought process) a bunch of X and Y axis movement which really didn't happen. Changing the G force setting helps but does not eliminate it.
Try the BALL-balancer thing (the ball bearing rolling around in a 4" ABS pipe end cap with three side wires via copper tape). The balls bang around (taps not touches; touch is a long contact a tap is a short pulse) but don't show the same issues. But you still get some banging taps signals until they settle down.
Try something from your past, a two pot joystick. You know that thing that you moved in an X Y plane so the video game would move. Hang it upside down, with a BRASS weight screwed onto the handle (I had to thread the handle ad drill/tap the brass weight). It can only respond to X Y axis movement and the weight helps dampen any sideway errors (noise).
Now just slide across the floor (sit on a piece of carpet and have someone / something pull you). NOTE I'M TESTING FOR TILT (falling over). The accelerometer/gyro shows mostly correct signals, the BALL-balancer shows correct signals, and the X-Y-pot shows correct signals.
While sliding suddenly stop. All three show some signal due to the change in speed (deceleration). The X-Y-pot was the only one that did not report FALLING OVER (I defined specific angle ranges of tilt as UPRIGHT, TILITED, an FALLING OVER). The bot must react to a FALLING OVER signal to prevent the event. The bot just uses UPRIGHT and TILTED as informational. I should note that the BALL-Balancer only reports FALLING OVER or MUST BE OK.
LOG ENTRY: "integrating BALL-balancer with X-Y-pots ad 9dof"
Running full speed toward an obstacle and hitting it, results in the X-Y-pot and BALL-balancer and 9dof showing FALLING OVER status momentarily but they quickly recover. The rate and duration of the three different technologies differ. This provides a BASIS for VOTING. If three sources claim some event at the SAME TIME then it may be true. When three sources keep changing their status then the event is a FUZZY probable.
END OF LOG ENTRY
Experiment result: was able to move across the obstacle with the addition of VOTING and motor control changes. Was not able to repeat the result in a sequence of tests (1 in 5).
LOG ENTRY: "Bullet Technique"
Increase probability of crossing obstacle by putting the upper unit into a slight spin (moving "around" in a circle while staying on top of the ball) before encountering obstacle. The lower unit (motor unit inside the ball) is still moving forward toward and across the obstacle. I think the spin helps detract the impact on the balance detectors (9dof, BALL-balancer, X-Y-pot) and may redirect the net combined SYSTEM level forces.
I believe the "Bullet Technique" is really a simple Gyroscopic implementation, much like a correctly thrown football pass (with spin) or a spinning TOP.
Experiment 12: "Drag just the logic / sensor assembly (upper unit) across driveway loaded with sand and large pebbles / rocks"
Results: 9dof & BALL-balancer had a lot of signal spikes (BALL-balancer started TAPping balls on all three contacts), but X-Y-pot was reasonably (I could average out the noise) good signaling.
Experiment 13: "Float just the logic / sensor assembly (upper unit) on mini-surf board in small pool, with variable wave period an amplitude"
Results: X-Y-pot and BALL-balancer could get into an oscillation (that did dampen) present after the waves ended / passed. 9dof had better performance (could average out any spiking).
Suggestion: If the accelerometer show spikes above amplitude ACC-NOT-TO-TRUST (experiment 12), or BALL-balancer shows results BANGING-AROUND (experiment 12) then rely on X-Y-pot while the condition exist.
If the X-Y-pot AND BALL-balancer has developed a PERIOD-OF-OSCILLATION (experiment 13) AND accelerometer averaging is less then ACC-NOT-TO-TRUST then rely on accelerometer while the condition exist.
I think the outline of the new (to my code) system looks like the following:
X-Y-pot SENSOR signals ===> averaging =========> TRUST CHECK ==+
BALL-balancer SENSOR ===> averaging =========> TRUST check ====+
9 dof sensors ============> kalman filtering =====> TRUST check ====+======> VOTED SYSTEM ATTITUDE CONDITION ==> SYSTEM DECISION ==> upper unit motor response
..........................................................................................................................................................................................................................+++++++++++++++ ==> lower unit motor command
A sensors that has failed a TRUST CHECK has a TIME duration penatily. It only needs to be NON-VOTING for LIMIT duration.
The sensor data collection and averaging/filtering still continues even while the sensor results are being ignored due to the NON-VOTING time duration.
SYSTEM DECISION module:
Inputs: Last known Attitude, Current voted Attitude, Last commanded Upper Motor, Last commanded Lower Motor Unit
Decision to make:
STATE "attitude is UPRIGHT (currently set at up to 10 degrees)"
...command UPPER motor response to the VOTED attitude
STATE "attitude is more than Correctable = FALLING-OVER (current set at 45 or more degrees)"
...stop all motors and put out arms because we are going to FALL OVER
STATE "attitude is tilted (not UPRIGHT and not FALLING-OVER)"
...can it be maintained by a UPPER motor response to the VOTED attitude, if so DO IT
...otherwise
...compute change in LOWER unit motor needed and send command
...UPPER motor response to the VOTED attitude
LOG ENTRY: "Bullet Technique"
Increase probability of crossing obstacle by putting the upper unit into a slight spin (moving "around" in a circle while staying on top of the ball) before encountering obstacle. The lower unit (motor unit inside the ball) is still moving forward toward and across the obstacle. I think the spin helps detract the impact on the balance detectors (9dof, BALL-balancer, X-Y-pot) and may redirect the net combined SYSTEM level forces.
END OF LOG ENTRY
Anyone reading these ?
I'm reading every entry though I have nothing to contribute except kudos to what you have been doing.
I've not tried this effort before, so like all new endeavors I'm bound to make mistakes (due to something that I didn't know before). I've switched to the LOG ENTRY / EXPERIMENTS format to try to find the fundamentals that I need to validate. The results should help design a system that has a much better chance of success.
If I was a government contractor I would work to a GOOD detailed Requirements document that also ends up in a Test document. Currently I'm trying to discover the requirements via testing.
NOTE: a GOOD requirement might be "before physically contacting a wall the bot will stop without damage".
a BAD requirement might be "the bot will not brake under any situation" (sounds more like what you find in the Statement Of Work).
With all that said, does anyone see a test / experiment that should be performing?
Comments
http://www.hizook.com/files/users/3/Balancing_Robot_Applications.jpg
Riding around?
http://asimo.honda.com/ASIMO_DCTM/News/images/inline/U3-X-Uni-ball-1989.jpg
A. EVE (IT) must be able to move over a level flat tile surface at a speed of at least one foot per two seconds without falling over
B. EVE (IT) must be able to move over a standard door threshold (3 inch wide, 1 inch tall, not an incline plane) within 30 seconds without falling over
C. EVE (IT) must be able to move over a non-level putting green like surface, with a max incline of 30 degrees (in reference to level) at a rate of at least one foot per two seconds without falling over
D. EVE (IT) must be able to carry at least a two pound object (size of a soda can) as a payload at a height of at least two feet above the floor and still meet requirements A, B ad C
E. EVE (IT) may be allowed to use a docking platform for loading and unloading payload (EVE does not need to pick-up the payload off the floor)
These basically allow the thing to go get a small glass of milk from a floor based mini-frig and bring it outside. Navigation, door opening, obstacle detection are left up to the different implementation designs.
A real world application might be: go get an insulin pen, or go get some type of medication and bring it out to a person in need but not in distress.
I've been wanting to do a balance bot for a while, specifically a wheel bot. Once I get this one behaving itself, I'll see if I can add the other dimension. A couple of Vex omni-wheels and a small kids ball should serve as the drive easily enough.
J
Awesomer name. WOBL-E. ROFL. Wall-E meets War Games' WOPR!
Urban Glider: https://www.youtube.com/watch?v=M51s-xa4q1Q
Solowheel: https://www.youtube.com/watch?v=e_-um9BU8Q4
Airwheel: https://www.youtube.com/watch?v=Ivai7qOQq4s
ANY ideas about getting a ball over a threshold ?
"Balance problems are an early indication for dementia and Alzheimer’s disease, according to Dr Li Wang and fellow researchers from the University of Washington. In an published article entitled : Performance-Based Physical Function and Future Dementia in Older People Li Wang, MS; Eric B. Larson, MD, MPH; James D. Bowen, MD; Gerald van Belle, PhD. Arch Intern Med. 2006;166:1115-1120, the University of Washington researchers studied 2,288 over 65 year old people who at the onset of the study showed no signs of dementia. People were enrolled from 1994 to 1996 and followed up through October 2003. A 6 year period. After six years 319 individuals had developed dementia, 221 of them had Alzheimer’s disease."
Yes I think the little robot has dementia as it has balance issues and doesn't seem to remember what I asked it to do.
Adding the FINGERs from the tri-wheel base down over the ball would help keep the bot from bouncing off the ball.
The fingers would also provide a mounting point for an IR send/receive sensor [RED circle in picture] (to communicate with the heavy motor system inside the ball [see previous post for concept]).
Adding shocks/springs to the upper assembly might help in absorbing the impact energy [BLUE ovals in picture].
Comments?
.....from:
...............D. EVE (IT) must be able to carry at least a two pound object (size of a soda can) as a payload at a height of at least two feet above the floor and still meet requirements A, B ad C
....to:
...............D. EVE (IT) must be able to carry at least a HALF pound object (size of a SMALL soda can) as a payload at a height of at least ONE OR MORE feet above the floor and still meet requirements A, B ad C
since no-one ever comments, this should be ok.
Guess it's time to replace the stock board with a custom set of three H bridges. I have made these before but was trying to keep the base unit stock (well mostly, I did remove the motor control processors and solder my own control wires for the three motors and three sensors).
As a note, I did not get this failure when I was using the BALL-balancer thing, could be the reaction of the ball did not see all the vibrations that the 9 dof does.
Looking back though the forum:
"http://forums.parallax.com/showthread.php/126312-Balancing-Bot?highlight=ball+balance
post #16
Hanno wrote:
Big bots are easier to balance than short ones- try balancing a broomstick on your hand, then a pencil.
It's relatively easy to get a bot to balance in place for up to a minute. It's much more complex to have it moving around for an extended time. The key is to quickly and accurately control the motors.
You really should use a gyro and accelerometer- fused using a Kalman filter. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Motors should be relatively powerful and strong, with minimal backlash- and they must have decent resolution."
Has anyone else got their single ball bot to balance, if so what about moving across an obstacle?
1. Tomorrow I'll try to etch and assemble a replacement THREE motor H-bridge control board for the tri-bot (don't really care if it is form fit replacement) with sensor power control (the original wow board could turn the sensors on and off for power saving).
2. Next week (assuming #1 works) I'll integrate both the 9 DOF + FILTER "9DF" and the older BALL-balancer "BB" sub-systems, where BB is an override (and check) of the 9DF
I'll just be happy (and possibly terminate the effort) if the rebuild system can safely move across the obstacles (and if it does, I might even try a ERCO figure 8 across the threshold, but don't hold your breath for that).
For anyone that is still trying, picking up things from the floor using a single ball bot is like trying to get into a canoe FROM THE SIDE without sinking it. It seems to take a lot of counter-balance and timing.
Would really like to see any recent video, figure 8 or not. What you are attempting is very difficult.
Currently the bot has had three major rebuilds, based on changes to structure needs and design sub-assembly relocations. There are multiple processors (BS2=tri-bot-motors+sensors, Prop=9dof+BALLb+convert+EMIC2, Arduino=lower_unit-motors+RFrx, Cypress-psoc=camera_vision+RFtx) because I find it easier to not worry about timing / integration issues, just a few communication / signaling things. A final version can not afford the power consumption that these things are doing. The robot claw (sparkfun stuff) use to be controlled by the arduino but was removed when I went to the TWO locomotion sub-assemblies (tri-bot up, little motor thing in the lower).
The main bot ball use to be a yellow rubber PLAYGROUND ball but now is a MICHAELS two part hollow Styrofoam bigger ball (about 12"). The lower locomotion unit can fit inside the center of the Styrofoam ball. It is arduino based and gets commands from the RF. I could not find a low cost clear plastic ball so I went to the two-piece Styrofoam. It was too much effort to glue DOLLAR store plastic salad bowels together for the lower unit because I had to brake them to get to the arduino after a test. This also meant that the communications had to change from IR to RF.
The IR concept was great (at least I liked it). The upper tri-bot based system rode on-top of the bot ball and commanded the lower unit to go / stop .... Three IRs were setup around the bot ball. IR1 would pulse (SONY format) a command, and the receiving IRx (Picaxe-08M2) unit would inform the arduino. The arduino would now know what it's orientation was in respect to the upper tri-bot (IRtx1 sent but IRrx2 received). The arduino could also respond back to the upper tri-bot based BS2 (via a picaxe-08m2) so it would now know it's orientation in respect to the arduino. That really helps when the upper tri-bot system wanted to go FORWARD and it knew the arduino was 180 degrees turned from it's direction. This also allowed the upper tri-bot to "scamper" on the bot ball, the upper unit only needed to stay on top (balance). Anyways that went away because the IR doesn't work with the Styrofoam ball.
Now the lower unit receives a command (via RF) and performs that task. The upper unit needs to figure out what the lower units orientation is based on how it has to react. Example: UPPER commands GO FORWARD, lower starts moving FORWARD (as it sees forward), the UPPER now notices that it is moving sideways (lets say to the LEFT), so the UPPER commands STOP and updates it's movement table (I want this ===> translated ===> you do that). This TWO part system is more complex but allows the BULK weight (batteries and a 3lb scuba weight) to be very low and that weight is directly on the drive motors.
The bowling ball experiment (mentioned early on in this thread) told me that the bot was going to have a real problem trying to change the speed/direction of MASS that it didn't directly control. Looked to be a lumber jack on the river log issue, the person could change it's (the log) speed and direction as long as they keep Center-of-Mass, Friction, and Momentum in check.
Anyways one of the H-bridge circuits didn't come out of the acid tank correctly (I think the operator didn't verify the coating), so I'll try to etch again tomorrow.
OK maybe I should have done this test way back when we started this thread. "Sit on the top stair step holding your processor with your tilt detector and an attached LCD" Start bumping down the steps like your ball bot should (that means you don't fall over). Just slide forward until your BUTT falls to the next lower step. Notice the display? Yep the accelerometer/gyro says Z axis movement but then when you hit the steps it repots (incorrectly to my thought process) a bunch of X and Y axis movement which really didn't happen. Changing the G force setting helps but does not eliminate it.
Try the BALL-balancer thing (the ball bearing rolling around in a 4" ABS pipe end cap with three side wires via copper tape). The balls bang around (taps not touches; touch is a long contact a tap is a short pulse) but don't show the same issues. But you still get some banging taps signals until they settle down.
Try something from your past, a two pot joystick. You know that thing that you moved in an X Y plane so the video game would move. Hang it upside down, with a BRASS weight screwed onto the handle (I had to thread the handle ad drill/tap the brass weight). It can only respond to X Y axis movement and the weight helps dampen any sideway errors (noise).
Now just slide across the floor (sit on a piece of carpet and have someone / something pull you). NOTE I'M TESTING FOR TILT (falling over). The accelerometer/gyro shows mostly correct signals, the BALL-balancer shows correct signals, and the X-Y-pot shows correct signals.
While sliding suddenly stop. All three show some signal due to the change in speed (deceleration). The X-Y-pot was the only one that did not report FALLING OVER (I defined specific angle ranges of tilt as UPRIGHT, TILITED, an FALLING OVER). The bot must react to a FALLING OVER signal to prevent the event. The bot just uses UPRIGHT and TILTED as informational. I should note that the BALL-Balancer only reports FALLING OVER or MUST BE OK.
Well anyways its just a school of thought
END OF LOG ENTRY
Running full speed toward an obstacle and hitting it, results in the X-Y-pot and BALL-balancer and 9dof showing FALLING OVER status momentarily but they quickly recover. The rate and duration of the three different technologies differ. This provides a BASIS for VOTING. If three sources claim some event at the SAME TIME then it may be true. When three sources keep changing their status then the event is a FUZZY probable.
END OF LOG ENTRY
Experiment result: was able to move across the obstacle with the addition of VOTING and motor control changes. Was not able to repeat the result in a sequence of tests (1 in 5).
Side note: erco may have some support that can be derived from his new thread http://forums.parallax.com/showthread.php/157978-DIY-Sphero
Increase probability of crossing obstacle by putting the upper unit into a slight spin (moving "around" in a circle while staying on top of the ball) before encountering obstacle. The lower unit (motor unit inside the ball) is still moving forward toward and across the obstacle. I think the spin helps detract the impact on the balance detectors (9dof, BALL-balancer, X-Y-pot) and may redirect the net combined SYSTEM level forces.
END OF LOG ENTRY
Anyone reading these ?
Nonstop, my friend! Keep up your excellent work.
Experiment 12: "Drag just the logic / sensor assembly (upper unit) across driveway loaded with sand and large pebbles / rocks"
Results: 9dof & BALL-balancer had a lot of signal spikes (BALL-balancer started TAPping balls on all three contacts), but X-Y-pot was reasonably (I could average out the noise) good signaling.
Experiment 13: "Float just the logic / sensor assembly (upper unit) on mini-surf board in small pool, with variable wave period an amplitude"
Results: X-Y-pot and BALL-balancer could get into an oscillation (that did dampen) present after the waves ended / passed. 9dof had better performance (could average out any spiking).
Suggestion: If the accelerometer show spikes above amplitude ACC-NOT-TO-TRUST (experiment 12), or BALL-balancer shows results BANGING-AROUND (experiment 12) then rely on X-Y-pot while the condition exist.
If the X-Y-pot AND BALL-balancer has developed a PERIOD-OF-OSCILLATION (experiment 13) AND accelerometer averaging is less then ACC-NOT-TO-TRUST then rely on accelerometer while the condition exist.
END OF LOG ENTRY
X-Y-pot SENSOR signals ===> averaging =========> TRUST CHECK ==+
BALL-balancer SENSOR ===> averaging =========> TRUST check ====+
9 dof sensors ============> kalman filtering =====> TRUST check ====+======> VOTED SYSTEM ATTITUDE CONDITION ==> SYSTEM DECISION ==> upper unit motor response
..........................................................................................................................................................................................................................+++++++++++++++ ==> lower unit motor command
A sensors that has failed a TRUST CHECK has a TIME duration penatily. It only needs to be NON-VOTING for LIMIT duration.
The sensor data collection and averaging/filtering still continues even while the sensor results are being ignored due to the NON-VOTING time duration.
SYSTEM DECISION module:
Inputs: Last known Attitude, Current voted Attitude, Last commanded Upper Motor, Last commanded Lower Motor Unit
Decision to make:
STATE "attitude is UPRIGHT (currently set at up to 10 degrees)"
...command UPPER motor response to the VOTED attitude
STATE "attitude is more than Correctable = FALLING-OVER (current set at 45 or more degrees)"
...stop all motors and put out arms because we are going to FALL OVER
STATE "attitude is tilted (not UPRIGHT and not FALLING-OVER)"
...can it be maintained by a UPPER motor response to the VOTED attitude, if so DO IT
...otherwise
...compute change in LOWER unit motor needed and send command
...UPPER motor response to the VOTED attitude
I'm reading every entry though I have nothing to contribute except kudos to what you have been doing.
Keep up the good work!
If I was a government contractor I would work to a GOOD detailed Requirements document that also ends up in a Test document. Currently I'm trying to discover the requirements via testing.
NOTE: a GOOD requirement might be "before physically contacting a wall the bot will stop without damage".
a BAD requirement might be "the bot will not brake under any situation" (sounds more like what you find in the Statement Of Work).
With all that said, does anyone see a test / experiment that should be performing?