| Electronics > Projects, Designs, and Technical Stuff |
| 16bit inclinometer accuracy problem |
| << < (3/4) > >> |
| webgiorgio:
It's a solar tracker using a parabolic mirror, 2 degree off and the focal point moves out of the receiver tube, leading to a complete loss of performance. For the prototype on my desk I have a small DC motor, that moves at about 2 deg/s at the lowest speed. If the angle measurement is late, I stop the movement too late, and I overshoot the target angle. I would like to get the best out of my hardware, even if the application requires less (as the real solar tracker will move slower than my desk prototype, there is time for the average to build up a value close to the real value). |
| Rerouter:
For your requirements, I am a little confused why your motors would not have servo feedback, as that would exceed your requirements, Other sensorless multi-mirror systems tend to compare the output power / temperature vs the mirror angle, To make your actual system work, the normal solution is a 9 axis IMU, the gyro resolves accelerometer noise by subtracting rotations, the magnetometer helps subtract accelerations, and the accelerometer cancels out the drift of the other 2. |
| Kleinstein:
For a concentrating system better tracking makes sense. The delay due to digital filtering is perfectly predictable. So the software can compensate for this to a large part. |
| hasc:
The datasheet specifies 3 mg typical for "linear acceleration RMS noise" which in terms or angle would be about 3 mrad or 0.17 deg so your first plot of inclination looks about right, I think, unless the data was filtered. |
| Siwastaja:
I fail to understand what you do with the acceleration information. No matter how accurate, you can't use it for absolute positioning in the yaw axis (rotation around the surface normal of the earth), only against the gravitation vector, i.e., roll and pitch, so your tracker is still missing an degree of freedom. What is wrong feeding back from the power output? Because this Sun thing has a track record of following the theoretical path very closely, just feedforward the motion (i.e., open loop) based on the expected path, then feedback a tiny correction parameter based on the power output. If the whole system is moving in unexpected ways due to external interactions, you would need a truly capable IMU to track this motion. You could scan the area, finding the brightest spot, lock to it, and then start following, which would be fairly easy to do unless the thing moves regularly during operation. Gyros solve the responsivity problem as I have explained, but seeing you are actually driving motors, not sensing externally-applied motors, why not just use encoders to measure the axle rotation? Knowing the delay from averaged accelerometer, it's trivial to add the integral of the applied motor movement during that delay, to get exact real-time result. |
| Navigation |
| Message Index |
| Next page |
| Previous page |