Every few years, someone creates another smartphone-based autopilot (I did my first back in 2007!). And because smartphones get better each year, so do the smartphone autopilots. They haven't yet been as good as dedicated autopilots (which increasingly use the same smartphone chips, but used with better sensors), but it's a very useful experiment regardless. Here's the latest one, from the University of Nottingham.
Here it is in flight:
Comments
Marc,
Phones use wifi to establish position before they get GPS. Try turning off your wifi and doing the same thing and you should see the difference.
I will say this. I would love it if someone cleverer than I could explain why my Samsung S6 seems to completely outperform my Ublox M8 and LEA 6 units in my basement. I have compared them on my Android app to the U Center and they see more satellites and get lock much more quickly. Someone should look at what Samsung is doing here. Is it some fancy antenna? Previous Samsung phones I have owned are nowhere near as good. So with the right phone GPS performance may not be compromised with this approach.
And I dare say you could use a second Bluetooth connected GPS as well.
Thanks for the catch, Marc. Fixed
It is clear that it is a learning exercise and not an effort to turn a smartphone into a commercial grade autopilot-- they are students. If they can achieve adequate control with the multiplexed audio outputs, the plan is to use the radios in the phone to do interesting things. Wi fi cell mapping, anti-collision with 2 such devices. It is clever.
jab
one positive thing is debugging :)
the uncertainty you mention is prob. you don't know anything about android.
It's great as a learning experience, but completely wrong approach if it is meant to end up as a dedicated high performance autopilot.
1. More expensive since you need a smartphone with lots of unneeded parts like screen and so on.
2. Sub optimal design where sensors are not selected for our application, there is no external GPS antenna, lack of low latency input/output for control etc.
3. A LOT of software overhead (Linux + Android/Java) causing lots of potential problems and uncertainty
The URL, I should say.
Chris -- University of Nottingham, not University of Cambridge. May want to edit that.
-
1
-
2
of 2 Next