Why would chip manufacturers decide to provide output data in 2’s compliment? I’ve been having loads of issues with reading data from the ADXL345 and the ITF-3200.
At least the ITG-3200 has 16bit resolution so getting a 2’s complement value from it is as simple as using BitConverter.ToInt16().
The ADXL345 however provides only a maximum of 13bit resolution. Sending 13Bit data into BitConverter simply returns a positive number between 0 and 8191 instead of the correct 2’s compliment value of +-4095
Luckily I found StackExchange’s Electronics forum and some people in the know could set me straight. See 13-bit 2's Complement on .Net MF.
Why would they even do this? Surely it would be simpler to just output a UInt value between 0 and the Max Resolution. Surely it’s simpler to just apply an offset than to go through all the bit shifting. To make it worse it seems that different processors seem to deal with BitConverting differently. From example code that I’ve seen, the Arduino boards handle the Byte to Decimal conversion much easier than the .Net boards.
If the ADXL345 simply output data between 0 and 8191 I could just take that data and subtract 4095 and have my value.
In any event, I think I have made some progress again. I suspect I might also have my Most Significant Byte and my Least Significant Byte reversed when using BitConverter on either my Gyro's or the Accelerometers which is why I am getting very unstable data from my IMU for very small physical changes. Anyway, I hope to test this theory and also implement my new 2’s complement understanding tonight.
Beware of .Net Garbage Collector Debug Messages
Another issue I have resolved is with the .Net Garbage collector debug message. To date I have been running my code on my FEZmini board in debug mode. When you run the code via Visual Studio the output window shows the garbage collector output every couple of seconds.
I assumed that this processing would be suppressed if a debugger is not attached to the board (I.E. running it without Visual Studio). Alas, this is not the case. My IMU (while seemingly approaching some level of stability) would twitch every couple of seconds. This seems to be due to the Garbage collector debug code executing from time to time. 2 options here: Either disable the debug GC messages and/or run in Release mode.
Debug.EnableGCMessages(false);
The twitch is now gone, so hopefully once I have the 2’s compliment issue sorted out, everything should be working [better].
|
Saturday, 14 June 2014
Why 2’s compliment?
Busy couple of weeks
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.
Anyway, an all-around busy couple of weeks.
|
Placing the ESC's
I've now reassembled TriRot to a state where the arms are in place on the bottom chassis plate so that I can place the ESC's in position as designed. Although I did leave room in the 3D model for cabling, the wire-tree for the power distribution is a mess.
Hopefully, I should be able to get the ESC's bolted down and wired up at which point I still need to find the I2C addresses of the other two ESC's (Have I mentioned the pool customer support and lack of documentation?).
The next step is to connect the serial interface to the FEZmini to allow me to get telemetry from TriRot and control it vie USB. I'll make another video of the first lift-off although I don't expect that to be smooth or very spectacular (hopefully ;-).
|
Wire Nest
I spent the weekend soldering the Wire-Tree that will supply power to all the components to everything. As part of this I replaced the connectors on my battery with Deans Connectors.
I also created the cables for the I2C connections and soldered the cabling onto the ESC's for the other two motors. This means that for each motor ESC connection there are 7 wires of variable thickness running somewhere. Times by three, equals, 21 cables that all have to fit through 1 or both of the 10mm holes in the upper and/or bottom chassis plate and then somehow route past mounts and circuit boards etc. I think the main reason why most of these things are not built smaller is because of wire routing.
Anyway, enough with the rant. I guess I can't really be annoyed with my own design. but this might be a good time to reduce the chassis plate weight by cutting some sections out of it that are not required.
The next step is figuring out what the addresses of the other two ESC's are (still with no response from their support department or descent documentation).
Once I have all three motors spinning up nicely, I can start working on the flight software. To do that I need some way to control TriRot. The options at the moment are to buy an XBox350 Crossfire to use for the rest of the development phase or to just buy the Tx/RX kit that I will eventually fly with. With a TX/RX kit, I get one way communication but if I couple a pair of XBee modules into the equation I will be getting full duplex data between TriRot and the controls. The only downside (if you can count it as a downside) is that I would have to take a notebook with me to fly TriRot.
Any suggestions and/or comments welcome.
|
TriRot first motor test
Okay, so after absolutely no help from the manufacturers, I finally had to write a short app to step through all possible I2C addresses to find the address for the BL_CTRL_v1.2 (I would not recommend this part because of the total lack of customer support or descent documentation).
So I shot the first video of TriRot today as promised to those that follow me on twitter (@gineer). In this video I run to motors in a program that slowly ramps up the speed, but I only use the first byte of the 11 bit resolution for the speed. This equates to 0-255 of 2048. These little motors are amazing.
Now on to the source code: Not finished, but if you fill in the minor blanks, it will work. The ESC has none of the address jumpers soldered so it is effectively configured for "address 0" which apparently equates to 0x29.
Microsoft C#.Net
0: using System; 1: using Microsoft.SPOT; 2: using Microsoft.SPOT.Hardware; 3: using System.Threading; 4: 5: namespace Tri_Rot_Version_1 6: { 7: public class BL_CTRLv12I2C : IDisposable 8: { 9: #region Private Variables 10: private I2CDevice BL_CTRLv12; 11: private I2CDevice.I2CTransaction[] xActions; 12: #endregion 13: 14: #region [Con|De]structor 15: public BL_CTRLv12I2C() { } 16: #endregion 17: 18: #region Public Properties 19: #endregion 20: 21: #region Public Methods 22: public void StartUp(Motor motor) 23: { 24: ushort I2CAddress; 25: switch(motor) 26: { 27: case Motor.Left: 28: I2CAddress = 0x29; 29: break; 30: case Motor.Right: 31: I2CAddress = ???; 32: break; 33: default: 34: I2CAddress = ???; 35: break; 36: } 37: 38: InitialiseBL_CTRLv12(I2CAddress); 39: } 40: 41: public int SetSpeed(int Speed) 42: { 43: if (Speed > 2048) Speed = 2048; 44: else if (Speed < 0) Speed = 0; 45: 46: //break speed into 2 bytes and send; 47: } 48: 49: public void Dispose() 50: { 51: BL_CTRLv12.Dispose(); 52: } 53: #endregion 54: 55: #region Private Methods 56: private void InitialiseBL_CTRLv12(ushort I2CAddress) 57: { 58: I2CDevice.Configuration BL_CTRLv12Config = new I2CDevice.Configuration(I2CAddress, 400); 59: BL_CTRLv12 = new I2CDevice(BL_CTRLv12Config); 60: } 61: 62: private int WriteBL_CTRLv12Speed(Byte MostSignificantByte, Byte LeastSignificantByte) 63: { 64: int bytesTransfered = 0; 65: Byte[] SendBytes; 66: xActions = new I2CDevice.I2CTransaction[1]; 67: SendBytes = new byte[2] { MostSignificantByte, LeastSignificantByte }; 68: xActions[0] = I2CDevice.CreateWriteTransaction(SendBytes); 69: bytesTransfered = BL_CTRLv12.Execute(xActions, 1000); 70: return bytesTransfered; 71: } 72: #endregion 73: 74: public enum Motor 75: { 76: Left, 77: Right, 78: Rear 79: } 80: } 81: }
Let me know what you think!
|
TriRot in a box...
posted 5 May 2011 04:57 by David Taylor
No, TriRot is not dead, but I did strip it down completely in preparation for the installation of the Electronic Speed Controllers (ESC's).
No, TriRot is not dead, but I did strip it down completely in preparation for the installation of the Electronic Speed Controllers (ESC's).
It's actually been quite an Interesting week. One of the Tantalum Caps (indicated in the pic above) blew quite violently. I subsequently noticed that I had installed every one of the 4 tantalum caps the wrong way around. So last night they were de-soldered and fixed, and I also replaced the remnants of the blown cap with a shiny new one.
I also soldered some Pin Headers in place on my FEZmini in preparation for the serial coms cable (TTL-232R-3V3-WE) I bought. This would allow me to get some telemetry from TriRot while it is still tethered. This would allow me to have 1 USB cable for deploying and debugging via Visual Studio and another feeding (and potentially receiving) data for telemetry.
In the meantime I have tested the servo assembly, which moves the rear arm perfectly on the bearings.
Once the ESC's are installed and wired up TriRot would be mechanically complete enough to start flying (tethered to 1/2 USB cable(s) for now). I'll post video's when that happens.
No part of TriRot is simple
I haven't posted an update in a while because I have been battling with the silliest of things. I needed to get hold of some PCB Header pins sockets. These things are surprisingly hard to get hold of. Maplin have them, but they are almost always out of stock and then they also only have the ones with the guides on the side which make them to big to use on TriRot. I eventually bought a couple of ebay.
In the mean time, I tried to solder the power cabling which supplies 12V to the 3 ESC's, and to TriRots Control Interface Board. I am using 12AWG cabling which is the same cable attached to the battery and started simply soldering the cables into a star shape to distribute the wire, but this (in my opinion) just looks messy. So I did a bit of thinking and came up with the following solution.
Two rings inside the chassis to which I can solder the 12V and GND cables respectively. This distributes it nice and neetly and also keeps it all out of the way and keeps the weight down. This will be cut out of 2mm think alluminium sheeting and will be 2 mm thick. I hope that is enough to carry to current required.
Let me know what you think.
|
Subscribe to:
Posts (Atom)