41 replies to this topic

[Reddog]

I have always wondered why you are able to control a model via standard transmitters but you are unable to do it via modems like the Xbee. I figured it had to do with real time information (Futaba seems to require a 20ms pulse for PPM). I cannot see the difference between an Xbee or Pipextreme and a standard receiver/transmitter. If FrSky can build a receiver/transmitter that has two way telemetry why have others in the hacking scene not built one?

[dankers]

You can use modems for control, in fact one of the really high dollar MultiRotor platforms has their own transmitter and it's just an 2.4Ghz Xbee in case with some gimbals, and an MCU.

One of the things the PipX has is PPM on a header and hence can be used for long range control, (used as a PPM input on the TX and an output to a Revo / CC / MK etc) on the other end. it would be possible to multiplex the PPM with telemetry or use a priority queue for it.

Quote

If FrSky can build a receiver/transmitter that has two way telemetry why have others in the hacking scene not built one?

Cost and complexity. RF is hard and like black magic, while it is not to hard to work with digital circuits, analog gets trickier but RF is another world and only the foolish step in to it lightly. I'm reading a lot of RF stuff currently, it's tricky, fraught with traps and some of it even contradicts it's self.

We do plan to release the PipX at some point unless something better comes along which negates it but without someone saying "I will lead the PipX development and stick with it", we can't as we don't have the resources for it.

[D-Lite]

Reddog, on 15 December 2011 - 06:34 AM, said:

I figured it had to do with real time information (Futaba seems to require a 20ms pulse for PPM). I cannot see the difference between an Xbee or Pipextreme and a standard receiver/transmitter.

That's basically it, latency. On a standard receiver, there is not much overhead, you move the stick and (up to) 20ms later, the servo output on the model is guaranteed to respond. On a modem, you often have things like queues that store a small amout of data which is bad for latency. And if you use the same modem to do telemetry, it get's worse because other telemetry data may delay your control input data. All of this can be solved, it just doesn't work "out of the box". AFAIK, Brian is working on a board that plugs between the radio modem and the GCS to inject manual control commands. It's also possible to connect a joystick to the GCS and use the GCScontrol plugin to control the model through telemetry but this is still experimental and just not fast enough to really fly the model in realtime.

[jes1111]

D-Lite, on 15 December 2011 - 10:05 AM, said:

not fast enough to really fly the model in realtime.

Ah! There's the rub! But the Revolution, in full-on "fly-by-wire" mode? That seems do-able to me. The latency would matter much less if the command signalling was simply "move the Magic Waypoint over here, please" rather than "Turn left! ...NOW!"

[Reddog]

dankers, on 15 December 2011 - 09:23 AM, said:

One of the things the PipX has is PPM on a header and hence can be used for long range control, (used as a PPM input on the TX and an output to a Revo / CC / MK etc) on the other end. it would be possible to multiplex the PPM with telemetry or use a priority queue for it.

So the Pipextreme as designed has sort of two wireless streams going to the vehicle or its communicating with the airframe over a serial type connection and also outputting PPM for use in an RC transmitter? Either way, quite a cool idea.

[Reddog]

D-Lite, on 15 December 2011 - 10:05 AM, said:

AFAIK, Brian is working on a board that plugs between the radio modem and the GCS to inject manual control commands. It's also possible to connect a joystick to the GCS and use the GCScontrol plugin to control the model through telemetry but this is still experimental and just not fast enough to really fly the model in realtime.

I saw Brian mention this and it looks very exciting and interesting.

[Reddog]

dankers, on 15 December 2011 - 09:23 AM, said:

Cost and complexity. RF is hard and like black magic, while it is not to hard to work with digital circuits, analog gets trickier but RF is another world and only the foolish step in to it lightly. I'm reading a lot of RF stuff currently, it's tricky, fraught with traps and some of it even contradicts it's self.

It seems so simple......

You sure are right about this, I have spent a fair amount of time looking into RF for my HAM certification and its extremely complex.

[D-Lite]

