TriRot is taking a Diet
So last week I finally got TriRot fully assembled so obviously, the first thing was making the motors spin up for a test lift-off. Bear in mind there was no control, so I tied TriRot down giving it only enough tether to not destroy itself during a simple motor burn test. I slowly increased the motor speed until, sow-and-behold, TriRot was actually capable of lift-off. However at this stage the battery was not being carried, but I think it would still achieve lift-off regardless. My concern was how high I had to spin the motors before achieving lift-off, so I figured TriRot also needed to go on a diet.
TriRot: Before at 595grams including the battery.
TriRot after the first step of the diet dropping 36grams. Notice the motor and rotor mounts.
Only afterwards did I do a bit of research and realised that my battery was flat to below 9v, which is the minimum you should drop a LiPo too. But the diet could not have been bad either way. The next steps would be to cut out the sections of chassis which is not needed.
Once that was done I started working on getting some useful data out of my IMU. I spent quite a bit of time researching the Kalman filter as described by Starlino in his "Guide to using IMU in embedded applications", but he loses me in the Gyroscope section. I eventually ported the Arduino code which Fabio (using the same Gyro and Accelerometer) ported from Startlino's implementation (which I found afterwards) to C#.
Even then the output was more noisy that my raw accelerometer data. I eventually figured there was a problem in Fabio's code where he divided the raw Gyro data by 14.375?!? In Starlino's discussion, he mentions that getting degrees/second from your gyro you should be using the following formula:
RateAxz = (Axz1 – Axz0) / (t1 – t0).
Once I did this, my IMU seemed to be producing better data. The only way I could get this data though was to run in debug mode and then copy the data to a spread sheet. I figure the debug print routines screw up the timing etc., so I'm still not fully sure the code works as it should, but as soon as I can prove it does, I'll post the code to that in C#.
FEZmini 1.3 COM2
I've also been trying to make my TTL-232R-3V3-WE cable work on COM2, but I just couldn't. Anyway, I eventually tested the code with a loopback plug between Tx and Rx bot on FEZmini and on the Cable directly and both seem to actually work.
At the moment I am therefore assuming that the problem is that I may have Tx and Rx reversed on the plug from the cable which plugs into FEZ.
Anyway, an all-around busy couple of weeks.
|
Saturday, 14 June 2014
Busy couple of weeks
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment