I finally hooked up my Smart OSD to my new 2.5 FC, and running v2.02a I noticed my compass headings were allover the place, showing about 20 degrees of variation. I didn't notice this before in MK tools, but the 3D display also show the CS6 jumping around. I had a problem with yaw last week, and Cf was not working correctly, but was definitely setup to a switch. I thought it was me, but now I'm not so sure? No errors including Compass, but it seems something is not quite right. Re-calibrated compass at mark 80 on graph, but nothing changed. Never took off so didn't generate a SD card file. I did calibrate gyros though, and got the Radians and my Vid Tx running to see if made any difference but it didn't. The CS6_12_28_13.txt is my MKTools setup file. Is this normal?? Don't think it can be as I've never seen my OSD be so unstable with the Compass heading. It did straighten itself out once, but I'm not sure why, but it "reverted" again. Tried USB cable and not just Xbee also.
I’ve seen that with my SmartOSD, too. I just ignore it. The GPX file seems to disagree, and I trust that. I wonder if something in the firmware (sampling rate?) is driving the SmartOSD bonkers.
Thanks Steve. Seems to be in MKTools too? I'm not exactly sure what compass Z axis is telling me. My 3D in MKT is also jumpy, and it didn't used to be? Also it's telling me my speed is between zero and 8, when sitting still.
Gary: Were you indoors or outside when you were doing your testing? The SOSD sits on the IC2 bus and interprets the data going between the NC and FC -- if the data blocks on the FC 2.5 have a slightly different format (and it would be controlled by the software on the FC and NC), then it might be confusing the SOSD. Andy.
Andy: Both inside (compass z data jpg) and outside (at80 Jpg). The compassZ data jpg was USB (skipping the OSD, I think?). Plugged the USB directly into the Navi. The at80 JPG was Xbee. I took the CS6 out side, ran MKTools, then calibrated the compass. There wasn't any difference really, OSD hooked up or not? I just initially noticed it because the SOSD compass was acting crazy. Maybe I'll unhook the SOSD and try it again. Supposed to rain tomorrow, it will give me some experimenting time.
I've sent and email to Irek, the author of the code for the Smart OSD reporting the problem that you've discovered. I've asked him whether he has heard of other people having the same issue with the compass swinging wildly. By the way, what version of the firmware are you using on the Smart OSD, please? Thanks Andy.
Andy: Not sure of the firmware on the OSD, and can't get the OSD manager to connect, even with usb. Not unusual. EDIT: DL latest Smart OSD Manager, worked great, updated firmware to lastest: 2.34 BUT I also have the 20 degree variance on Magnet Z data, without the OSD plugged in. ie: I hooked the USB ribbon to the Navi board. I also noticed the CS6 dada showed it was "traveling" when it is not. Perhaps it is a GPS data changing? This is another jpg showing the "Magnetic Field [18] screen and the Z data. Going to update my MK Quad now and see if it is similar. I have the 2.5 FC on the CS and 2.1 on the Quad. Update two: Appears my MK Quad is showing similar data on Compass Z and Ground Speed. From zero to 20 cm/sec. (About 1/2 mph) Guess it could be GPS? I'll go out tomorrow and see how they do outside, and reexamine the OSD. Anybody else see their Navi screen [2] showing their copter moving 20 cm/sec?
Nothing heard from Irek yet. Glad to see that you got the 2.34 firmware installed. The GPS data does tend to show the copter wandering around -- especially if you're indoors, or even outdoors depending on the Kp Index....that's why it tends to fly in small circles (aka toilet bowling). Let me know what you find. Andy.
I have noticed a variance on the OSD for quite a while. I especially notice it doing power changes, which suggests that my motor wires are leaking a magnetic field. I have also seen my copter "travel" 30 feet before while on the ground during high solar activity. The problem is that we rely on one singe GPS receiver of commercial standards not for flying applications. Unlike aircraft that have GPS receivers they also use inertial guidance as well to back the navigation up from small changes. We dont use any of the MEMS sensors to normalize lateral movements. I am guessing this is due to lack of processing power with the MK setup. An ideal controller would be one where the NAV board also have its own 3D MEMS gyroscopes and Accelerometers mixing that data into the NAV system. That would solve GPS variations as well as heading variations and allow for crisper more normalized movements and stable hovers. Until these things get incorporated we will stuck with imprecise hovering and GPS functions.
The problem is that the MK GPS is not a commercial grade system IMO. That combined with the lack of processing power in the MK electronics makes it less than ideal. Someone posted a little while ago someone selling what looked like MK knock off boards with claims of huge increases in processing power. If I remember correctly the cost was 10X of the MK stuff.
That'd be me. I found that one company. http://www.service-drone.com/en-gb/technology/multirotor-flight-control I did some research just now and we are using one of the baseline standalone GPS receivers from Ublox called the LEA-6S It has been replaced by the NEO family which 3DR uses, the comparable radio is the NEO-6M. These radios are most likely used for cheap stand alone hiker GPS units that dont require super precision and continuous accuracy. They have a better radio in this line called the LEA-6R which is designed to handle other sensors for dead reckoning ie the inertial guidance that I was talking about before. Although it looks like Seimple-Drone is also using the Ublx 6S as well. However by looking at their NAV board it looks like the NAV board has dead reckoning sensors. So the NAV board is doing the calculations, which is fine, the current radio is probably adequate for initial positions. By combining those other sensors it will work more precise. Shaun
I would have thought it would have been out now because they showed pictures of it and made the changes to the software to accomodate it.
Well hopefully they are working on getting it right the first time, and not having these endless beta updates? lol That was crazy, as I had to use the "beta" just to get my 2.5 FC to work at all.
Hopefully it will be, but IMO I would not be surprised if the results are not a significant improvement. I believe the FC 2.5 is just a "Bandaid" fix to what really needs to be done hopefully FC/NC 3.X will have better capabilities in processing power with at least 32 bit processors on both systems.
Shaun I posted a question to Holger about any new GPS improvements. Here's the question and here's his response. [Q]Holger any plans on upgrading the current MK LEA-6S GPS? The newer LEA-6R combined with dead reckoning sensor upgrades for the Nav board it offers super precision and continuous accuracy over what we have. I know there are a lot of people that would pay the money for the upgrade. Thoughts? [A]"Dead reckoning" is useful for cars with wheel-sensors. That doesn't work in the air. We are waiting for samples of the newer LEA-8 module, that could have some benefits. Maybe you would like to extend the conversation, here's the link http://forum.mikrokopter.de/topic-45196.html
Thanks Dave but I can't post, because I can't sign up. It doesn't like my email addresses. (hotmail or gmail). I kinda gave up trying to get on there.
That's interesting. I asked him a follow up on why its not possible to have X and Y accelrometers to compensate for lateral drift in the same manner the Z accelerometer compensates for barometric gradient drift on the altimeter.