41 replies to this topic

[XXL-Wing]

Brian, on 06 January 2012 - 09:49 PM, said:

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.

That is true except for the fact that there cold be some problems with congestion due to interferences on the network by other sources, could even be the remote control as this also operates in the 2.4GHz band. I agree that much can be done using standard XBees, but what should be implemented - and that is normally a matter of the protocol layer (so it should be done in the UAVTalk area) - is a supervision of timeliness and jitter in communication. This is especially true if you use this link for remote control of the UAV concerning live flight commands like from a RC control.

Brian, on 06 January 2012 - 09:49 PM, said:

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.

Agreed. UAVTalk itself (the protocol) should be separated from everything that includes network structure, routing, packetization etc. This alows for multiple different transmission types without changing the protocol itself. Something like a socket interface should be the entry point to UAVTalk, everything below should be exchangeable.

Brian, on 06 January 2012 - 09:49 PM, said:

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 think if you redesign it and do it nicely, adding more devices will be there automatically, if UAVTalk is separated from how things are transmitted it does not matter if a packet is exchanged between UAV and GCS using ZigBee, some proprietary protocol or transmission or even exchanged between the CC board and an ESC connect by I2C, SPI, or whatever.

Brian, on 06 January 2012 - 09:49 PM, said:

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.

Count me in. I'd like to help with that.

cheers
Mike

Edited by XXL-Wing, 07 January 2012 - 06:15 AM.

[Brian]

XXL-Wing, on 07 January 2012 - 06:13 AM, said:

Count me in. I'd like to help with that.

Mike,

Thanks for the offer.  I just started a new thread to discuss possible enhancements to UAVTalk.  Let's start the discussion there and see where it leads.

[dankers]

OK, so the PipX is taking me a long time to make and we have zero funds to do it with.

I think we might just release the hardware under a CC-BY-SA license and see what the community does with it? I am a bit concerned as we already have done a lot of research and work in to it, do you think people will do the right thing and at least credit OpenPilot?

The modems work now, we have had a 8km range test out of them, there is working software for them and a GCS config also.

Wise move?

[Brian]

I think I understand your reasoning for releasing it without the NC clause.  Your hope is that someone else will pick it up and manufacture it so that it at least gets out there.  The problem, of course, is that they could significantly change the design and/or lock down the firmware.  It's a tough call.

Another couple of alternatives that you've rejected for other products, but maybe one of them is a better compromise:

• See if there's enough community interest to have the community fund a prototype run.  I'll the the first to sign up for this.
  
• Keep the NC clause, but submit the design to something like Sparkfun or Seeedstudio.  Even if you arrange for this to be non-profit, or donate the profits to charity (not that I'm recommending either of those. since the project could use some financial support), you at least maintain some control over what comes out.

It would be great to see this come out in some form.  There's really nothing else out there that has both long range and is fully programmable.

[dankers]

Brian, on 16 February 2012 - 03:11 PM, said:

I think I understand your reasoning for releasing it without the NC clause.  Your hope is that someone else will pick it up and manufacture it so that it at least gets out there.  

Exactly, it's cost a lot of money to develop these and they have been done for almost a year now, fully working with a range test of 8km.

Quote

The problem, of course, is that they could significantly change the design and/or lock down the firmware.  It's a tough call.

It's possible and a big risk however the CC-BY-SA ensures we should at least get credit which at the moment people can silently grab the code from Git (it's been there for a year already), easily figure out the design and pass it off as their own work without any credit and people being non the wiser.

Quote

Another couple of alternatives that you've rejected for other products, but maybe one of them is a better compromise:

• See if there's enough community interest to have the community fund a prototype run.  I'll the the first to sign up for this.

Done

http://forums.openpi...the-pipx-modem/

[peabody124]

We should be clear - that 8 km was simply acknowledging a packet but not getting valid data.  I expect working telemetry BW to be much less than that.

[Kenn Sebesta]

peabody124, on 16 February 2012 - 07:39 PM, said:

We should be clear - that 8 km was simply acknowledging a packet but not getting valid data.  I expect working telemetry BW to be much less than that.

If that was with rubber duckies, I'm still going to claim I'm very impressed.

[dankers]

The test James is thinking about was rubber duckies and 11km however, I agree with the sentiment, a lot of testing to go yet to really determine the actual range. The aim was always 5 miles and Pip did get this with a full link, but as always YMMV.

[Reddog]

While I currently love the GCS its not possible to have the GCS features and manual control features in one box. It seems the Gruvin9x project has finished their custom transmitter board and selling it. I seem to remember Brian mentioning that he had ported UAVObjects to Arduino but would only run on the mega 2560. With the Gruvin9x board out and the Pipextreme soon to be available, it would be great to be able to merge the transmitter and GCS into one beast. Would it be possible on the Gruvin9x board?

I can just imagine flying my plane and tweaking the PID values etc.

[Brian]

One could probably build something around the Gruvin9x, but I can't see spending $140 to upgrade a $40 transmitter.  I also think that whatever you could do with the Gruvin9x you could do with the original board and custom firmware, combined with the PipX processor.  The most I think one would want would be the Smartipants board, which gives you a programmer interface (and back light, or course).

