Hi There,
I have a couple of Y6B 3DR frame copters. One of them seems reasonable with 3.1.3 code, although it seemed smoother with 3.1.2, but the other (identical HW setup) seems to have issues and will be the subject of this particular post.
Full calibration done, but not including CompassMot, as it seems the NAN issue is still there with 3.1.3?
Log file can be found attached:
[attachment=0]2014-05-03 18-35-37.log[/attachment]
You can see from the log file that upon Loiter being engaged the Throttle output is slammed to 100%. This is actually not always the case I am finding, but in this particular case it was. In other times when Loiter has been engaged there is certainly an increase in throttle, but not always a hard slam to 100%. However, in this particular case/log it was. As you can see I put back to stabilize within a second or two of engaging Loiter.
I notice in the vibration logs that there appears to be periods of relatively decent vibration, followed by periods that show a high degree of vibration, so wondering if that is contributing, although not sure why it would be vibrating so much worse than the other identical Y6 frame, (perhaps the very flexible props are playing a roll here?). Also, HDOP appears to be pretty decent throughout from a GPS perspective.
The other thing I am noticing is that even in normal Stabilize mode the copter’s motors appear to be “fluttery” is the best way I can describe the sound/motion.
Please advise what I might be needing to tweak here. Trying to rule out a HW prob.
Your log is corrupt. Please attach the .bin log from the SD card per the instructions in my sticky, but for now I’ll leave a few notes and questions based on what you’ve said:
3.1.2 and 3.1.3 are identical except for a tiny bugfix that has nothing to do with “smoothness”
Yes, see above statement. However, compassmot can still be done if you’re determined to do it. I can send you a patched version with working compassmot, or you can install the very latest development build, run compassmot, and save the compassmot parameters from that.
This is probably due to inaccuracy in the inertial navigation, which would in turn most likely be caused by vibrations. Specifically what props are you using? It is strongly recommended that you use APC slow flyers, as they are the most efficient props you can buy.
Probably rate D terms too high. Try autotune. Run autotune with the minimum amount of battery that you would normally use and no payload. Note that you should have working althold before you try autotune, however.
Hi jschall, thanks for the response. Unfortunately I cleared the logs after the download. I wondered about the corruption also as I notice that occasionally the IMU readings have large spikes in other logs I have seen (way outside what would be seemingly possible), when looking at the log in a text editor I noticed the IMU reading at the spike was due to an extra parameter that found its way into that log message.
Thanks for the info on the 3.1.3. I was hoping to compare the builds, but I guess there was no tag created for 3.1.2 so couldn’t compare the code to check.
I can make the change for the compassmot fix, I believe its just the protection in the loop with regards to checking against a divide by zero. Let me try rebuilding the 3.1.3 with compassmot fixed and redo the cal.
I’ll try and run an auto tune with my lighter 3S battery to see if that fixes the “smoothness” prob + perhaps move to stiffer props? I believe the 1245’s i’m using are slow flyer type, but I am thinking of picking up some from Foxtech (could try APC). The ones I have are:
APC slowflyer is the most efficient prop you can buy. The material it is made out of is far stiffer than the EPP props, while being thinner and more efficient.
// avoid division by zero if we haven't received any mag reports
if (_count[i] == 0) continue;
to the beginning of the loop inside:
bool AP_Compass_PX4::init(void)
…
for (uint8_t i=0; i<_num_instances; i++) {
// avoid division by zero if we haven't received any mag reports
if (_count[i] == 0) continue;
…
However, with using terminal in Mission Planner 1.3.1 I still see NAN’s reported. Not wanting to drift too off topic, but is there anything missing from the following process?
load build of 3.1.3 + above fix is present to Pixhawk
Start Mission Planner 1.3.1
Lipo connected to copter + USB connected
Push Pixhawk Safety button so it goes solid red
Connect to CLI terminal in Mission planner
setup->compassmot
increase throttle
observe nan values displayed in CLI updates…
nan’s written to params in compass_mot
I set the values back to 0 for now. Does this cal make a big difference? For now I’ll continue with the above (autotune etc) with compass_mot set to 0.
btw, I read in another thread you are working on a self cal of compassmot, don’t suppose that will be there in 3.1.4 (or whatever the next release is?)
Are you certain the fix is present? That should work.
Does it make a big difference? It depends ™. Where is your compass mounted?
Yes, I am working on learning: groups.google.com/forum/#!topic … dVlPipnxko
I am hoping to get it in by 3.2. I currently have the majority of my python code translated into C++, but I have yet to test it on a flying copter. Much like the EKF, it’ll probably run and log whether or not it is enabled.
Looking at the log in this particular case vibrations seem higher, i’ll check the frame later to see why that might be. Would that cause althold to do an erractic increase in height? As althold uses Barrometer rather than GPS and the wind was less than 5kmh then wondering if there might be a prob with the sensor?
Also, with regards to your earlier compass question I assume that you mean Pixhawk location? I know that the UBLOX 3DR GPS also has a compass but I thought that the pixhawk code currently hard codes the use of the pixhawk internal compass rather than allowing for an external one?
From the log I notice that when althold was enabled the altitude was being read as the coptor was increased in height, presumably meaning that the copter knew that it was increasing in height when in althold mode, just wondering why? Again vibrations are a bit high so will try and see if I can do something about that. Following is a plot of relalt and baralt both showing increase in height when althold was engaged.
Hi Jonathan,
Took another log today (having tightened up the frame where possible). Same condition seems to occur where a second or two into alt hold there is a burst increase in altitude, which I don’t allow to continue for more than a second or two more before taking control again (stabilize).
Captured the .bin from the SDCard and you can see two occurances of alt hold invoked, in both cases the same thing happens:
[attachment=1]9.BIN[/attachment]
The vibration does seem to still be a little high (which I can now only attribute perhaps the to the props I am using). However, even with this vibration I can’t explain why the pixhawk would seek a rapid increase in height when its Barrometer is telling it that it is gaining altitude. In simple terms from the log what I seem to see is:
throttle increase (bursty) -> translating to increase in height reported by Barrometer, but throttle does not relent.
So, regardless of vibration why would it be ignoring the sensor input which is telling it that it is increasing in height yet it continues to push throttle up to increase height even more?
Here is snap shot of the plot showing this:
[attachment=0]Baralt_vs_throut.jpg[/attachment]
I am noticing that that GPS is lagging a bit in Altitude response though, does GPS get used for alt-hold? Might that factor? I am basically trying to ascertain whether I have a bad HW part because the sooner I can show that the quicker I can get it replaced. If it is just based on barometer reading then I can’t explain why it is doing this from the graph plots.
Hi Jonathan,
It’s “possible” I may found something HW wise that is contributing to the issue.
Just to recap, I have two identical Y6B setups, both with Pixhawk & both using 3dr UBLOX GPS + compass. Issue occurs on only one of them.
I recently noticed that the copter that shows the burst height increase prob during alt hold seems to have a curious compass behavior. I never noticed it before because after performing compass calibration I assumed all was good as theoffsets seemed reasonable etc. However, what I am noticing is that when level the compass seems ok, but if you pitch slightly the compass direction starts to spin. To be clear I am not alterring heading (yaw) only pitch. This is NOT the case on the other Y6B, whose compass heading remains rock solid as the copter is pitched (by hand).
To try and isolate things I took the 3DR ublox from the “working” y6b setup and connected it up to the other setup and recalibrated the compass to get the new offsets. However, I continue to see the same issue. Reading that ArduCopter 3.1.4 indicated some potential probs on I2C are fixed and knowing that compass from ublox goes over I2C I tried 3.1.4 FW, but no diff. It seems the Pixhawk HW, in this case, may be somehow to blame?
Having said the above one “workaround” has presented itself. The internal compass of the pixhawk on the failing setup works fine. If I remove the i2c connection from ublox to pixhawk and recalibrate the compass once again (this time it would be using Pixhawk’s internal compass as I guess the code auto detects that no compass is attached to i2c) then the compass behavior seems ok. Meaning that if I now pitch the copter the compass heading does not spin.
Is it generally better to use the Pixhawk’s compass in setups like this where you could be using either 3dr ublox or pixhawk? Perhaps the i2c voltage is too high marginally on the bad setup from pixhawk to ublox, but marginally ok enough on the other pixhawk ublox setup? I’ll try alt hold test again with using the pixhawk compass instead and see where things are at.
ALT_HOLD holds altitude in exactly the same manner as loiter. It uses the height estimation from the complementary filter. If the accelerometers are bad, the complementary filter does not work.
How did you go with compassmot? I’m hoping to fix a few bugs and get a 3.1.5 release done.
Hi Jonathan,
Compassmot cal appears to work fine, in as far as it calibrates without giving me NAN’s anymore and I get what appear to be reasonable values in the compass mot params.
I continue to have issues with Alt hold so i am trying to go the very basics to see if I can figure out what is going on. In the vibration graphs provided on some of my flights I notice that I am seeing periods of good vibration interspersed with periods of vibration out of spec. I tried an experiment and perhaps this experiment is not valid, but it seemed to be an obvious thing to try:
Powered the pixhawk up through USB connection only (no battery connected to minimise any sort of EM noise).
Armed the copter and increased throttle to 50% in stabilize, when to alt hold mode etc.
Took the log at the end.
So, clearly in this flight the copter is not moving in anyway, it is on a flat surface and there were no vibrations in the house, yet when I look at the vibration plots from the log of this I see periods of relative increase in vibration. Now this I really can’t explain, unless this is a HW issue with the pixhawk?
Please see the graph below followed by the .bin file:
[attachment=1]accx_y_not_moving2.jpg[/attachment]
[attachment=0]2.BIN[/attachment]
There appears to be some gross inaccuracies here, or I am doing an experiment that is simply not valid (why?). The other thing I noticed is that observing things in flight data (that provides the artificial horizon etc) I can see that mission planner is reporting that things are pitching/rolloing slightly. Slightly I say, however given the copter is on a solid surface that is not at all moving I would expect that to not pitch or roll at all? I should mention that the compass is rock solid and does not move at least.
In addition if you look at this log and plot the relalt & baralt they both show a gradual climb of 4 meters over the period of the log. Both them seemingly in lock step with one another thinking this? GPS slightly lags baralt, but I find that curious that both height indications are showing a drift of 4m upwards when the craft is not moving at all. The fact that both sensors are saying this seems to indicate a SW issue as I can’t imagine both HW failing in the same way?
Is my experiment invalid? What am I missing here. Or do I genuinely perhaps have bad HW?
The two IMUs onboard the pixhawk are in agreement. The measurement must be real.
You are probably comparing CTUN.BarAlt with GPS.RelAlt. GPS.RelAlt is misleading - it does not come from the GPS, instead it is the inertial navigation altitude, which is a complementary filter that uses the accelerometers in the short term and barometer in the long term. Normal for it to track the barometer. It lags the barometer because it is being slowly dragged towards the barometer - it relies on the accelerometers to measure rapid movements. If you take a look at GPS.Alt, you’ll see it is terrible. It jumps by 50 meters at one point. Doesn’t matter, we don’t use it for that reason.
Roll and pitch jump around because of noise in the GPS velocity measurement, which is used in the attitude solution.