Nwanua Elumeze
Zach Johnson
Travis Presley
1.0 Introduction:
2 + 2 = 4, the simplest of math problems. Where did you learn that? Why are you sure that its true? Did you just memorize it in first grade? Or, do you have an intuition based on a physical example you saw in kindergarten? The Math Balance is a tool for teachers and museums to use to give that physical intuition to each student. Not only can this tool be used for simple problems like two plus two, but it also can be reintroduced in the next few years to teach algebra.
The Math Balance is a simple balance with labeled blocks of unit weight. Using this tool, simple problems can be posed like two plus two. Simply place two twos in the left basket, and ask the student “What does two plus two equal?” The child can play with the other blocks to try and get the beam to balance. If the child is getting frustrated that the three he/she thinks is the correct answer isn’t balancing the beam, they could hit the “?” button. The dial will display one instructing the student that they need to add a one block to the right side to balance. As they slowly learn they may be asked to consolidate items on the right so that three and one are not a correct answer, only four is.
Beyond simple addition, 2 + x = 4 is another problem that can be posed. By simply placing a two on the left and a four on the right, the teacher can ask the student “What is x, if two plus x equals four?” Again the student can simply work with the blocks to determine what the correct answer is when the beam is balanced. Also if they have trouble the “?” button displays the number they are off by.
This tool is just many in an arsenal of mathematical teaching devices including memorization, and math teaching software. It adds an additional level of the physical world to each problem that may help students that need to visualize each problem.
2.0 Design
Given the task, our project was broken down into three sections. The base to support the balance beams, their corresponding springs, as well as the computer monitoring the balance to provide the help. The unit weight blocks to be used in the math problems and placed in the baskets on the balance beam. The computation hangs on the upright beam and monitors two sensors that observe a change in the balance beam position and then display the hint when the “?” button is pushed. Each piece contains a large amount of detail and design. Each of the follow sections describe these pieces in detail as well as how they were iteratively designed.
2.1 Computation:
From the very beginning, we wanted this exhibit to feature a very strong coupling of computation and the physical aspects of the balance. The idea behind the computation in the exhibit was to determine the difference (in discrete block weights) between the left and right pans, and report that difference to the child in a non-ambiguous manner should it be asked. Rather than an intrusive and obviously present computation, we wanted the exhibit to appear very easy to use by hiding most of the electronics part of (figuratively and literally). As a result, the exhibit can be used without even being aware that it contains any computation: as long as blocks are placed and removed in order to balance the beam, and no help is sought by the child, he/she can easily benefit from seeing that 4+3+1 blocks on one side is equivalent to 8 on the other side. Seeking for help, however, reveals the background computational unit that has up until now, simply been monitoring the motions of the beam. In the same spirit of simplicity and "background", there is only one way that a child may interact with the micro-controller: a big bold button with a question mark on it. For example, if there are blocks marked 4 & 3 on the left pan, and 8 on the right pan, the exhibit will move the dial toward the left pan (to a position marked '1'), implying: "looks like we might need a 1 on this side". At the bottom of the dial face were three exclamation marks: another unambiguous way of saying there was too much weight difference on a particular side.
The task of keeping track of the beam position was put on a cricket, which quickly became overwhelmed by the demands of a real time method of tracking - this is why we eventually used a micro-controller.
During the initial design phase, there were several methods we wanted to use to keep track of the beam's position.
- Shine an infrared beam under each weigh pan and use a corresponding sensor to convert the intensity of the reflected light into a distance measure. The difference between the readings of either sensor would tell how much the balance beam has tilted. We discovered, after toying with this idea, that there would be far too little resolution (since the reflected light would not change much), and this method could be adversely affected by the presence and intensity of ambient light.
- Another reflective idea was touched upon: ultrasonic. Again, it was believed that this would suffer from the same problems of too little resolution; hence this idea didn't last longer than the time it took to suggest it and discredit it.
- If attention is paid to the center of the beam, one can see that it describes a turning circle as the beam tips one way to the other. We intended to take advantage of this by putting the shaft of a rheostat on a nut attached to the beam that would revolve along with it. This would result in a different resistance depending on how the beam was tilted; this resistance will then be interpreted by the cricket. This actually worked initially but was ultimately superceded by our final design for two reasons:
1. Even though the shaft was relatively easy to turn, it added just enough load to reduce our resolution to about 3 unit blocks... not at all a good thing.
2. The range of the potentiometer was either too small or too little for the cricket to interpret effectively. To make matters worse, there were regions of non-linearity what would have to be taken into account. With these disadvantages, and the fact that mounting the resistor would have required a very precise mechanism made it all the more unfavorable.
The idea of using the resistor can be pursued in future endeavors because it didn't require constant monitoring (unlike the other ideas): when the help button is pressed, the position can be directly obtained from the resistance value.
- At this stage, we needed a linear and reliable method of detecting the rotation of the "circle" described by the beam's motion: quadrature phase measurement. This involves a circle with slots in it, and two sensors positioned 90 degrees from each other. As the circle turns, the two sensors yield a waveform that looks like a 2-bit gray code. Depending on the direction, this mechanism would yield logic values of:
... 10 11 01 00 10 11 01 ... (one direction, and)
... 10 00 01 11 10 11 01 ... (opposite direction).
This is a well-proven method of motion detection: it's the same mechanism that tracks the position of a computer mouse. The trouble now was to obtain and use suitable sensors and wheel.
For the wheel, we asked for and got a gear whose patterns of teeth would suit the detection just fine. Initially, we wanted to use simple switched with rollers on them: as the wheel turned, it would press and release the switches, giving the desired pulses. As it turns out, not only did the switches add extra resistance to motion in one direction, the totally opposed rotation in the other, depending on how they were oriented. Crickey! We needed a way of sensing this motion and fast... two seemingly good ideas had turned to pot, and the presentation was just a week away! Fortunately, the code (which will be described later) for detecting this phase difference had been written and tested with handheld switches the week before, so that was not an issue.
Since we wanted as little contact between the turning wheel and the sensors (and with a flash of inspiration from thinking about a mouse while shopping for something entirely different), the idea of using opto-interruptors was hit upon. Opto-interruptors are a method of detecting when a direct path is blocked by and object or not, using infrared. The wheel had enough teeth and was just the right diameter to fit the ones I had bought (I had made sure to buy the widest sensors with this in mind).
Now, it was a piece of cake to connect these sensors to a cricket and monitor the analog values in software. Unfortunately, due to the limited speed of these devices, we would not be able to keep track of the wheel's rotation in real time. Couple this with my lack of patience with finicky devices and computers that crash ever so often, I asked and kindly obtained permission to move the project to a micro-controller with more computing power.
The micro-controller was one I had been introduced to in a previous class, and here was an excellent opportunity to do something really useful with knowledge gained from building the board from scratch. The two sensors were mounted on the main trunk of the balance, spaced to maximize the sensitivity to differential motion, with the teeth of the gear alternately interrupting the beam from transmitter to sensor. As the wheel turned, one sensor would have a transition about 90 degrees ahead (or behind) the previous one.
This state of transitions called for a state machine that would be put into a known state by sampling the sensors when it started: this way, the machine calibrated itself automatically...a feature which is essential to the fact that we didn't want the user of the exhibit to know anything about how the computation unit ran.
From any state, there could only be two transitions (i.e. from 11):
01 <- 11 -> 10.
Which transition was made determined whether a counter (imaginatively called "count") was incremented or decremented. The following fragment exemplifies this:
.
.
.
if (laststate == 11) {
if (state == 01) count++;
else if(state == 10) count --;
} else if (laststate == 10) {
.
.
.
As the gear was turned back and forth during testing, we could see the variable increase in one direction, return to zero, and continue in the other direction: we thought we were home free.
Unfortunately, as with any real-world-computer interface, non-linearities would show up and would have to be dealt with in software.
- Static friction (again!) could prevent a wheel from moving if a very small load change is made (adding or removing a relatively light block)
- As the beam tilts and the springs stretch, each spring introduces a non-zero component into the balance of forces. [cos(90) = 0, and cos(90+x) = cos(x) != 0]
These two problems were eventually resolved by empirically measuring the values produced by varying weight changes and using those values in the program to determine how far to move the dial.
The dial was connected to a low speed, high torque motor which was also controlled by the board. When the help button is pressed, the motor is moved in a direction for a duration directly related to the angle of the beam. Each time the help button was pressed, the state machine would reset to this new position: essentially zeroing itself out. This way, only relative motion (which is what is important anyway), was taken into account: "I have to move the dial 3 ticks CCW of this position).
2.2 Blocks:
A collection of blocks representing weights from 1 to 10 numeric units was required. These blocks were constructed from precut 11/2-inch wooden cubes obtained from Michaels Arts & Crafts stores. A cylindrical cavity was drilled into each block using an 11/4-inch Forstner bit. This bit permitted drilling a uniform cylinder to within 1/8 inch of the bottom of the block. The weight of each block was grossly adjusted by addition of 11/4-inch fender washers. The final weight adjustment was made by addition of lead shot. Any remaining void space within the cylinder was filled with cotton. The side of the block containing the cylindrical opening was then covered with a 11/2" X 11/2" X 3/32" piece of Basswood, which was glued in place. These Basswood covers were prepared using the laser cutter.
The weights of the blocks were measured on a kitchen scale. The response of the scale was fairly linear, but suffered from hystersis and a shifting zero point. The accuracies of the weighted blocks were confirmed on the balance itself before final gluing was done. It is estimated that the total weights of any combination of blocks, which add to make a given numeric unit, agree within plus or minus 2 grams.
2.3 Balance:
Wood is one of the simplest and durable materials we had access too. With it, and a few screws we were able to build the basis of our exhibit. About twenty feet of one by two inch pine was cut to form two legs, a cross beam, and the upright balance support. The two legs were constructed with stacked pieces and a gap for the cross beam to slide into. The cross beam is three piece of wood sandwiched together, with the inner section having a gap to fit the upright balance support. Thus to erect the balance from a stored state, you simply lay the two legs on your work surface, either the ground or a table, spaced about a foot apart. Simply slide the cross beam into the legs. That is the base. The upright balance support slides into the crossbeam. The upright support has several wholes in it to place the metal balance beam and the spring support metal plate. The balance beam attaches to the bearing bolt. The upper plate is attached with two bolts and the springs are hooked into the upper wholes. Once everything is attached the baskets can be hooked on the balance beam. While this may seem over done, it works great for situations in a school where an exhibit needs to be stored when not in use. The modular design allows it to be completely deconstructed and then tucked in any cabinet or storage area.
This final design for the balance evolved from a fairly similar origin. We found that a bearing on both the front and the back resisted the balance movement. We also found that when the balance had a difference of 3 units the bottom of the spring scales hindered the movement, so we raised the spring support and added chains to the bottom of the springs. With these minor changes we had our final design.
3.0 Evaluation:
This exhibit exploits the analogy between an arithmetic problem and a balanced lever to teach children to solve arithmetic addition problems. The child will come to understand that arithmetic concept of "equality" corresponds to the lever being balanced in the horizontal position. With this exhibit a child can be asked to solve an arithmetic addition or subtraction problem by determining the numeric unit block to be added in order to balance the beam.
When presenting a problem to the child, the pans affixed to each end of the lever beam contain blocks with different numeric units. The child is asked to select a block to add to one of the pans to balance the lever. While either pan could be heavier, it will probably be less confusing if the left pan is used for adding or subtracting numeric units. This is the convention used in textbooks for writing equations on one line of text, e.g. 5 + x = 8. The child guesses a numeric value for x and places a block having that value in the left pan. If the guess is correct, the beam balances in a horizontal position. If the choice is incorrect, then the beam will be tipped to one side or the other. Springs will arrest the beam at some point. The specific arrest-point depends on the amount of the weight imbalance.
If the child wants help with the solution, he/she can press the help button (?) and the pointer on the dial will turn to indicate a number, either 1, 2, 3, or (!!). The reading indicates the numeric units to add to a pan. The double exclamation points indicate that the imbalance exceeded 3 numeric units. If the dial pointer turns counterclockwise, blocks should be added to the left pan. When the dial turns clockwise it may be more confusing to the child. It means that blocks should be added to the right pan. It may be necessary to explain to the child that adding blocks to the right pan is equivalent to removing blocks from the left pan. However, with a small amount of initial experimentation, the child should be able to discover this principle with his/her own efforts.
It might have been helpful if a mechanical means had been provided for arresting the beam motion while setting up a problem. The child could press a Release button to free the beam and see the results of his/her guess.
The exhibit was constructed in a modular fashion. We found this extremely desirable. The base is easily disassembled. The computer can be readily removed from its holding bracket. With a bit of difficulty the metal beams can be disconnected from their vertical support. There is a bit of instability between the vertical support and the base, but it was judged to be inconsequential. If necessary this instability could be corrected with a couple of bolts. The only non-modular features are the dial and the help buttons, which were glued directly to the vertical support member.
We tested many different combinations of blocks, which summed to equal numeric values, to verify that they would accurately balance.
We evaluated the software, which converts beam displacement to dial-pointer rotation for many different combinations of blocks, with imbalances favoring either pan. The displacement readings were calibrated to give accurate pointer rotations to indicate the numeric units corresponding to the imbalance.
From our results we believe this system to be accurate, stable, and reproducible, subject to the caveat that, due to time pressure, long-term reproducibility testing was not possible.
Unfortunately, our testing did not involve children as users. Certainly, this type of input is desirable, and had it been available, would likely have precipitated some redesign leading to usability improvement. Nevertheless, we feel that this exhibit can support and enhance the teaching of addition and subtraction to young children. It provides a physical realization of abstract arithmetic rules. In addition the exhibit permits and encourages individual exploration by the child.
4.0 Conclusion:
Rather than a crutch, we wanted a helpful guide that helps only when asked, and does that in a very unambiguous, easy to understand manner. We feel that by interacting with a child in this manner, the balance helps the child learn algebra (albeit limited in scope) without the heavy-handiness of "this is what it must be, so memorize it". Rather, the child is free to try to balance the weights on her own and learn by being inquisitive (how any child learns best), and only when she feels frustrated does she have to press a button (clearly marked) which allows the exhibit to suggest the answer. We prefer that the exhibit suggests the answer by implying: "you would need 3 on that pan to balance this equation", rather than "you must have 3 to balance the equation".
If I was to do this over, I would consider having a single tray for blocks, and a digital display (or a single dial) that shows a number (1 - 10). One side of the balance will be "weighted down" by applying enough power to a motor to give the desired torque. The child would simply have to fill the balance with enough blocks to yield an answer. This, I believe would remove the possible confusion that can occur if there are several blocks on each pan, at the cost of limited flexibility.
We feel very strongly about the role that an exhibit/automaton should posses in relative terms with a child: allow for exploration of options, and provide concise help when requested. By interacting with the exhibit ourselves, we feel that it succeeded in allowing us to "learn" differences between weights, providing just enough, and not overbearing feedback.
In comparison with the different ways arithmetic is currently taught and illustrated to children, it is easy to see that this method is a welcome complement, which uses equally sized blocks to show the importance of weight and the value of numerals.
5.0 Appendix:
/*
Balance code... written for 8051 uC. 2001, Nwanua */
#include
<8051io.h>
#include
<8051reg.h>
#include
<8051bit.h>
void
movedial(int dir)
{
/* if dir is non-zero, move the motor
in the specified direction
for a specified
duration... then turn it off before leaving
this function */
if (dir > 0) {
setbit(P1.4);
clrbit(P1.5);
delay(abs(dir));
goto _moff;
} else if (dir < 0) {
clrbit(P1.4);
setbit(P1.5);
delay(abs(dir));
goto _moff;
} else {
_moff:
setbit(P1.4);
setbit(P1.5);
}
}
int
dohelp(int count)
{
int position;
/* debounce the switch (solidly
pressed) */
delay(80);
if(P1 & 0x08)
return 0;
/* "scaled" position... the
springs combined with
* rotation give a non-linear
result... need to compensate:
*/
if (count == 0) {
position = 0;
} else if (count >= -2 &&
count <= -1) {
position = -1;
} else if (count >= -4 &&
count <= -3) {
position = -2;
} else if (count >= -6 &&
count <= -5) {
position = -3;
} else if (count < -6) {
/* overflow... no chance of
knowing where to return to,
so make
sure we can return to zero at least */
position = -4;
} else if (count >= 1 &&
count <= 3) {
position = 1;
} else if (count >= 4 &&
count <= 5) {
position = 2;
} else if (count >= 5 &&
count <= 6) {
position = 3;
} else if (count > 6) {
/* overflow... no chance of
knowing where to return to,
so make
sure we can return to zero at least */
position = 4;
}
/* 800 is a nice constant */
movedial(position * 800);
/* make sure switch was released */
while(! (P1 & 0x08));
/* successful */
return 1;
}
int
main()
{
char state, last;
int count;
/* make sure motor is off! */
movedial(0);
/* if there's a computer attached...
tell 'em "hello" */
serinit(9600);
printf("balance.... \n");
/* just so we know it's alive and well
*/
movedial(800);
delay(1);
movedial(-800);
/* configure up the port pins as inputs
*/
setbit(P1.1);
setbit(P1.2);
setbit(P1.3);
/* relative motor ticks... */
count = 0;
/* the initial state of the machine */
state = P1 & 0x6;
while(1){
/* looks like help switch
was pressed */
if (!(P1 & 0x08)) {
/* if switch
press was valid... */
if (
dohelp(count) ) {
/*
reset the state with the new position as a basis */
count = 0;
state = P1 & 0x6;
}
}
/* the state machine:
constantly monitor the state of the two sensors,
if there
has been no change, there's nothing else to do */
last = state;
state = P1 & 0x6;
if (last == state)
continue;
/* a given transition from
a given state yeilds a dec/increment */
if (last == 0) {
if (state == 2
&& count < 128)
count++;
else if ( state
== 4 && count > -127)
count--;
} else if (last == 2) {
if (state == 6
&& count < 128)
count++;
else if ( state
== 0 && count > -127)
count--;
} else if (last == 6) {
if (state == 4
&& count < 128)
count++;
else if ( state
== 2 && count > -127)
count--;
} else if (last == 4) {
if (state == 0
&& count < 128)
count++;
else if ( state
== 6 && count > -127)
count--;
}
}
}