Starring ArduPilot GroundStation, MillswoodEngineering GroundStation and Flexipilot. Enjoy!
UAV mission simulation using MillswoodEngineering GroundStation and Flexipilot from Krzysztof Bosak on Vimeo.
UAV mission simulation using Ardupilot GroundStation and Flexipilot from Krzysztof Bosak on Vimeo.
Comments
I think they should stay because $ATTO exists and is popular. But otherwise, only the information about autopilot on/off and loiter flags are necessary at those low refresh rates you can get.
The Millswood guys have done a real nice job there, very cool.
Lots of good points made. I always knew my upper airpeeds and climb rates were a bit over the top. I had not realised the target dots were invisible outdoors. Perhaps another colour would be better - I'll have a look.
I take your point about displaying servo positions, but I think the pan/tilt/zoom/trigger positions are useful, so I'll probably leave them all there unless I need more screen area.
Thanks for taking the time to review.
Andrew.
Ardu parsers have no idea about data coherence, while $ATTO is so bulky that is unsuitable for long range modems, and also is not immune to some rare character mistakes (this is only a XOR).
Also $ATTO is relying on mixing the data with GPRMC, GPVTG and as a result the parser sees the results asynchronously.
In case of reception problems, ME 'jams' because long $ATTO is easily converted into garbage and discarded, while Ardustation 'jams and jitters' to any value it managed to parse.
In any case, good looking groundstations.
Ardustation is also generating flickering when overlaid over any OpenGL application - would be cool to disable window overlay. There is also a typo (currenmt or something)
The update rate of both protocols and using both gstations are insufficient for IMU tuning or remote flying - therefore the orientation display is not very useful, climbrate is much more important for out of visual range failure diagnostic.
ME gstation is much better smoothing the display, and is more resistant to corrupted data - thus producing less jitter. Servo positions in any gstation is a joke-not really useful for diagnostics.
For flying in the filed, the dials of both gstations could be larger.
Also it could better to make actual value needle to more visible than the target position needle - this is not the case in Ardu GS, on the other hand in ME GE the target value is practically invisible in the field (it is not really useful, but if so why send it - OK I know because $ATTO has it).
Subjectively, ME GS look is very 'sexy' and only lacking small polishing (how to run at once in Kiosk mode and so on). Most deficiencies of ME GS are coming from the side effects of otherwise 'complete and rich' protocol.
It appears that airspeed by Ardustation is handling the data as pure integers (very crude).
ME GS climbrate scale is crazy - +/-20m/s is at most powerful hotliner levels.
Ardu airspeed scale is 145km/h - could be.
Personally it is UNLIKELY any amateur will fly a UAV faster than 120km/h while having the time to look at groundstatio, and above those speeds all heads will already be up curious due to engine noise.
Personally for estars, telemasters and fwings I would prefer 0-120km/h, +/- 10m/s climbrates, 0-400m altitudes.
I don't think the airspeed in m/s is useful for anybody, but it avoids kmh vs mph war.
the reason for 10m/s climbrate max is that above that numbers, you should have the parachute already deployed or rushing to the impact site.
Also the color on the ardustation is bad for the airspeed ring. The slower, the more reddish it should be.
Ardustation is not suited to lipo 4s machines.