info: Waypoint app

[Noël]

Not sure if it has been posted already.

I just had a look at my twitter time line and noticed this tweet from DJIGlobal .

For those waiting for #waypoint, we're still getting this ready and would launch only when 100% pic.twitter.com/6dsZbQulVq

The screenshot does look nice

 

[helixaviator]

Thats very exciting! I wonder if they are going to put a lot of restrictions on distance of waypoints and total distance traveled etc. That would be kind of disappointing if they did espectially given that many phantom users are getting greater than 1km range. Hopefully they won't lock it down too much so there is room to grow. But this is a nice feature nonetheless. I really like my phantom and this adds a new level of sophistication to the unit.

 

[Pull_Up]

If, as I suspect, all the "piloting" will be done by the app then we will be limited to the radius of wifi range. However, if there is somewhere on the main board where the Vision can store flight command data... well my goodness that would open up a whole different world. Sure, you'd lose the video downlink with the stock range extender beyond about 1000ft, but if you kept the video rolling or the camera on an intervalometer then you could capture footage from not only beyond wifi range, but beyond control range. Those who do some of the range mods in the other thread on here could probably watch it a good part of the way!

Still, all excitable speculation until we see that actual thing released.

 

[Noël]

So how do you send the waypoints to the P2V?

 

[OI Photography]

In the current groundstation setup, the entire flight plan is uploaded to the NAZA over the datalink and then executed onboard (as opposed to being actively controlled from the ground the whole time). However, it can be edited in real time once flight has begun.

The NAZA has also been limited to 16 waypoints, I'm curious to see if the same limit applies when they release it for the vision. I suspect that cap is due to limited storage available on the NAZA, but it could just be a marketing decision to help keep their Wookong flight controller (which can do 50 waypoints) worth the price difference.

 

[gunslinger]

In the current groundstation setup, the entire flight plan is uploaded to the NAZA over the datalink and then executed onboard (as opposed to being actively controlled from the ground the whole time). However, it can be edited in real time once flight has begun.

The NAZA has also been limited to 16 waypoints, I'm curious to see if the same limit applies when they release it for the vision. I suspect that cap is due to limited storage available on the NAZA, but it could just be a marketing decision to help keep their Wookong flight controller (which can do 50 waypoints) worth the price difference.

So... This thing might be able to do waypoints well beyond 1,000 feet as the information is stored onboard? I've never had the opportunity to explore the capabilities of the current groundstation setup. How much control do you have, if any, of changing altitude from waypoint to waypoint? I also wonder if, with the Vision version, you'll be able to tell the camera what you want it to do at each waypoint...

-slinger

 

[dkatz42]

However, if there is somewhere on the main board where the Vision can store flight command data... well my goodness that would open up a whole different world

It's called "RAM". Even in tiny embedded systems, RAM is cheap and it's hard to get very small amounts of it. Keeping a list of uploaded waypoints would take negligible amounts of memory, which I would guess is where the home point is stored (since it appears to be volatile). The flight plan would disappear on power failure, but that is the least of your problems at that point...

Clearly there's no technical reason why this couldn't be completely autonomous--there's no need for any sort of up/downlink once the flight plan is uploaded. If it gives up and comes home when it exceeds the range of one of the links, it's because either they're concerned that flooding the world with thousands of autonomous vehicles in the hands of...(desperately trying to think of something not too pejorative)...inexperienced people would be problematic, or they're getting (or fearing) legal pressure, or they're trying not to cannibalize the sales of the higher-end products.

 

[OI Photography]

In the current groundstation setup, the entire flight plan is uploaded to the NAZA over the datalink and then executed onboard (as opposed to being actively controlled from the ground the whole time). However, it can be edited in real time once flight has begun.

The NAZA has also been limited to 16 waypoints, I'm curious to see if the same limit applies when they release it for the vision. I suspect that cap is due to limited storage available on the NAZA, but it could just be a marketing decision to help keep their Wookong flight controller (which can do 50 waypoints) worth the price difference.

So... This thing might be able to do waypoints well beyond 1,000 feet as the information is stored onboard? I've never had the opportunity to explore the capabilities of the current groundstation setup. How much control do you have, if any, of changing altitude from waypoint to waypoint? I also wonder if, with the Vision version, you'll be able to tell the camera what you want it to do at each waypoint...

-slinger

Good question about the camera...my suspicion is that added feature is one of the reasons it's taking so long to release for the Vision. Keep your fingers crossed

Yes, the current groundstation is capable of (and programmed to perform) continuing a flight plan beyond the range of Tx/Data Link. From what I understand, auto-land will still kick in based on voltage warnings, so conceivably your only limit is the range of the battery...but I haven't tested that yet myself. It's also quite possible DJI will re-work some of that or add certain restrictions in the Vision version, or at least lock them down until you enable NAZA mode.

As of now you can also edit waypoint altitudes, both before and during flight. The command structure is fairly simple, "Fly to waypoint A, hold for 30 seconds, climb to 100m, fly to waypoint B" etc

 

[Migmon]

