I'm just starting to dig into load cells, but I think the gradual decline you were seeing may be attributed to "creep" which you see listed in the specifications of a lot of the load cells you can buy. My understanding is that it will level out over time if the weight is left on continuously, but is just something you have to expect and work around for immediate readouts.
I don't know what you are talking about, but the "gradual decline" of the average is because the first few values are anomalously large. So the solution is just to ignore the first few values and only then start averaging.
@@will2see Nah, there's more to it than just the initial readings being off. Like my comment from a couple years ago said, there's actually listed specs on load cells that you can buy to help you account for the creep of the load cell. Generally it shouldn't creep muh after the first 10-30 minutes, but that probably depends on the individual load cell specs.
@@noahjones7579 If you're talking about metals (or I think in some cases plastics?) getting deformed gradually under stress, then yeah, it's normally near melting point. But load cell creep is a real thing, has nothing to do with deforming or damaging the load cell, and as I mentioned before, is a well-known enough thing that manufacturers tend to give the specs for it with the load cells.
Oh yes!!! I've pondered over making a prop thrust test dyno giving graphable results, but have not had the motivation :P Can't wait to see this built! :)
As a programmer I know that "what the hell..." feeling when you left the average code in, I genuinely cracked up laughing at that. It's nice to be on the other end of it for a change.
Not sure if someone already mentioned this, but the likely cause of the raw values decreasing over time is related to a phenomenon called "creep." When you have a load on the force transducer, it physically deforms the material. The strain gauges are circuits that are placed on the material than enable you to measure the physical material deformation as a change in electrical properties of the circuit. The problem is that the mechanical deformation is not instantaneous. There is a time course for which it takes the material to respond to the applied load. So the output of the force transducer does not change instantaneously with the application of a load, but rather, the load cell output slowly increases at a given load. This phenomenon is called "creep". Creep is defined as the change in load cell output at a constant load, all other factors being constant (temperature, humidity, etc). Then there is a corresponding time course for which it takes the material to return to baseline following removal of the load. This means that the load cell output will continuously decrease upon load removal. Herein lies the problem. There is usually a significant hysteresis involved with the load removal process. This phenomenon is referred to as "Minimum Dead Load Output Return." Vishay has a really good article on load cells: www.vishaypg.com/docs/11864/11864.pdf There is a nice figure on page 2 of this PDF that shows what creep looks like.
I looked at these load cells a couple years ago when a friend wanted a Makiwara with a digital readout of force created. I got as far as finding the item and buying an arduino. That led to 3 failed projects past the flashy light hello world stuff. If I leave your videos on playlist while I sleep maybe it will slowly sink in.
It could be a bit jittery due to creep as mentioned below which could come from minor load cell voltage supply changes, possibly air currents or table vibration in the room, or possibly warming due to the small amounts of current running through the load cell to cause some warming. Load cells are resistors and dissipate heat.
Thanks for this encouraging introduction, I'm sure that many people will be more interested in Load Cells after seeing your video. It is important, though,, to understand Load Cells more precisely. They do not bend, and if they do, this is not measured. Well then, how do they work? The four thinnest pieces of alloy right above and below the two big holes holes act as four hinges, and while every hinge is bending, the arrangement creates a parallelogram where two hinges bend up and two hinges bend down.. So the measuring end of the cell is shifting instead of a bending. This is important, because if the cell would bend, the applied force would produce different readings dependent on the place the force is applied, while a shifting motion is immune to the location of the force entry. All four hinges are equipped with a variable resistor in a bridge configuration that adds all shifting, parallelogram motion, while the remaining small bending motion is even cancelled out (not measured). Pretty clever - and that makes the cells robust and reliable.
00:34 The reason for two holes is that it makes a parallellogram, making the loaded half stay parallel to the fixed half. So it does not bend ;) That is also he reason why it does not really matter too much where you put your weight (21:30 does not have to be the same point), especially if you fix a little plate to those two threaded holes, it should not matter too much where you put the object to be measured on that plate. I have no explanation for the fluctuation / decrease in value other than that it is a very, very low percentage of the total measured value. So I am inclined to say that the measuring current influences the temperature, and therefore the resistance of the strain gauge (which is in fact a variable resistor) because it's length changes some picometers... Inspired by this video, I am going to try this out myself soon! :)
thanks for sharing. i am building an arduino coin counter based on weight and I surpsrisingly had a difficult time figuring out how i was gunna code the load cell but this video made me realise it should be pretty easy. i bought a 10 dollar scale on amazon made by american weigh scales. since i wanted to have a platform to hack up rather than build my own tray for the load cell and everything.
Nice vid. I have been thinking of this to. Would be cool if you visualize the punch out speed with box2d with a small multirotor (not only quads) scaled to a human or trees or house standing next to it. Could maybe even set the weight, size, cell count and prop of the multirotor. And overkill: simulate throttle realtime from radio. Ooh and megaoverkill: online db of motors so you can test the feel of diffrent motors with your own multirotor. Ok, only in 2D.. But I would play with it. :).. Anyways keep the good vids coming. Nice work!
Thank you so much brother ..your Code solved my problem ... Previously the load cell was showing zero kg weight after Arduino reset. But your code solved that issue ..it shows Actual ( Current) value even after power off or Arduino reset... !! Thanks once again
Strongly agree with Jess Stuart, val should be float. I usually do val = 0.99 * val + 0.01 * read. It starts with a big error but it averages out. Other formula would be val = val + (read - val) / factor, where factor can be anything from 2 to 100, the lower the factor the more significant the last read is, and the faster it reaches the read value. I use this for ease functions, but it could be applied, to average the read during load changes.
If we convert the floating number to integer it will stay settle with one value. Then this will be equivalent to commercial weighing scales Also constant decrease is due to continuous average which leads to not to get settle in one value. Good experiment. Nice explanation
Excellent info, I picked up one of these and controller board from a coffee grinder and was wondering how I could make it work, I'll have a closer look at the board and see if it looks like this type of interface, hope so
Pretty stable output, however the deviation of sensor output always cause the offset and coefficient need to be calibrated within the program automatically, and the temperature is also a headache factor need to deal with.
I don't know if anyone has mentioned it or not, but a possible reason for the unstable values at 12:38 could be due to environmental vibrations. With the load cell being attached to a piece of wood, those vibrations will be transmitted to the load cell. I could be wrong, but thought I would share.
this is a cool little vid since im trying to throw together a cheap piece of kit to test strain gauges. try taking the raw data [83346720 etc] into a string, then knocking off the last 2 or 3 numbers for a more accurate and less 'bouncy' reading, yours doesnt need to be accurate down to 0.00000001
When i was need to get average value of analog measurement a took 3 variables; 1 - an array to keep last N values, 2 - counter 3 - average value (summ). The algorithm was pretty effective. While Counter less than N you fill the array with corresponding values, Cunter = Counter+1; Array[Counter]=value; Summ = Summ+Value; Average = Summ/Counter. When counter hits N is a tricky part. You subtract N from counter, then read value from array[Counter] and subtract this value from Summ, then you need to place new value on this cell, also you need to add this value to summ, and you will get your Avg. If you need more detailed explanation - send me a message, or reply here.
Very nice work and tutorial on load-cells. I admire your work. I would program it a bit different if was in your place. I would store the measurements in an array of size 100 or 1000, then print the average. The way currently it's done, it takes the first measurement with the heights weight, and the more your code runs, the less weight it gives to later measurements. Imagine if the first measurement was terrible, it would take a VERY long time to remove the noise from the first measurement(s). You can increase the array size if you want a less noisy average. Alternatively, you could use a low-pass filter implementation, with a long time constant. Then take the measurement after at least 5x the time constant you chose. Very nice video though! Keep it up.
If you're talking about 11:48 it gives equal weight to all values ever seen, which is what you want when measuring a value known to be unchanging, like when you're calibrating. When measuring a value that may be changing, you want something like at 18:22 . But yes, a moving average is the best - I just didn't want to make the code longer with extra details not related to a basic intro about load cells.
12:36 The reason the values are decreasing is a problem in your program. In the line where you are calculating val, you are performing an implicit type-cast from float to long when the assignment operator "=" is performed. This will truncate the fractional part of the float, always giving you a value of val that is slightly less than than the float value. These truncations errors accumulate in val and that is why it never stabilizes. Replace val with a float type variable "fval" in the averaging line, and the value should stabilize to an "average" value of cell (input). I tried this out with gcc, and it does indeed fix this problem. longs are 32-bit on arduino, that's why I used ints (32-bit) on my PC. See example code below. #include #include void waitFor (unsigned int secs) { unsigned int retTime = time(0) + secs; // Get finishing time. while (time(0) < retTime); // Loop until it arrives. } int main(void) { int cell=8000000,val=0; float count=0,fval; while(1){ count=count+1; fval = ((count-1)/count)*fval + (1/count)*cell; printf("%d ",(int)fval); waitFor(1); } return 0; } I would suggest using a moving average filter.
Yes, truncating a float gives you a value less than the float, but it does not cause it to continually decrease. For example 12.6 will truncate to 12, but it will not truncate to 11, unless the incoming float itself is less than 12 right? Anyway, I found out afterward that I can make it increase or decrease whichever way I wanted by placing a hot or cold object nearby and waiting a few minutes. See the link in the description.
I think you missed the point. "These truncations errors accumulate in val and that is why it never stabilizes." Even if you compensate somehow by placing a hot or cold object nearby, your algorithm still has the issue of accumulating truncation error.
I admit you're right that truncation errors will accumulate in val. But I still don't think that is the cause of the change we see in this video, since it will not become significant for a much longer time. I actually wrote a big comment here and then stupidly refreshed the page before submitting, but I have added the gist of what I said to the page linked to in the description.
Moving average would give you better result I think. 5 period or 10 period moving average will stabilize the result quite nicely. We look forward to your future videos on this topic.
interesstingly this cutout is on purpose not just 2 random overlapping holes. so it bends with both sides staying parallel, if it wouldnt be there it would bend on a slight angle which gives you different results if the weight its furhter away from the mounting holes, basically reading the torque created so it doesnt matter if its perfectly between them or slightly off
Hey, just some quick comments. You can probably avoid the weird ramp up to an accurate number by polling an initial val in the setup. Just move val above the setup and read it in once right after the begin in the setup method. Have you also considered a average of n number of previous polls? Grab a val array of n size, set them all to an initial poll in setup and then take a total / n of all the elements? Use an index and index % n to get the current position in the array. Cheers!
+Misha Mengisen I think the (0.8*old + 0.2*new) style averaging I'm doing behaves fairly similar to a real moving average, but without the memory requirements. Yes, it seems we need to ignore the first few readings entirely.
Also the load cell seems to read very high values for the first 2 or 3 cycles. Quick fix is to skip the first N read values. Better fix is to take a running average of N values. You'll probably want to take the running average anyways while measuring actual thrust.
The gooey is actually just to protect the strain gauges and the wires under it, and the working principle of strain gauges changing resistance is called "the piezoresistive effect"
One month ago I got the same idea. I ordered 2kg load cell from ebay, but it didn't arrive yet. You will be attaching motor directly? I plan to build L shape thing from aluminium square tubes and attach motor on one side and load cell on other side. I also plan to have more sensors as RPM and wattmeter. It should have automated mode too.
Could you please tell me the time-step of this code? Since you didn´t put a delay()... What is the default time-step it prints a value. Thanks a lot. Great tutorial
Hi iforce2d, I was interested in the rate of data acquisition for this setup. What portion of the code could be modified to increase the number of readings on the serial display per second?
Is there any way you could do a small number for averaging say, 10-sampling? Also, humidity and temperature DOES play a part but shouldn't mess with this particular experiment at the moment. I am just learning and have not yet constructed my test stand for rocket motor testing.
You’re getting inconsistent zeros because the weight of the free end of the unsupported aluminum is causing it to deflect and produce a tiny voltage difference
whereabouts you put the force on the load cell shouldn't matter too much, as the flexture is designed to keep the 2 ends parallel. it shouldn't matter where you apply the force, the amount of translation will be very close to the same
Depends how accurate you want to be I suppose - "very close to the same" is not the same as "the same". If the goal is to measure something accurately you'd want to place the load where the calibration load was placed.
anyway to stabilize my load cell readings? my load cell gives me data that has a 2000 difference (by just doing cell.read()) I have installed it onto a wooden plank end, my arduino is kinda old, and I may not be the greatest at soldering.
The counting down probably stems from casting the value to long (var) each step and loosing the decimal digits since they are cut off when casting, not rounded.
But the raw values are going down too. Besides, truncating a value doesn't somehow make it go down and down. For example, if we truncate 12.3 we get 12, but we don't get 11 unless the input value goes below 12 right? So for the truncated value to keep going down the input value must be going down.
I have a pocket scale, which is showing only zero, though I am pushing weight, so I opened it, and found, it can only measure negative if I push up, Is there a way to fix?
The complete video that illustrates all our Guidelines for the correct installation of Load Cells, Weight Indicators and Weight Transmitters within a Weighing System. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-cQtKeXBC25Y.html
I would suggest a combination of sliding average and rounding (i.e. smoothening/dampening). like in my example written for a slide pot: const float roundingDivisor = 100.; // two digits.. const int weightCurrentSliderValue = 1; const int weightlastSliderValue = 1; const int weightTotal = weightCurrentSliderValue + weightlastSliderValue; (...) // smoothen currentSliderValue = (sliderValue * weightCurrentSliderValue + lastSliderValue * weightlastSliderValue) / weightTotal; // round currentSliderValue = round(currentSliderValue / roundingDivisor) * roundingDivisor; // save current value lastSliderValue = currentSliderValue;
I hv a weighing scale n the display n other functs works... but no matter wat i put on it...the display stays at zero could my loadcell be faulty? How do i check if my load cell is faulty??
Hi, does anyone has this problem too (and maybe a solution)? I've got the same set up as in the video and I've got the load cell working insofar as it registers when a weight is placed on the cell. However, the value it gives keeps jittering rapidly and increases over time until (after a few minutes) the maximum value is reached (all bits from the amplifier are ones). When that has happened, I need to have it powered off for at least a couple of hours in order for it to give normal values again (which again start to increase immediately). I've tried different load cells, amplifiers and arduinos, but all give the same problem. Any solution would be greatly appreciated!
Hi, I have a little problem: I use Hx711 and Pro Micro, I try both the 4 wire cell, and also the 3-wire one with 2 resistors. But after using the test, which is fine, and running the scketch, the cells work fine, for 1 minute, then they go to "zero" and from there they don't move anymore. Even with DiView, I see it working, but for 2 minutes, and then they stop. Do you have solutions? Thanks for the reply.
+DutchRC Adventures Previously I was using one fluorescent light in the ceiling and one big LED bulb, now I'm using two LED bulbs. I need to work on this a bit more and get rid of those big glare spots on either side. Your recording setup looks pretty pro btw!
+iforce2d `Thanks brother (I give seminars on photography lighting, so I Should :P) The color of the lights I use is not perfect though.. I now use 4 LED spots with 2 white umbrella's in front of them.. Those umbrella do get rid of most of the nasty LED coloring.. lh3.googleusercontent.com/-ZckloEr8r4Q/VmIgVIoMs7I/AAAAAAAAAkU/1oU_u_jheH0/w761-h571-no/2015-12-05%2B00.12.28.jpg Offcourse the umbrella allso diffuse the light -> no hard shadows
At the begging of the video you mentioned that you are doing this in order to control the thrust produced by a motor , can you please upload or send me the the whole procedure ? that will be appreciated thank you !
Hey about the drift you talk about, som of it is from the formal there dont work, as we believe val = ((count-1)/count) * val + (1/count) * 150; Serial.print(val); Serial.print('\t'); count++; val = ((count-1)/count) * val + (1/count) * 50; Serial.println(val); count++; 150+50/2 = 100 and we get a number lower, down to 49 :) This one is just Slow, if the weight change, then it us about 17 measurement to get to the real number val = 0.5 * val + 0.5 * RawData; // take recent average i get the Average from the last 3, this work as good as if i use the last 4, and it is Fast :) val = (RawData+ last1 + last2) / 3; last2 = last1; last = RawData;
Seungho Lee They're usually marked to be used in one direction, but in reality, yes, albeit the calibration probably won't be correct when used in the opposite direction.
IMPEDB - Internet Motor / Prop / ESC / Database. Automated testing, submission and correlation with inexpensive open source standardized hardware and code. This doesn't exist yet, but it needs to. Manufactures will finally have a standard to compete with so efficiency and consistency can be improved. We've all bought a bunch of weird combos trying to get an edge... maybe now with some standardized data we can make intelligent purchase decisions based on science instead of guessing or taking specs for granted. Needs environmental monitoring, and part temperature logging & safety system.
Well, well - the reason I'm here is exactly the same interest. I'm also thinking of making a rig to measure thrust of various electric motors with various propellers. I'm also intending to couple it with an optical rev counter and ammeter. The Turnigy setup looks quite nice (I hadn't seen it before), but I want mine to do its test on model aircraft rather than on detached motors, so the force-measuring rig will have to be different. I see you originally posted this in March 2016. Did you complete the experiment, and what results have you had? Did you ever make any sort of temperature compensation, or did you simply decide not to stand a coffee too close to it? Another question - considering the jitter in the output figures, did you have the impression that a 24-bit A-D was overkill? Judging only from your video, It doesn't appear to have a sufficiently fine resolution. 24 bits is a count of 16.7 million! I had thought of just using the A-D converter in the Arduino.
Here's my thrust tester main video and docs: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-PfVJmci9IQQ.html github.com/iforce2d/thrustTester I was looking for a resolution of at worst 10g, ideally 1g. I think it's ok for that level of usage.
iforce2d - Thanks for the URLs. Haven't read them yet, but I will. With reference to the resolution, it's about what I thought. Dividing 5Kg by 2^24 gives a resolution of 0.3 milligrams. You can get 5Kg in 1g increments with 13 bits.
5kg is just the rating of that aluminium bar - the range within which it will bend enough without breaking. The ADC is measuring a tiny tiny change in voltage, caused by the tiny tiny change in resistance when the bar bends. It knows nothing about a 5kg range. Apparently even when amplified that tiny change is still so tiny that the 10 bit ADC of the arduino is not sensitive enough to be useful, otherwise I'm sure nobody would bother with those load amplifier things at all. en.wikipedia.org/wiki/Wheatstone_bridge