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
If other people or the dev's aren't having the random yaw movement issue I've been posting logs about, please try flying in a poor GPS area... Under a tree between houses (realistic environment for real estate photos) or try flying on a trail in dense woods (realistic environment for a racer). I think the issue is related to GPS.. that's the best I can tell from looking at what is happening when it adjusts the yaw.
And I have repeated this issue on a non pixracer board.. (an auav-x2).
Yes I noticed the same thing. very strange... I thought I needed to tweak the PIDS on the yaw or something. It just seemed to have less control over itself with yaw. I turned off EKF2... seemed better but I sort of lost track what all I did. It's in this thread somewhere. Definitely did not have the issue in 3.3
I believe you need to adjust your thr_min and thr_mid as I believe your yaw issues are caused by improper throttle control. Also, I suggest upon loading AC3.4 reset all settings to default in full parameter, write, than reboot. Also, having mud stuck on props will cause them to have diferent surface area along with mass, this affect everything in the attitude control, especially yaw. I have experience with px4 and naze32 in a 250 frame, bent and dirty props affect performance greatly... if the prop is bent it needs to go to garbage.
Thorsten, It's usually just a few or maybe 10 degrees.
I really don't think it's the vibes and dirt, etc.. If it is, that's a problem, too!! It worked fine w/ 3.3.. and on a racer, chipped props, mud, etc, will happen! And in the end, my vibes are not bad! They are in the green the entire time.. They are as low as the example copter on the instructions about monitoring vibe levels. And, I have cleaned my props, gotten my vibes down below 5, and the issue remains.
Plus, if you look at the logs, as soon as I switch to Alt_Hold, there are a bunch of yaw commands showing up. They're short spikes to 100%.. when I switch out of Alt_Hold, they go away, or get much less.
The issue is obvious from my logs.. maybe not the cause... But you can clearly see what is happening.. (look at the ATT yaw and des yaw graphs)
Also, Thorsten mentioned loiter.. For some reason, the issue is NOT in loiter! I have a log showing the yaw spikes in alt_hold, and then I switch to loiter, and they immediately stop.. I switch back to alt_hold and they are there again! I thought loiter would have all the same issues as alt_hold, because alt_hold is part of loiter.. But the issue is not present in loiter.
Scott how strong is that movement, i.e. how many degrees?
In environments with multipathing problems I also saw one or two uncommanded CW yaws of maybe 15° - 20°. But this copter is not finally tuned so i am not sure if this is a problem of AC 3.4. In open environments there is no yaw. Or at least I have not noticed. I have a 39min Loiter log. I'll have a look.
I'm running 3.4RC1. I get no motor response no matter what I set MOT_PWM_TYPE to. I'm using RCTimers 30amp ESCs that support Onshot125. With 3.3 I was able to get the motors to spin but they go from nothing to full, nothing in between.
Another issue I'm running into is that all my logs have the date of Dec 31st 1999.
Yet another issue is, the USB device becomes an unrecognized device when the battery is plugged in. When the battery is unplugged, works just fine, as soon as I plug in the battery the connection to MP disconnects and am unable to reconnect until I unplug the battery.
Any assistance would be greatly appreciated, I have yet to even take this thing into a hover. I previously had the Seriously Pro F3 board on this and it was fine, the only thing different is the flight controller. I have a hex that is running with 40amp ESCs of the same type with a Pixhawk and that thing has been fine. It's only this Pixracer board that's been giving me a problem.
@De Le,
The most likely cause of having no motor response is that the safety is on. In 3.3 the safety switch did not affect the Pixracer, now it does.
If you have the safety switch installed then make sure it is not flashing. If you don't have it installed then set BRD_SAFETYENABLE=0 to disable it.
Cheers, Tridge
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
-
32
-
33
-
34
-
35
-
36
of 110 Next