jes1111, on 15 December 2011 - 12:07 PM, said:

Ah! There's the rub! But the Revolution, in full-on "fly-by-wire" mode? That seems do-able to me. The latency would matter much less if the command signalling was simply "move the Magic Waypoint over here, please" rather than "Turn left! ...NOW!"

Absolutely. With some autonomous assistance on board, it will work very well. Btw., I already did some manually controlled hovering in attitude mode via GCS. It's not totally impossible but just not responsive enough to call it "real" flighing or to be much fun.

[Reddog]

D-Lite, on 15 December 2011 - 01:06 PM, said:

Absolutely. With some autonomous assistance on board, it will work very well. Btw., I already did some manually controlled hovering in attitude mode via GCS. It's not totally impossible but just not responsive enough to call it "real" flighing or to be much fun.

Is the reason the Xbees are so slow is because of the error checking and other overhead or is it something else?

[Brian]

I have my transmitter box working, and plan to create a post soon describing it.  The mini quad that I just got working last night is designed to test it.  It only as a CC board and Xbee, and receives GCSReceiver commands from the transmitter box via the Xbee.

In initial tests it seems to work well, but I want to add more debug code to quantify the latency and to ensure that packets aren't being dropped.

[Kenn Sebesta]

Reddog, on 15 December 2011 - 01:20 PM, said:

Is the reason the Xbees are so slow is because of the error checking and other overhead or is it something else?

Depending on which Xbee you're using, you could see multiple effects.

First, if it's a 802.15.4 Xbee, then you have random delays in transmission in order to try to find an open slot. You can disable this, at the expense of possibly getting in sync with some noise source and *never* being able to find any open time slot because now your time slots are deterministic. (Actually, IIRC you cannot disable it completely, just bring it down to +-2ms)

Second, if you're using a zigbee capable Xbee, then you are now running a mesh network protocol and, yeah, there's a lot of overhead associated.

[Grawp]

Kenn Sebesta, on 15 December 2011 - 02:40 PM, said:

Depending on which Xbee you're using, you could see multiple effects.

First, if it's a 802.15.4 Xbee, then you have random delays in transmission in order to try to find an open slot. You can disable this, at the expense of possibly getting in sync with some noise source and *never* being able to find any open time slot because now your time slots are deterministic. (Actually, IIRC you cannot disable it completely, just bring it down to +-2ms)

Second, if you're using a zigbee capable Xbee, then you are now running a mesh network protocol and, yeah, there's a lot of overhead associated.

That's right but you could use plain 802.15.4 ICs or modules without that fancy software like in Xbee. Just use 802.15.4 physical+link layer and in untraditional way. In Atmel's RF230 you can f.e. set your own 'noise' limit for collision avoidance (maybe it can be turned of completely), set no automatic retransmission ('cos that would utilize random back-off), instead do retransmissions manually if needed.

This guy have done something like that but with WirelessUSB. See this. Problem is that I can't find distributor of any Cyrf based modules in Europe.

[XXL-Wing]

Maybe just another ZigBee stack would solve the problem.
We realized low latency soft real-time communication in a project in the company i am working for, ZigBee allows for Guaranteed Time Slots (GTS) apart from standard CSMA/CA. Several other people use this mode to transmit time critical data in fixed slots (like we want to do with flight control data) and use the remaining bandwith dynamically for non-critical data (like e.g. telemetry or video).
There are some very good papers that describe this technology. I can upload more info to the Wiki if anybody is interested.

So i think the live remote control (over a range of up to 1 mile) of a CC UAV using ZigBee is possible and feasible.

cheers
Mike

[Kenn Sebesta]

XXL-Wing, on 05 January 2012 - 02:01 PM, said:

We realized low latency soft real-time communication in a project in the company i am working for, ZigBee allows for Guaranteed Time Slots (GTS) apart from standard CSMA/CA. Several other people use this mode to transmit time critical data in fixed slots (like we want to do with flight control data) and use the remaining bandwith dynamically for non-critical data (like e.g. telemetry or video).
There are some very good papers that describe this technology. I can upload more info to the Wiki if anybody is interested.

Could you do that? That'd be great, since I thought that Zigbee was built on 802.15.4, which itself cannot guarantee any time slots, so I'm interested to see how Xbee gets around this.

[Grawp]

Kenn Sebesta, on 05 January 2012 - 10:14 PM, said:

Could you do that? That'd be great, since I thought that Zigbee was built on 802.14.11, which itself cannot guarantee any time slots, so I'm interested to see how Xbee gets around this.

WirelessHART also supports TDMA and is built around 802.15.4 physical layer but it's using its own link layer. (Correct me if I'm wrong.)

