This is a discussion to focus the feedback and support of ardupilot on the PixRacer board from AUAV.co.
We believe that all teething problems encountered are now resolved and so we recommend people load Copter-3.3.4 which is available for all multicopters through the Mission Planner's (and other GCS's) Install Firmware screens. Note that because regular Pixhawks are still on Copter-3.3.3 the install icon may show Copter-3.3.3 but rest assured, Copter-3.3.4 will be installed (you can check the version by looking at the very top of the Mission Planner).
Replies
Latest AC 3.4dev (ba3576f0) loaded. ESCs calibrate better, and all other problems I was having are gone.
Almost ready to fly (sunny today!) but now pre-arm: compass not calibrated will not allow arming.
Have calibrated the (external) compass 3 times. Good values. All green. Internal compass disabled. Params written to PixRacer.
Not willing to bypass the pre-arm checks since they are there for a reason. Anyone got ideas as to what is causing this?
I really like having the safety switch in action. Behaves more like the pixhawk. Consistency between hardware is important IMO. Less chance of personal injury of noobs to PixRacer, coming from the Pixhawk.
@Justin,
The Pixracer has two internal compasses. When you disabled the internal compass, did you set both COMPASS_USE2=0 and COMPASS_USE3=0?
If it is still claiming it is not calibrated then it may indicate the connection to the external compass is broken, and it is using one of the internal ones. I'd suggest putting a magnet or just a screwdriver close to the external mag and seeing if the reported magnetic fields (mx, my and mz in MissionPlanner) change. That will allow you to be sure that it is using that compass.
Once you've confirmed it is using the right compass then if it still claims it is not calibrated then I'd suggest you calibrate it again.
Cheers, Tridge
Had the same issue, after loading one of the dev versions compass_use3 was set to 1, took me good 10min before i realised this, though I am very sure I did NOT set that param. After setting it to 0, all was fine. Btw, I think compass3 orientation is not set correctly in the code, its X offset is around -600. Or Is it just too close to an LDO?
Hello Tridge
You nailed it. Got it working just now :) I achieved what you suggested in a different way.
Will be flying it for the first time today. Really looking forward to it.
The trick was I had to calibrate the compass with ALL three compasses selected. Then I disabled the two internal compasses (checkboxes) who's errors where pretty high compared to the external compass anyway - as you would expect. Then I wrote the params, effectively doing what you suggested (COMPASS_USE2=0 and COMPASS_USE3=0). Safety switch, armed and GOOD TO GO!
I always thought that regardless of the compass usage checkboxes, ALL compasses where calibrated in one go and stored, since they all show up in the 3D axis graphic. But based on what I saw today, it suggests that the checkbox is required to be checked to store the calibration values.
I worked this out after reading the official documentation. Which is quite good really, and I should refer to more often. It suggested that if any changes are made to the craft then ALL compasses should be recalibrated regardless.
Thanks for you help. I have never flown FPV before. Should be an experience!
I reported I was running AC3.4dev when in fact it is AC3.4rc1 as of less than 24 hours ago!
Has anyone been able to get FrSky telemetry working with their PR? I have verified that my X6R Receiver is sending telemetry with an FLVSS voltage sensor. I have also tried an X4R which is sending telemetry perfectly with an SPRacingF3 flight controller, but nothing from the PixRacer. I am under the impression from various threads that this works out of the box and should not require any configuration. I have double and triple checked my wiring.
I am using the latest beta version of MP and AC3.4RC1.
Thanks, Rich.
Still the same trouble!
Only now Stabilize is also doing the uncommanded yaw movements.
Alt hold does random yaw movements. Alt hold doesn't hold altitude well.
it's unflyable w/ the random uncommanded yaw movements! One time it spun almost completely around and I lost orientation..
I'll try to upload a log...
38 5-28-2016 11-51-10 AM.bin
Vibrations are bad. Your lucky it doesn't fly off on you.
Where are you seeing that? I just replayed my telemetry log of the flight, and vibes are in the low-mid green section on the bar graphs in MP the entire flight..
That's how I've always tried to be aware of the vibe situation... I keep that vibe graph open while flying/testing things..
--I just looked at the log I posted above.. and if you're talking about the clipping that is increasing through the flight, those are adding up each time I crash.. But not while in the air.
-- Now I looked at the 'old' way of vibe analysis, looking at thge IMU AccXYZ values, and the vibes are practically non-existent.
I also noticed, while watching the telemetry log, my GPS was horrible during the flight. Velocity EKF was going red often. I thought maybe that could be causing the yaw movements..
So, that finally motivated me to install a new GPS on this copter. I did and took another flight. GPS was much better. But still a couple random yaw movements. Not as bad as the flight this morning.
I always had 13-15 satellites this time. Velocity still went in to the red a couple of times, and it looks like it is at the same time it drops a satellite. But it's from 15-14 sats.. nothing major. Those times might coincide w/ the times it makes random yaw adjustments.
And if it is a GPS thing, maybe it's worth mentioning the same copter w/ the same deficient GPS running APM 3.3 works fine.. (at least in stab and alt_hold)
Attached a log of the flight w/ the new GPS.
39 5-28-2016 2-15-00 PM.bin
-
34
-
35
-
36
-
37
-
38
of 120 Next