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
Hi Thorsten,
already have the faulty clone next to me. investing a few more hours would not hurt. i dont take it as an offense, but please be supportive. there is still a high chance i will fail to solve, im just giving a try :)
im not seeking support from auav. cloners probably just downloaded the files and put into the circuit factory machine. i agree with most of your points and i dont want to dive in this too deep.
moral, theoretical question.. if it ever happens i find a fix, should i keep it private? :)
actually, by the debug port, 3.4-rc1 hangs at "no ms5611 found". checked the same on 3.3.4-pixracer, the same happens. the only difference is on 3.3.4, the whole [init] process is restarted after this 2 more times, when "ms5611 started OK", then the system boots up properly.
this all takes around a half second. i assume the board is not ready at the point sw started as usual. retry logic seems to be changed for 3.4. (or the driver, or something else :D )
is there a reboot button on the cloneRacer? if so, try warm reset, maybe the ldo they've used does not stabilize quick enough, so baro fails to start and since there are no more retries the process aborts.
Marcell
One can only do so much magic with software. I'm not saying it can't be tackled, but with the variances in behavior from the HKracers its a hell of a job.
Is there some sort of trace level logs, where i can see the point if fails to boot? Is a diy ftdi dronecode probe the tool i need to check this?
Is the master the right branch to start from? And is this the right forum to talk about this?
Sry for the too many questions ;)
Macell: ask for refund, say that you buy a Pixracer and recive a Fake pixracer and not works and them buy a genuine one, they are very easy to make work, only autotune don't work for me (3.4) but I don't spend many time tunning yet, only plug, little manual tunning and enjoy fly :)
I would start with... "Why does my board not work with ArduCopter 3.4?"
Marcell
I would be a bit more blunt than Phillip :)
"Refund now!! Doesn't work as advertised!!"
I heard that Paypal has some heavy handed policies for this :)
You can go to the http://discuss.ardupilot.org where most of the dev team tends to watch for issues.
But i would. If i could :)
Where should i start? I have some xp in embedded development, general software engineering, but not yet familiar with the codebase on this level. Or... is it a mission impossible?
Marcell
I hope this translates well, but debugging hardware is a real pain. Doing it remotely is like a blind man leading another blind man.
I've done my share of Windows embedded systems and I can tell you has very little to do with this. And I'm excluding sub par components. Recently there was a problem with the FTDI fake chips that caused some uproar in the community. Problem is that we don't know what's in those HKRacers...and we rely on very severe timings from some components, if a component is not on spec, then .... you know the rest.
This happens with other boards as well.
So whatever you've saved on the initial purchase you've already spent way more trying to get it working right.
-
18
-
19
-
20
-
21
-
22
of 120 Next