My Android beta explorer App took another update tonight. Not sure what changes were made. Just said bug fixes. Now sits at V1.0.1.43
Last edited:
New Beta Firmware Program V1.5.7
- Thread starter Jagerbomb52
- Start date
I had my first fly away today while running the Beta firmware. Todate, the Evo has been rock solid during its 17 flights. The conditions were perfect for a routine flight, but at 0.19 miles away (perfect line of sight) the RC lost its signal and would not regain any control of the drone. It flew a straight line out about 0.40 miles and landed in a sagebrush. No damage to the bird, but my confidence is shaken after that flight. It reports that I had 16 satellites and all batteries (drone & RC) were in the 70 percentile. This was in the open hills just east of Reno with no power lines or structures in the vicinity. Just open land. I have issued a full report to Autel for their input. It was just hovering about 75 feet AGL taking some still photos when it lost contact and decided to find a new landing spot. Very strange.
Ansia
Well-Known Member
When a drone autolands it means it lost it's home point. I do not know why you lost signal and what happened between that and the autoland, but sounds like a magnetic interference.
I would tend to agree. It appeared that a strong signal blocked our communications for a brief period of time. It is a bit curious that the drone flew about 0.20 miles before landing. It went zipping off in a straight line about 50 degrees tangent to the line home. To be honest, I can't tell if the drone really landed or finally crashed into the sagebrush. I'm starting to think that the latter may have been the case. If so, it was just plain luck that it hit the bush instead of a rock. We have a lot of rocks in Nevada.
Ansia
Well-Known Member
I tried changing the antennas of my controller and I broke the cable within the controller and didn't noticed. When I was testing my Evo out, I was telling it to gain altitude. When it disconnected, it continued to gain altitude for 10 or 15 seconds, before it activated RTH. So the drone just continued your last input until Autoland activated. My theory would be that somehow between the time you lost connection and the Autoland activated, it lost GPS signal, causing it to lose Home Point.
Your situation does sound similar in regards to the extended "last command". Upon further study of the log, it does indeed show a continuous "reverse" stick for the final 32 seconds of its flight. It appears that it simply struck the sagebrush rather than executing an autoland as the altitude does not change during that last linear run. I found the bird upside down just below the bush so it may have smacked it pretty hard. Thank you sagebrush!
DJI pioneered that one. ?"-Bug fixes" always scares me when it comes to drone firmware.
LOL not really. All you have to do is read most of the updates for most Apps and you will see the main one is for bug fixes.
Ansia
Well-Known Member
So I finally was able to test the beta firmware out. I have a problem that I do not know how to fix.
My Evo sometimes drifts. It is not all the time, but I always have GPS lock when it drifts. I think it is probably due to the VPS, but at the time of testing it out, it didn't occur to me to turn it off. Gave me a scare, when I saw my Evo wanting to get up close and personal with a palm tree, then a window, then a tree.
My horizon is tilted again. I calibrated, but it stays tilted.
For now I can't fly my Evo in confine spaces. I can't trust it to stay steady.
My Evo sometimes drifts. It is not all the time, but I always have GPS lock when it drifts. I think it is probably due to the VPS, but at the time of testing it out, it didn't occur to me to turn it off. Gave me a scare, when I saw my Evo wanting to get up close and personal with a palm tree, then a window, then a tree.
My horizon is tilted again. I calibrated, but it stays tilted.
For now I can't fly my Evo in confine spaces. I can't trust it to stay steady.
Ansia
Well-Known Member
claudius62
Well-Known Member
- Joined
- Sep 16, 2019
- Messages
- 877
- Reaction score
- 497
- Age
- 72
Ansia
Well-Known Member
@NevadaRocks I think you are right on the money with your last analysis. 32 seconds of backwards flight at 22 mph would send the bird 1032 feet or .196 miles. Added to your initial .19 mile position of last control and you have a close match of 0.39 miles flight length.
I suspect that between the still photo location and the site of the alien aircraft crash site the terrain rose in elevation 75 feet and the bird literally beelined it into the side of the mountain. Can you confirm a ground elevation change of that magnitude where your bird struck paydirt? With no telemetry elevation change of the drone as in a landing attempt as well as your flight speed probably went from 22mph to zero in a blink I wouldn't have wanted to witness that in person...I hate pucker and cringe factors! ?
Of course there is still the mystery at hand about what was the true cause of the event. You have confirmed the drone never lost GPS lock based on the Flight Log data. And there was no altitude change in the drone. And that your battery was far from initiating safety protocols. And there was no artificial interference from manmade infrastructure. So the problem was not a GPS issue and not a battery issue. But for one more double check, run your flight log file again and watch prior to and during the runaway period. Observe the Lat/Lon coordinates displayed on the screen to see if there was ever a drop out of those numbers about the time of, or after the runaway began.
You were on the same beta firmware as what @Ansia has just reported as drone performance changes after the beta firmware install. In your case it appears your drone shifted to reverse and stomped on the gas pedal until it tried to bury itself in the mountain. The fact that your drone had performed flawlessly until the software change sure seems to indicate a software issue. The only other possibility would be a mechanical malfunction of the right joystick reverse contact "sticking". Were you possibly flying or moving backwards at the time of the last photo take? If perhaps the software "locked in" on that last joystick command that would be valuable information to help Autel track down the issue.
Oh I sure didn't want to hear of any new HORIZON issues on the EVO. That was the reason I never bought the XSP and had hesitated until the first of August to purchase the EVO. For my projects that show a horizon in the frame, anything other than 0° level is not acceptable. I guess I'm fortunate to still be running the Explorer Beta through its paces testing the Mission Planning features before deciding to install the drone firmware. Maybe I dodged a bullet for now.
I've been spending most of my flight time testing the new Mission Planning Waypoint and Polygon features since some of my future projects would be enhanced if autonomous flight via waypoint navigation was usable. Currently, all of the Waypoint flying using either Intelligent Flight Waypoint or the three Mission Plan waypoint modes are very primitive with limited value. This includes even the Rectangle and Polygon "survey" grids.
=>=> [Sorry if this is considered hijacking the thread. It is at least a BETA thread and getting some decent visibility so I hope I'm not out of line in following this inquiry with relevant information for everyone.]
• Every waypoint is given an altitude value and a speed value by the pilot when programming a flight plan using waypoints.
• You may want to change altitude and obviously will change the heading of the next waypoint in the flight path.
Drone/Software Response
• The software commands the drone to first fly straight up to or down to the next waypoint's altitude, or remain the same if there was no change.
• Next, the software commands the drone to rotate pointing to the next waypoint heading.
• Then it initiates the flight to the next waypoint at the speed set in the plan.
• Arriving at the next waypoint it stops, checks for any altitude change at the following waypoint and initiates that first in the flight. Then the heading rotation is performed, then the flight to next waypoint is launched at the programmed speed.
There is no continuous, smooth flight through the course programmed by the waypoint flight plan. Every step is stop, adjust, go. This is the way it works for rectangle grids, irregular shaped polygon grids and freeform waypoint paths. Its probably better that I start a new thread specific for the Waypoint Navigation features of EVO but for now I'll give an example here and some comments.
Below is a [Mission Plan] 39 waypoint flight plan following a half mile of cross-country skiing trail. My take off was at WP 39 which then flew to WP#1 for starting the flight. There are a lot of reasons I designed this flight plan to serve a number of purposes but that won't be discussed here.
• The entire flight was at 220 feet to provide a safety clearance during the terrain elevation changes on the course. So there was no altitude adjustments from one waypoint to the next nor was there any speed changes between waypoints. ONLY a heading change.
• The speed was constant. Programmed as 22mph top speed in Standard flight speed.
• A 2 second per still photo time lapse was programmed.
• NOTE the software real time calculation in the lower left of the display for Distance and Estimated Time for these 39 waypoints.
• Most of you have probably realized that with the very close distances between waypoints there is no way this drone was going to achieve 22mph before reaching the next destination. So right off the bat the estimated flight time is suspect.
• Also factor in the delay in the drone reaching the new waypoint, stopping, rotating to the next heading, then initiating the flight again.
Below is the completed flight on that Waypoint Mission. It entailed exactly one half mile from take off to starting point to finishing point. The software estimate was 2 minutes and 22 seconds flight time for this course. That is at 22 mph. There is no software allowance taken into consideration for the time spent changing altitudes and heading rotation as well as the complete stop and go execution of the flight.
As you can see the actual total Flight Time = 11 mins 54 secs from take off to landing. 5X longer than what the software calculated. And the execution of the Flight Plan is as primitive as it can be programmed. And with waypoints close together the actual flight speed is never achieved except during the last few waypoints on the straightaway heading home.
=======================================================================================================
There are just as many negatives if you try using the Rectangle or Polygon grid Mission Planning navigation for performing surveys.
• If you initiate Time Lapse at x photos per time interval, you are going to end up with all kinds of photos that have widely diverse amounts of overlap as well as orientation if you intend to stitch them together.
• Every time the drone stops at a waypoint, the camera is still rolling. And during the heading rotation the camera is still clicking away. And then during the flight the camera is snapping shots at the increasing and decreasing velocities of the drone as it heads for and reaches the next waypoint.
• If that waypoint is just a short distance as the drone moves over to the next long leg path, the camera is still snapping pics while at a slow flight speed. Rotate, head down the long leg at full speed, snapping away with the actual programmed overlap.
Basically you have accumulated a hodge podge of photos that are a nightmare to stitch together with ground orientation changes during rotation to 100% overlap on photos taken during stop and gos, and varying speeds and overlap amounts on short leg flights. As well as changing overlaps during drone acceleration and deceleration.
It don't get any more primitive than that. If you want to have smooth cinematic and continuous flight paths during time lapse sequences, you had better hone your "Fly by the seat of your pants" skills with the joystick like in the old days! Or you will have NO JOY! You'll need it until waypoint navigation and perhaps the limitations of even the onboard CPU processing speeds can handle real time algorithms for smooth flight. That requires computational speeds that probably exceed the limits of EVO's onboard brain in this version. You need thousands of course corrections per second for smooth autonomous waypoint flight. EVO software (and maybe hardware?) have a long way to go.
Ansia
Well-Known Member
I didn't calibrate the camera after the firmware update. I did the firmware and stored my drone in it's bag until today. Once I took at the air, during the initial checkup of the drone's Pitch/Yaw/Roll, it started drifting forward. I will go backwards and it went again going forward. After a few seconds it stopped and I continued to do my inspection of the building. I do a horizontal S pattern of the inspection while filming and taking photos. When I finished the first elevation I left the drone hovering while I changed some settings on the screen. That is when I noticed it was going backwards. In both occasions the drone was around 10-15' from the ground, so it may have been an error of the VPS (not GPS). I have to add that I had to launch in Boat Mode, since the ground is filled with rebar and I would get magnetic interference. There are so many variables that may have affected the performance. I need a bigger open space to test further and root out the problem. For tomorrow's inspections I decided against using the Evo, until I sort things out. As for the tilted horizon. I can live with that. I can either adjust the camera as soon as I take off real quick or do it in post processing.
Here is how it looks right now.
claudius62
Well-Known Member
- Joined
- Sep 16, 2019
- Messages
- 877
- Reaction score
- 497
- Age
- 72
Thank you Trox for your explanations but I already know the system, working with the H520 which has almost similar functions.
But there are changes in the writing of files between the old version of the waypoints and the new version in the last Explorer.
Look at my post: New Beta Firmware Program V1.5.7
You will see that there are a lot of changes.
"Circledirections" appear, also angles, gimbalpictch, gimbalYaw etc ....
Would not it be a new projection of more elaborate waypoints system with turns, gradual change of altitude and others (Gimbal).
It looks like a lot. Why this radical change of file writing with new features?
A month that the firmware of the Evo is not yet finalized, but I have reason to believe that they will get there. So deal to follow.
Greeting Trox.
But there are changes in the writing of files between the old version of the waypoints and the new version in the last Explorer.
Look at my post: New Beta Firmware Program V1.5.7
You will see that there are a lot of changes.
"Circledirections" appear, also angles, gimbalpictch, gimbalYaw etc ....
Would not it be a new projection of more elaborate waypoints system with turns, gradual change of altitude and others (Gimbal).
It looks like a lot. Why this radical change of file writing with new features?
A month that the firmware of the Evo is not yet finalized, but I have reason to believe that they will get there. So deal to follow.
Greeting Trox.
Ah yes I did read your discovery of the new additions of data parameters found in the Mission Planning files. But as of right now there is no difference in execution of the Intelligent Flight Waypoints flying and the Mission Planning Waypoints flying. I wonder if those new additions are just benign 'place holders' in the code for now. Perhaps the activation and use of that new data resource is in a holding pattern (no pun intended) until developers can get an alpha version working in the lab before turning it loose in beta with some actual data points showing.
I'm curious about their inclusion of pitch and yaw as data points. That would suggest that those view angles by the camera lens would have to be added to each waypoint based on real time information captured during an actual flight. Which brings up the thought that perhaps you program in your Waypoints and flight path before flying, then fly the pattern making your camera pitch and yaw (and elevation) changes which is then added (saved) to the WP data series. What this would do is allow an exact duplicate of that cinematic flight to be performed many times, perhaps allowing the camera settings to be adjusted several different times until you finally achieve that money shot. I COULD GO FOR THAT!
Great for documenting the exact same replay over a length of time, like on construction projects, agricultural assessments, movie productions for reshoots, etc.Rather than allow the pilot to create a Waypoint flight path in the software before flying like it currently is, I'd rather see the app record and save the flight path when actually flying, like a 'dry' run. That would eliminate the CPU from being burdened with calculating the inbetweens necessary for smooth motion and curved flight paths. By just recording the continuous stream of waypoints the drone is creating in flight, including camera pitch and yaw positioning, you would have a file that just needs to be replayed to duplicate the flight AND the moves all autonomously. Now THAT would be a first! At least on an affordable prosumer level.
I suspect that due to the redundancy of Mission Planning Waypoints and Intelligent Flight Waypoints that the I.F. version will be dropped. Right now I.F. Waypoints is running with the oldest software module for this type of flight planning and needs to be 'retired.'
