Is it possible to use Arduino to measure and integrate the drawbar pull of a miniature steam locomotive in order to calculate the amount of work done by the locomotive during a run. With this information together with the amount of fuel used allows calculation of the efficiency.
You presumably have a load sensor - preferably digital - in mind and the means of mounting it?
Hi, Don't you also need to know wheel rpm / movement ?? And time? Power is force * distance * time As I recall??? Like 1 horsepower is 550 foot pounds seconds.
Doing the Engineering Thing of "exploring the limits", you could have a sequence of drawbar force but what if the train never actually moved?
But maybe I'm too young to understand steam locomotives :)
Power = force * velocity (work done per unit time = force*distance/time)
Hi, this is an international forum, kg m s please, whats foot pounds seconds? lol.
If you can get drawbar force and measure track speed then the arduino should not have any problems doing the maths and taking measurements.
Tom… metrics for ever…
P =M*n/9,55, .(M = torque in Nm, n = rpm) -> W= M*n*t/9,55 or W = F*d, (F = force in N, d=distance in m) -> P = F*d/t t = time in s
In all cases above the multiplications should really be integrations because the numbers not being constant
Measuring force by mounting a stringauge should be possible. Preferable on the chassis then on the pushrod. Rotaion can be measured by a ir sensor detecting sections of the wheel
Thanks for replies,
Maths no problem, measuring distance travelled no problem. I can measure the instantaneous drawbar pull using a strain gauge, but how do I integrate this for the time of the run where the pull varies widely. Can the Arduino do the integration or do I have to insert some sort of integrator circuit. I have a vague sort of memory that an op-amp can be used for this. Does anyone know a schematic for this?
I would recommend doing the math in the arduino rather than with analog circuitry. Divide a circle into maybe 16 or more segments and calculate the push rods contribution to the torque based on angle and force and sum up over a full circle.
miniature steam locomotive
How miniature? Is this a real steam engine or a steam model that is electric driven?
The idea (or reality?) of a real miniature steam engine is really cool.
And links to this 'hardware' would be nice.
Glynne: Can the Arduino do the integration
Yes, it can do it easily. It is simple arithmetic and would only need a couple of lines of code to implement.
Thanks for all replies to my query, however none have been particularly useful. Perhaps I haven’t given enough explanation (I use the FPS system because these units were used when I was being educated.) The locomotives are 5 inch gauge weighing 200 to 500 lbs , developing of the order of .5 to 1 HP and are run on a track typically 1000 to 2000 feet length with gradients varying from 1 in 70 uphill a and 1 in 70 down hill,( so the draw bar pull may vary from negative to positive) pulling a load of 10 to 20 adults for a period of 30 minutes at a speed of 4 to 6 mph. During this time they do 500000 to 1000000 foot pounds of work with an average draw bar pull of 30 to 70 pounds and they burn 2 to 5 lbs of coal. I realise I can use the Arduino analogue inputs to measure the instantaneous draw bar pull using a strain gauge, but how do I integrate this in order to work out the average?
Nilton61 suggests “Divide a circle into maybe 16 or more segments and calculate the push rods contribution to the torque based on angle and force and sum up over a full circle.”
Which I don’t understand And PeterH says “Yes, it can do it easily. It is simple arithmetic and would only need a couple of lines of code to implement”
Unfortunately he doesn’t quote the two lines of code. I can’t find an Arduino command to calculate ƒ F dt
Can anyone be more forthcoming?
If you're measuring energy efficiency then you will want to integrate force over distance. That will need two inputs: force, and distance (position). The position you can determine from rotation of a non-driven wheel.
The integration algorithm you would use is a discrete integration: imagine plotting force against distance traveled, on a graph where force was the vertical (y) axis. The integral you're trying to calculate is the area under the curve. The discrete integration algorithm would estimate the area by dividing it up into a set of vertical columns. The area of each column is the width times the average height. The total area is just the sum of the area of all columns. This is much easier to describe with pictures, and I'm sure somebody on the internet has done that.
So, your code will consist of a global accumulator which is zeroed at the start of the integration and holds the result at the end, and some code to update that accumulator each time your position moves by your chosen column width. You would do the update in two parts:
Part 1: Estimate the average force during the current increment. Traditionally you'd do that by reading the force at the end of each increment and use the average of that sample, and the previous sample, as the average. I don't know how steady your force will be, and it might work better by measuring the force at a fixed frequency which is much higher than the integration interval and calculating the average explicitly.
long averageForce = forceSampleSum / forceSampleCount; // zero the average for the next sample forceSampleSum = 0; forceSampleCount = 0;
Part 2: Multiple average force by distance traveled to get energy, add that to the accumulator.
long energyDelta = averageForce * distanceTraveled; totalEnergy += energyDelta;
I haven't defined forceSampleSum,forceSampleCount, distanceTraveled. You would have code running at regular intervals which reads the instantaneous force and adds it to forceSampleSum, and increments forceSampleCount. DistanceTraveled is just the distance the vehicle travels between successive executions of this algorithm. For example it might be the circumference of the wheel used to trigger this calculation.
You will need to scale the forces and distances to produce sensible units, and you will need to arrange that the values were small enough not to cause numeric overflow in your accumulator of averaging variables, and large enough to avoid rounding errors being excessive.
As I figure it, the actual code is quite simple; the complexity is scaling, especially into those steam units!
Your distance input will presumably already have a unit to it - wheel rotations or partial wheel rotations. On each interval - which is therefore fixed - you measure the force and add it to your accumulator. You are integrating the force over that delta distance. That’s all that is necessary.
You do not need to perform the average suggested above because (apart from the endpoints, which are trivial), that comes out naturally of the steps (yes, this could be nicely visualised graphically!) And you do not need any multiplication at each step.
Again, the code is easy, it is the scaling and units that you need to figure out; how many of your distance steps per standard unit, and the calibration of the force sensor.
Paul__B: You do not need to perform the average suggested above because (apart from the endpoints, which are trivial), that comes out naturally of the steps (yes, this could be nicely visualised graphically!) And you do not need any multiplication at each step.
You seem to be assuming that the tractive force remains basically constant during each step. I expect that in practice it will have a lot of noise and variation within each sample and some work [u]will[/u] need to be done to calculate an average.
You definitely need to accumulate the average and not the initial or final value. If you fail to do that then you will over-estimate or under-estimate depending whether the effort is rising or falling within the step. (In maths terms, you would be calculating the upper or lower bound of the value, which could be significantly different to the actual value if the steps are large. The distinction only becomes irrelevant when the steps are negligibly small.
Sorry, I misread you slightly.
There is no point in "averaging" each interval by its start and end times because the end of one becomes the start of the next.
If you wish to go to the trouble of sub-dividing the interval by time and averaging that, then of course, you will need to do some calculation - a single division per interval as you say of the per-interval total by the number of measurements.
The main concern is of course, to avoid making measurements on the basis of the jolting of the carriages that happens in this situation and probably is more important at slower speeds as more can happen within each distance interval. Of course in general, you wish to have the distance interval as small as possible; a fraction of a wheel revolution.
Paul__B: There is no point in "averaging" each interval by its start and end times because the end of one becomes the start of the next.
There is a point, when your steps are not negligibly small. Draw it out for a non-constant Y value and you will see that accumulating the start or end value for each step does NOT give the same answer as accumulating the average. In one case it gives you the upper bound for the result; in the other case it gives you the lower bound. The [u]average[/u] is what you want to accumulate.
There would be no point if you were to take only a two point average from the start and end times, because they are common between successive intervals. Fair enough?
This is what i meant:
(All angles in radians, lengths in meters, The SI system simplifies calculations… )
The force (Fo) in the pushrod contributes to torque (M): M = RFocos(T) where R is flywheel radius and T is the torque angle.
The torque angle (T) can be calculated from flywheel advance(F): T = pi/2-F-arcsin(Rsin(F)/L) where L is pushrod length
If you assume that the torque is fairly constant during a small interval of flywheel advance (dF) the energy(W) transferred from the pushrod to the flywheel is: W = dFM.
If you put an encoder on the flywheel you can calculate the energy transferred to the flywheel during each advance interval. The size of the interval would be dependent on calculation scan cycle time, rpm and encoder resolution
Edit: I’m not sure whether the right term to use is push rod or connection rod. I hope the figure clarifies what i meant
Thanks PeterH and Paul__B All clear to me now. I've breadboarded the distance measuring device and it works OK. The Dynamometer car will have wheels of about 4 inches diameter so I'll be measuring the output from the load cell almost every foot or about 8 times per second over the 3 miles of travel(at max speed of about 6mph). I'll have to start experimenting with strain gauges to get the right sort of output for the Arduino.
Thanks again an regards
I did not see any links, but here is the Ruby, a simple little model: http://www.accucraft.uk.com/products/ruby-2-live-steam-0-4-0t/