I was talking about something similiar here. 802.15.4 RF ICs may allow you to do things that are not in the standard. We should then probably refer to it as 802.15.4 PHY. Same goes for WirelessUSB (see my previous post).

[XXL-Wing]

Grawp, on 06 January 2012 - 12:53 AM, said:

WirelessHART also supports TDMA and is built around 802.15.4 physical layer but it's using its own link layer. (Correct me if I'm wrong.)

I was talking about something similiar here. 802.15.4 RF ICs may allow you to do things that are not in the standard. We should then probably refer to it as 802.15.4 PHY. Same goes for WirelessUSB (see my previous post).

Correct, WirelessHART is something similar using the same base technology.
In my opinion the best way to choose is that we take a general purpose 802.15.4 PHY chip and have an evaluation of possible communiucation protocols (together if there is any stack already available).
What also could be done is to have all communication things (like time supervision, field strength measurement etc.) in the "communication coprocessor" that also runs the wireless stack on the wireless companion chip.

@Kenn: I am at the moment searching for fields where i can help in his project so i would be glad to do that (with a team of people at least for discussion if there are people that would like to help - at least by testing ;-)) if the core team agrees.

What i would like to do is to implement in inside the PipXtreme hardware, if this is possible.
Where can i get a spec of the hardware and moreover: how can i get some of those boards for development?

Again: all only if the core team agrees.

cheers
Mike

[Aerhead]

Mike

I very interested in seeing PipXtreme type hardward developed.  The loss of Pip as the key person on the PipXtreme project has stalled it for a long time. I would very much like to do testing just like many others would on this forum.

Larry

[XXL-Wing]

I am no hardware guy, i can do the development of the communication software things, but no hardware....

maybe if the project is really stalled, take one of the available boards that offer the functionality needed and implement communication on that....

[dankers]

It is on my Todo list, I need them before Portugal for sure.

Yeah, Pip was a huge loss and we all miss her.

[Brian]

I like the discussion of consideration of different network protocols for improving the real-time performance of the telemetry, but I think there's much that can be done with existing hardware (standard Xbees) prior to re-implementing the link-level protocol.  I believe that most of what you're talking about WRT CDMA, etc is not so much of an issue in the small networks that we have.  We really only have a pair of Xbees talking to each other, so there shouldn't be any collisions.  I've been trying to put together an initial proof-of-concept with my UAVTalk Transmitter, and so far it is working pretty well as it is with standard Xbees.

What I've been trying to focus on at the higher level is generalizing the UAVTalk interface.  I would really like to see more separation of the network layers in UAVTalk.  Currently UAVTalk performs packetization, and reliability / re-transmission, and it (for the most part) assumes a single link between two devices.  I wedged another device in the middle by simply relaying all packets between the two comm channels and stuffing GCSReceiver packets in as required.  It would be really nice if there was a clearer notion of multiple devices and the ability to route messages more directly i.e. distinct network and transport layers.

I believe that this is going to be more important as we start bringing more devices online (PiPXs, ESCs, OSDs, etc).  It would great if the GCS could talk to all of these devices, and for the devices to communicate no matter how the network is connected, and have devices automatically reconfigure, etc.

I've thought about this a bit, but would love to have some help in designing and prototyping it.  So far I've just been making changes to UAVTalk that were required for my transmitter prototype.