looks like the iphone.. cant wait! the funny thing will be uploading it and telling it to go then sitting down and eating a sandwich hoping it returns home instead of flying home to china!

 

[Pull_Up]

In the current groundstation setup, the entire flight plan is uploaded to the NAZA over the datalink and then executed onboard (as opposed to being actively controlled from the ground the whole time). However, it can be edited in real time once flight has begun.

The NAZA has also been limited to 16 waypoints, I'm curious to see if the same limit applies when they release it for the vision. I suspect that cap is due to limited storage available on the NAZA, but it could just be a marketing decision to help keep their Wookong flight controller (which can do 50 waypoints) worth the price difference.

That's interesting - I didn't realise it was the NAZA itself that stored the flight plan, I thought it was the datalink module that stored the flightplan and sent it to the NAZA... no need for the Vision main board to have any storage at all then, the camera module can just chuck the flightplan straight at the NAZA, assuming the Vision-specific version has retained that capability.

That little box of tricks in the middle gets more and more impressive the more I find out about it...

 

[AnselA]

As of now you can also edit waypoint altitudes, both before and during flight. The command structure is fairly simple, "Fly to waypoint A, hold for 30 seconds, climb to 100m, fly to waypoint B" etc

or... <speculation>

Fly to waypoint A (LAT, LON, ALT), set attitude 270 deg, tilt -45 deg, hold, set EV -1, take picture, set EV 0, take picture, set EV +1, take picture, fly to waypoint B...

 

[OI Photography]

In the current groundstation setup, the entire flight plan is uploaded to the NAZA over the datalink and then executed onboard (as opposed to being actively controlled from the ground the whole time). However, it can be edited in real time once flight has begun.

The NAZA has also been limited to 16 waypoints, I'm curious to see if the same limit applies when they release it for the vision. I suspect that cap is due to limited storage available on the NAZA, but it could just be a marketing decision to help keep their Wookong flight controller (which can do 50 waypoints) worth the price difference.

That's interesting - I didn't realise it was the NAZA itself that stored the flight plan, I thought it was the datalink module that stored the flightplan and sent it to the NAZA... no need for the Vision main board to have any storage at all then, the camera module can just chuck the flightplan straight at the NAZA, assuming the Vision-specific version has retained that capability.

That little box of tricks in the middle gets more and more impressive the more I find out about it...

Hmmm...that's an interesting point, I honestly hadn't considered that the storage might be on the data link module vs the flight controller. I just went over the documentation for the current groundstation (and it's looooong), and it just refers to uploading to "the aircraft" and then makes other references to interfacing with the flight controller...but no specific mention of where the mission data resides. It could very well be on the DL Tx module, it's big enough to have memory in the casing as well.

Here's the pdf if you have some time to burn: http://download.dji-innovations.com/dow ... n_v2.9.zip

...and the updated reader's digest version for the iPad GS: http://download.dji-innovations.com/dow ... .08_en.pdf

 

[dkatz42]

The only sensible place to hold the flight plan would be somewhere in the aircraft itself. The flying is all being done by the aircraft (you get a taste of it today by watching it return to home).

The flight plan info can reside in any piece of the system that has a CPU and RAM, and I suspect there's at least a couple buried in there. It requires no special hardware--it's just data, and there's *lots* of data flying around inside these things.

 

[OI Photography]

The only sensible place to hold the flight plan would be somewhere in the aircraft itself. The flying is all being done by the aircraft (you get a taste of it today by watching it return to home).

The flight plan info can reside in any piece of the system that has a CPU and RAM, and I suspect there's at least a couple buried in there. It requires no special hardware--it's just data, and there's *lots* of data flying around inside these things.

Right, and I'm sure it is stored on the aircraft itself...just up until now I assumed it was on the NAZA, but it might very well be on the datalink module that's installed on the aircraft and connected to the NAZA via canbus. If so, that would indicate that the 16 waypoint limitation isn't driven by hardware restrictions, since the same datalink is used regardless of flight controller model (NAZA vs Wookong)

 

[dkatz42]

Right, and I'm sure it is stored on the aircraft itself...just up until now I assumed it was on the NAZA, but it might very well be on the datalink module that's installed on the aircraft and connected to the NAZA via canbus. If so, that would indicate that the 16 waypoint limitation isn't driven by hardware restrictions, since the same datalink is used regardless of flight controller model (NAZA vs Wookong)

I'd be astonished if the 16 waypoint limitation has anything to do with hardware, whether the waypoints are stored in the NAZA or in the datalink module (I'd expect the former, though if you're on the canbus you can do anything, or at least anything that the NAZA gives you access to on that bus.)

In my day job I design and build embedded systems, so I have at least some design aesthetics, if not any actual knowledge of the innards of these beasts, so take all of this with a grain of salt...

If I were designing the datalink module, I'd make it as vanilla as possible. Presumably its job is to translate between whatever protocol runs over the radio link and the Canbus. A clean design would be to make its functions as generic as possible, so that it isn't aware of the application running across it. A simple, clean design would be to extend the Canbus protocol over the radio link, but to not be aware of the messages running across the link. The waypoint protocol would be implemented by the iPhone app and the NAZA and would run transparently across the radio link and the datalink module.

I suspect that there are some really cheap serial-to-Canbus parts coming out of the auto industry (which is presumably why they used it in the first place.)

The most obvious thing to do would be to extend the firmware in the NAZA (and to extend the protocol running over Canbus) to accept a stream of waypoints and related commands. Then action those commands within the NAZA itself, which is presumably where all of the flight control functionality lives.

A perverse (in my opinion) design would be to make the datalink module smarter (assuming it has any smarts to speak of beyond driving the Canbus). You could theoretically store the waypoints in the datalink module and then have the datalink module turn them into steering commands over the Canbus, assuming that the NAZA would accept such commands.

But regardless of which way it is done, at the end of the day it's just software and RAM--you should be able to have as many waypoints as you have space to store them (they're not terribly big, probably less than 100 bytes per waypoint). The only way it would be a hardware limitation is if they built some custom chip that did the waypoint-to-steering translation and that chip only had 16 registers, but given the obvious compute ability of the NAZA (and the expense and difficulty of custom silicon) it doesn't seem likely to me.

