I am a retired engineer using accelerometers on a personal project.
I have developed a unique and novel way of finding the center of mass of odd objects using accelerometers. It is a three-dimensional virtual plumb bob. It can find the center of mass inside of a three-dimensional object. The process is simple and uses statics. No motion is required.
I want to make this unique process available for universities and other Drone and RC hobbyists. I hope you will find this process useful for your products and customers.
I have made the software free and available on GitHub.
The software program is written in MATLAB for an X frame drone. However, this program can easily be adapted for use on any odd object.
I am makeing a version for use with the IMU of ArduPilot and PX4. I don’t know where or how ArduPilot uses this information. I know how to format the informaton for PX4, but I don’t know where, how, or what format does ArduPilot use.
For PX4 software I provide the distance from each motor ( X Y and Z) to the CoG. Is this correct fot ArduPilot?
If the location of the IMU is known, its distance to the CoG can be calculated as well.
Physically measured motor distance is never used directly in AP. The motor matrix assumes a geometry based on selected frame type and scales thrust accordingly.
For IMU measurements, it takes the direct offset into account, per linked documentation above. For thrust scaling, it assumes a symmetric geometry, and the control laws loop fast enough to compensate for lack of feed forward based on mass distribution.
(this may be overly simplified, but it’s enough information for you to understand what data is important to the parameter set for ArduPilot)
At one point I was thinking about whether I can estimate the CoG of the vehicle based on the IMU values in a hover executed in a position hold mode, maybe rotate the vehicle at least 180 during this test flight to cancel out external disturbances.
If you know the geometry of the frame. You could put it in stationary flight and hold the postion. Look how hard the motors are driving and calculate CoG in the X and Y plane….no wind.
I think the best, for now, is the CoG distance from the frame center (AP) and then the distance from each motor to the CoG. (PX4)
What gave me this idea, 10 years ago, I had a QX350 with a mount for a GoPro. The drone was set up at the factory. No way to make any adjustment to the flight controller. When making fast and hard maneuvers, the control laws loop was not fast enough. The drone would rotate about the z axis and then snap back to the correct heading.
Without the camera, it was great! A real blast to fly.
“Sensor Position Offset Compensation The sensor’s position offsets are specified as 3 values (X, Y and Z) which are distances in meters from the IMU (which can be assumed to be in the middle of the autopilot board) or the vehicle’s center of gravity.”
How do you place the IMU if you don’t know where the CoG is?
If the IMU is not at the frame center then the user will have to input its location or they can move it to the CoG.
It’s located where you install it. And if you didn’t install it at the CG, that’s exactly what the offsets are used to adjust. Your question is circular logic.
If your method assumes the IMU is located at the CG, then it is fundamentally flawed, as this cannot be guaranteed (and why would you be measuring…as the location is already known…).
To install the IMU at the CG, you’d have to measure/balance the craft to find the proper location.
If the IMU is installed somewhere other than the CG, then you still have to measure the 3-axis offset to determine proper measurement scaling.
In practice, this is often fairly inconsequential, especially for smaller vehicles. If the IMU is located roughly in the center of a multi-rotor frame, it’s probably good enough. On larger, more exquisite vehicles, the CG should be well characterized via good design practice such that physical measurements validate the design specs/requirements. Such measurements are usually done with calibrated load cells and inclinometers, not via MEMS IMUs, and the results can be used to properly configure the firmware parameters.
If I understand correctly the is no requirement for the IMU to be at the GC for this method to work.
In general for copters so long as the CG is roughly in the center of the motors its fine. You may have issues in either high or low throttle saturation cases if it is not, but mostly this is not a problem and the control system deals with any offset without anyone noticing.
The ArduPilot parameters for IMU to GC offset are used to correct the accelerometer readings for effects caused by the rotation of the vehicle. Again these are mostly fine at zero. If your IMU is more than 1/4m or so you might start seeing a noticeable difference when there setup correctly. There is a upper limit too, if the IMU is more than a meter or so from the CG the corrections can add more noise than they remove and your better off setting a smaller value that the true distance.
Where I see this method being more useful is on fixed wing aircraft where the CG location is much more critical, however its much harder to rig up a way to hang them.
The go-to way to calculate the CG, apart from trying to find the balance point by hand, would be to use “corner weight scales” where you measure the weight on each landing gear leg and then calculate the CG location relative to the known gear positions. Of course this method cannot get the vertical CG location but you do get he total weight of the vehicle.
What would be very useful would be to extend this method to be able to extract the rotational inertia with a swinging step. Typically a swing test would isolate each axis independently, but it maybe be possible to isolate the axis in post from several tests from different swing points.