I looked at some of the custom firmware for the 9x, and I don't think it would be hard to modify the custom firmware to communicate with e.g. a PipX to send control over the PipX radio link, and to display telemetry on the 9x display.  The firmware already supports Arducopter telemetry using an Xbee.

[dankers]

Quote

One could probably build something around the Gruvin9x, but I can't see spending $140 to upgrade a $40 transmitter.

I love what they are doing but we went down that road (well me and Pip did) thinking about how to make it better, an STM32 is obviously the right way, not more 8 bit stuff. Then you think, well for another $14 I can add a much better color screen as the STM32 has the power to drive it, then add a back light as well. But ultimately you end up making a $40 in to a $200 TX and it's simply not worth that with the shitty POTs it has. It's like the guys that spend a fortune adding stuff to their old car, by the time they have finished they could have just bought something much better.

The 9X has some horrible POTs in it, Oleg even implemented a new feature in the next OP firmware to especially accommodate these. It is a great TX for the price but the best upgrade is the back-light and custom firmware and call it done, it is no way worth investing any more in it.

If no one has done a commercial quality Open Source TX that doesn't cost $2000, I will take that project on after Revo is released.

From what I remember of Ardupilot stuff it was just a copy of AttoPilot's telemetry, it just sent what is basically a NMEA style sentence, very very easy to get CC to do the same but you don't need the Gruvin9x board for it.

[Reddog]

dankers, on 21 February 2012 - 02:54 AM, said:

If no one has done a commercial quality Open Source TX that doesn't cost $2000, I will take that project on after Revo is released.

I will be right there besides you on that one. Every transmitter out there is limited in some way. It would be great to have something a little more flexible and up to the challenge.

[dankers]

Reddog, on 21 February 2012 - 04:24 AM, said:

I will be right there besides you on that one. Every transmitter out there is limited in some way. It would be great to have something a little more flexible and up to the challenge.

You're funding it

[LeeS]

I vote we use hall-effect, military grade, joysticks.

[LeeS]

Brian, on 21 February 2012 - 02:04 AM, said:

I looked at some of the custom firmware for the 9x, and I don't think it would be hard to modify the custom firmware to communicate with e.g. a PipX to send control over the PipX radio link, and to display telemetry on the 9x display.  The firmware already supports Arducopter telemetry using an Xbee.

The transmission side should be dead simple as the PipX has the ability to read a PPM stream.  You could just hook up via the trainer port.  Or, if you prefer a wireless solution and have RX modules than support PPM out, you just wire the RX PPM out into the PipX PPM in and you have a wireless bridge.  If you have something like the Frsky modules, you could even push basic telemetry data back to the TX wirelessly as well.  The added benefit of this is no special mods for the PipX are needed in the TX.  You could use standard Frsky RX <-> TX in some of your airframes and PipX <-> PipX <-> RX <-> TX in your long range airframes.

[Reddog]

dankers, on 21 February 2012 - 04:42 AM, said:

You're funding it

Thats fine as long as someone helps me to understand the basics of hardware development.

[dankers]

The worse part is the case for cost to be honest, plus for something like that, we need to really visit the factory. Lets get revo out and see where we go.

[Grawp]

I'm going to try using Atmel's AT86RF212 based modules for complete realtime servo control. I will use 802.15.4 PHY layer without any retransmissions etc., and I'm going for G3 band (869.400-869.650 MHz) and not original 802.15.4's G1 (868.0-868.6 MHz) since G3 allows up to 10% duty cycle compared with 1% G1. (I really hope I can fit to the G3. I'm not sure how narrow/wide 802.15.4 signal is.)
I'll post some results here by the end of this or next week.

If it goes well I plan to implement two-way communication with random delays to prevent possibility of locking to some periodic noise. UAV will normally always start the communication by sending some data and GCS will immediately reply by wanted servo positions, commands, etc.. Every new cycle will be separated by semi-random delay.
The UAV will be listening all the time except when it's transmitting so there will be possibility for emergency out-of-cycle commands from GCS.

[Grawp]

AT86RF212 worked fine for servo control. I haven't measured actual latency in ms, but from what I saw, it could be definitely used for slowflys and big UAVs. I also haven't measured the range since I only had modules without any powerful preamplifier and I was operating it probably illegally since I could not find any modulation narrow enough so it would fit to G3 band.

Later I decided to go on with AT86RF230 in Zigbit modules that optionally have power amplifier capable of 100mW output. However I couldn't find anything about time constants, cycle length... Experiment showed that the minimum possible ping is about or little lower than 100ms. The AT86RF230 options (no custom frequency, no various modulations, no frame-buffer protection) are also severely limited when compared to RF212.

[XXL-Wing]

Reddog, on 21 February 2012 - 04:24 AM, said:

I will be right there besides you on that one. Every transmitter out there is limited in some way. It would be great to have something a little more flexible and up to the challenge.

How do you like the new Jeti one?
I curently fly a Graupner MC-22 with Jeti 2.4GHz module but i am just waiting for the new one from jeti to be released (should be the next month)