You need to be a member of diydrones to add comments!
RT @chr1sa: Donkeycar 4.4 released with tons of new features, including path learning (useful with GPS outdoors), better Web and Lidar supp…
RT @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer https://t.co/GKcEjImQ3t
UC Berkeley's DIY robocar program https://roar.berkeley.edu/
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup https://t.co/PHBYwlFlnE
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/Y2hMyj1…
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs https://t.co/Rrf9vDJ8TJ
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/kK686Hb9Ej
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
RT @NeaveEng: Calling all UK based folks interested in @diyrobocars, @f1tenth, @donkey_car, and similar robot racing competitions! @hacky_r…
I was wondering whether the problem is related to hardware failure (mine has sure taken a couple of big knocks) or just interference. My APM2 also sits in a cramped space under the Ublox GPS such as I see in your photo.
Did your APM also take some knocks? and
Is there an option to mount the compass remotely on the APM2?
Hi droners. After our discussion about the compass possibly being the cause of my woes I did some more test flights. I found that the drone that I've been doing most of my testing on is the one APM I have that has a seemingly faulty compass. My other drones don't have this problem. However, if I boot up with the drone facing north, it _mostly_ works. The compass, even with learning turned on, tends to drift out during the flight, however, so even it RTL works at the beginning, it may not function toward the end of the flight.
This APM has already been RMA'd to the factory (I couldn't get the radio calibration to work) but they couldn't reproduce the problem in the factory and it worked after it came back. Hmmm. Anyhow, it's a known-flakey piece of hardware. It occurs to me that I could put this APM in my plane and use the plane APM on a 'copter as planes don't need the compass.
In the meantime, I've found a workaround involving adding a small piece of apparatus to my drone (see attachment).
I didn't study your logs and video, but I've also experienced occasional fly-aways. My problem seems to be that the compass heading error grows until it is more than 90-120 deg out. Two days ago it ended up going away at a steady 97 km/h! I found it 2km away and from the Go-Pro video (that amazingly survived the 200m drop) I could confirm that the heading displayed on the GCS was not the actual heading.
This has happened before on a similar mission and the common factors were:
Distance to waypoint >1.8 km
Direction to waypoint South
Didn't do manual compass calibration before flight since it seemed OK
Cross-wind component 20+km/h
I've strangely never had the problem when flying similar missions in an East-West direction.
Next I'll try and do manual calibration and then switch off auto learn for the compass.
Did some more testing today with a build that had CAMERA and MOUNT, but no AP_LIMITS. RTL exhibited its usual error in 3 of 4 flights. This suggests AP_LIMITS is not the culprit. It did seem to good to be true.
I'll try again with CAMERA and MOUNT disabled, and will also try jasonshort's patch. Has anyone else tested jason's patch? I doubt that CAMERA or MOUNT would cause this error, but it's possible, and we have to turn over all stones until this bug is found.
Looking through your logs helped me find a small bug where the AP commands were failed to be reset when flying in Stab mode. It was a minor bug but could account for your strange behavior. It would however correct itself after a few seconds.
I'll post a fix soon for the next version.
not sure if the compass was the reason, but it reminds me of when mine crashed into the sea.
maybe you can see some similarities.
I upgraded the firmware on one of my afflicted drones to AC2.7.3. I also upgraded the GPS on this bird from the Mtx to the Ublox, for greater accuracy, and installed new props. I was able to reliably reproduce this bug in 3 out of 4 flights. I was also able to figure out (sort of) a work-around. Please review the footage attached to this new thread (I created a new thread as I don't know how to add attachments to replies):
The flight log excerpts display the same sort of jump in long_error/lat_error differences as before (3rd and 4th numbers, respectively):
NTUN, 2548, 88, 0, 0, 1159, 338, 80, -137, 0, 0
NTUN, 2509, 86, 0, 0, 1159, 338, 100, -160, 0, 0
NTUN, 2496, 87, 0, 0, 1159, 338, 101, -136, 0, 0
NTUN, 4140, 108, 3695, -1216, 739, 0, 138, -174, 2, 3
NTUN, 4128, 106, 3664, -1185, 413, -354, 152, -154, 6, 6
NTUN, 4026, 106, 3626, -1154, 490, -449, 191, -154, 9, 10
Some additional notes from these flights:
* When RTL is acting strange, Loiter also doesn't work well.
* The point it thinks is home is moving around a lot, and very fast, as evidenced by the home arrow on the OSD moving even when the copter is hovering stationary.
* I don't have a work-around, but in the video I explain a simple test that will determine if you can use RTL that flight.
* Re-arming the APM doesn't fix the problem, but rebooting the APM sometime does.
So, where do we start debugging this problem? Here are some ideas. Maybe some of the developers could weigh in on this problem as well.
* Custom build of APM with lots of features (limits, camera etc.) turned off.
* Custom build of OSD to display additional data from the APM, like lat_error and long_error.
* Dig through the code and figure out what's causing the lat_error and long_error to move so much. Maybe something to do with waypoints?
I tried RTL a few times on the weekend in the heli, it seemed to work fine. I'm really not sure why sometimes it seems to not work.
#define RTL_YAW YAW_LOOK_AT_HOME and this allows me to see which way it thinks home is. So that helps too.
But, for whatever reason, it worked fine this weekend.
I have observed this on my Quad for every version of APM I have used (I have had my Quad about 7 months). RTL has worked maybe 10% of the time.... the remaining 90% is scary. I have mentioned this on few posts as far back as April. I know others have the same problem.
The last time I tried RTL my quad ended up in a tree.. so I have given up on it and really have no idea how to fix it. Stabilize, loiter and Alt Hold all have worked well for me.
I did more test and happen to find the problem again (although rarely). I usually wait 20 seconds more after getting the gps fix in order to be safer and usually works but RTL is the safety related mode and should be fully trustable.
Anyway, if it's a problem in setting the home position it should fly consistent to the wrong home (and this could be due to a twitch in gps during arming such as those deeply discussed in the main 2.7.3 released thread). But the behaviour is somewhat different. The copter, when functional, rises straight up 15 meters stay there a while and start cruising home. Instead when crazy it start rising 15 meters while drifting or rotating a bit (or a lot sometimes) and then without stopping at all starts increasing this drift speed to a random direction.
Will test further but so far (in around 5 flights) I noticed that if it goes well the first time it goes well always (which might lead to think that the problem is during arming). For now I'm just testing it right after take off and if it works ok, I feel decently safe.