(But over my career I've been astonished by crappy designs, so who knows...)

 

[OI Photography]

Right, and I'm sure it is stored on the aircraft itself...just up until now I assumed it was on the NAZA, but it might very well be on the datalink module that's installed on the aircraft and connected to the NAZA via canbus. If so, that would indicate that the 16 waypoint limitation isn't driven by hardware restrictions, since the same datalink is used regardless of flight controller model (NAZA vs Wookong)

I'd be astonished if the 16 waypoint limitation has anything to do with hardware, whether the waypoints are stored in the NAZA or in the datalink module (I'd expect the former, though if you're on the canbus you can do anything, or at least anything that the NAZA gives you access to on that bus.)

In my day job I design and build embedded systems, so I have at least some design aesthetics, if not any actual knowledge of the innards of these beasts, so take all of this with a grain of salt...

If I were designing the datalink module, I'd make it as vanilla as possible. Presumably its job is to translate between whatever protocol runs over the radio link and the Canbus. A clean design would be to make its functions as generic as possible, so that it isn't aware of the application running across it. A simple, clean design would be to extend the Canbus protocol over the radio link, but to not be aware of the messages running across the link. The waypoint protocol would be implemented by the iPhone app and the NAZA and would run transparently across the radio link and the datalink module.

I suspect that there are some really cheap serial-to-Canbus parts coming out of the auto industry (which is presumably why they used it in the first place.)

The most obvious thing to do would be to extend the firmware in the NAZA (and to extend the protocol running over Canbus) to accept a stream of waypoints and related commands. Then action those commands within the NAZA itself, which is presumably where all of the flight control functionality lives.

A perverse (in my opinion) design would be to make the datalink module smarter (assuming it has any smarts to speak of beyond driving the Canbus). You could theoretically store the waypoints in the datalink module and then have the datalink module turn them into steering commands over the Canbus, assuming that the NAZA would accept such commands.

But regardless of which way it is done, at the end of the day it's just software and RAM--you should be able to have as many waypoints as you have space to store them (they're not terribly big, probably less than 100 bytes per waypoint). The only way it would be a hardware limitation is if they built some custom chip that did the waypoint-to-steering translation and that chip only had 16 registers, but given the obvious compute ability of the NAZA (and the expense and difficulty of custom silicon) it doesn't seem likely to me.

(But over my career I've been astonished by crappy designs, so who knows...)

Sounds good to me!

I had always just assumed it was the NAZA, but for reasons far less substantiated than yours lol.

 

[dkatz42]

That's interesting - I didn't realise it was the NAZA itself that stored the flight plan, I thought it was the datalink module that stored the flightplan and sent it to the NAZA... no need for the Vision main board to have any storage at all then, the camera module can just chuck the flightplan straight at the NAZA, assuming the Vision-specific version has retained that capability.

The flight controller must have storage on it; it's a computer. That's the trivial part; it's the actioning of the waypoints that requires a bit of computation (but that computation is obviously already there, given the RTH function.)

That little box of tricks in the middle gets more and more impressive the more I find out about it...

I did a little reading and armchair reverse engineering, and I agree, though most of its impressiveness comes from...software.

If you look at a NAZA module, on the outside you'll see generic controller inputs on one side and motor controller outputs on the other. Presumably in the early days of multirotors, there was some fairly simplistic translation of controller actions (essentially manual mode) and the module did that math.

But a better way to look at the NAZA module is a microprocessor with flash (for program and other persistent storage) and RAM (for working storage) that also happens to have a whole bunch of sensors and A/D and D/A converters hanging off of it. And a Canbus interface.

Basically, given this setup, you can do anything you want with those inputs and outputs if you have enough CPU and RAM to pull it off.

(I'd love it if they published an iOS SDK for some of this stuff. The hackery possibilities are endless...)