79 replies to this topic

[Brian]

peabody124, on 15 November 2011 - 04:28 PM, said:

At one point she started making it UAVTalk aware and we extended UAVTalk for that purpose (added a size field so it could know the packet length without knowing all the object IDs).  I think the version of PPM carrying she wrote then was _either_ PPM or telemetry too - not a two stream solution with prioritization.

I've been thinking about an extension to UAVTalk that would add prioritization and routing.  I think this would help to generalize e.g. the UAVTalkBus and Telemetry modules, where one could have a network of processor boards that run modules that either are monitoring UAVObjects and/or are modifying UAVObjects.  The module would register with UAVTalk what objects they're interested in and the priority of the updates, and UAVTalk would maintain a routing table that would be used to pass the UAVTalk messages around.  I think most of the framework is in place, and wouldn't require too many external changes to UAVTalk.  I've been trying to prototype something, but haven't quite gotten there yet.

[peabody124]

Remember there is a distinction between UAVTalk and the UAVObjects themselves.  Within the hardware the UAVObjectManager handles sending events to anyone that is registered for them.

UAVTalk is for communications and I'm not sure that there is a general "priority" that is universal across all channels.  More I would say it ends up being application specific.  For example PipX (and for that matter the GCS when sending ManualControlCommand) should know that updates for the receiver information are the highest priority and should be fast tracked.

For that matter Stac added a "GCSReceiver" object with all the latest input changes which is another input source and could be how the PipX sends receiver data.  I.e. PPM -> processed and instead of forwarding the raw PPM stream it sends a particular UAVObject.

[Brian]

peabody124, on 15 November 2011 - 05:09 PM, said:

Remember there is a distinction between UAVTalk and the UAVObjects themselves.  Within the hardware the UAVObjectManager handles sending events to anyone that is registered for them.

True, and the Telemetry module is currently responsible for transmitting the events over the wire, so it has to register events with all UAVObjects in order to see when they changed, and is uses UAVtalk.  I had envisioned a Router module that would replace the Telemetry module, that every other module on that board would register with.  All of the local UAVTalk objects would be registered, along with an update priority.  The Router modules would also communicate with other Router modules to build routing tables to know when objects need to be passed to other boards, or just passed through.  When the Router module receives a message via UAVTalk it looks up the object ID in it's routing table and either queues it to be passed on over another link, and/or unpacks it locally.  I think this is just a generalization of the Telemetry module,and I believe all the registration could be accomplished via request messages.

Also, there would likely need to be (at least initially) some simplifying assumptions e.g. no loops in the network (or even assume a chain, where each node only has a maximum of 2 links), and possibly only a single writer per UAVObject (Is that currently true?).

Quote

UAVTalk is for communications and I'm not sure that there is a general "priority" that is universal across all channels.  More I would say it ends up being application specific.  For example PipX (and for that matter the GCS when sending ManualControlCommand) should know that updates for the receiver information are the highest priority and should be fast tracked.

Exactly, which is why the local module on each board registers update priorities for each module.  E.g. status updates would be low priority periodic events, and manual control updates would be immediate, high-priority events.

Quote

For that matter Stac added a "GCSReceiver" object with all the latest input changes which is another input source and could be how the PipX sends receiver data.  I.e. PPM -> processed and instead of forwarding the raw PPM stream it sends a particular UAVObject.

I haven't looked at the GCSReceiver object yet...

[peabody124]

Brian, on 15 November 2011 - 06:25 PM, said:

True, and the Telemetry module is currently responsible for transmitting the events over the wire, so it has to register events with all UAVObjects in order to see when they changed, and is uses UAVtalk. I had envisioned a Router module that would replace the Telemetry module, that every other module on that board would register with.

I don't really see the benefit of this.  The goal with the current system is that you don't overload the internal event system but anything can register for anything with very low latency.  It's meant to just work and not require prioritization - that's done by FreeRTOS task priority.

For telemetry I can see prioritization but I think that's largely handled by setting update rates or on change settings.  However on-change does need to be improved to have throttling to be more useful.

If anything were to be improve about the internal UAVO routing it would be that we need the ability for modules to get an exclusive lock on objects and say "I'm sourcing this" to avoid potential conflicts.  I've thought about giving objects a semaphore to do this but for CC that's a bit pricey as objects are already too costly.

[Brian]

peabody124, on 15 November 2011 - 06:31 PM, said:

I don't really see the benefit of this.  The goal with the current system is that you don't overload the internal event system but anything can register for anything with very low latency.  It's meant to just work and not require prioritization - that's done by FreeRTOS task priority.

For telemetry I can see prioritization but I think that's largely handled by setting update rates or on change settings.  However on-change does need to be improved to have throttling to be more useful.

All I'm really talking about is telemetry.  When you add the PipX, the "telemetry" link is now going through another device.  You can make that other device just pass messages through, which is what I think the PipX already does, but then you have to have special case code that knows about the objects that are on that device (e.g. the GCSReceiver object), and do something special with that (unpack it locally, send it over the RF link, send it to the GCS?).  The Telemetry module also has special case code, and so does Corvus's UAVTalkBus module, which is a sister to the Telemetry module.  I think it would be cleaner if the code that communicated with other boards was more general, and the endpoints decided what gets sent where, and at what priority.

The local UAVTalk communication would work the same as it currently does.  The only difference is that if e.g. the GCS wanted updates on the CC system status, which it knows is not local, it would request updates from the local "Router" module, which would communicate that to it's peer on the CC, who would then send periodic updates, just as the Telemetry module does now.  Essentially it would remove the special case code from the telemetry, etc modules and add an interface to configure that at runtime.

[peabody124]

Brian, on 15 November 2011 - 07:40 PM, said:

All I'm really talking about is telemetry.  When you add the PipX, the "telemetry" link is now going through another device.  You can make that other device just pass messages through, which is what I think the PipX already does, but then you have to have special case code that knows about the objects that are on that device (e.g. the GCSReceiver object), and do something special with that (unpack it locally, send it over the RF link, send it to the GCS?)

Yeah I agree it can and should do those things.  Also throttling based on link quality.  We added DTR/CTS lines to help with this too.  I'm still not sold that there is a general way to do this but you're saying interesting things.

Quote

The Telemetry module also has special case code, and so does Corvus's UAVTalkBus module, which is a sister to the Telemetry module.  I think it would be cleaner if the code that communicated with other boards was more general, and the endpoints decided what gets sent where, and at what priority.

That might be true.  For the pro for example we made added a SPI port for external boards and just made a carrier board for a gumstix.  My goal in this case is we can reuse (with some tweaking) the original AHRS link code which simple kept objects in sync between the two sides.  There was enough bandwidth this wasn't a problem.

Quote

The only difference is that if e.g. the GCS wanted updates on the CC system status, which it knows is not local, it would request updates from the local "Router" module, which would communicate that to it's peer on the CC, who would then send periodic updates, just as the Telemetry module does now.  Essentially it would remove the special case code from the telemetry, etc modules and add an interface to configure that at runtime.

I guess I'd need to see this more concretely because you are essentially describing right now what telemetry does exactly.  GCS sets the meta data to indicate how frequently updates should occur (or request a single shot update) and telemetry does that.  If you start replicating similar logic around it's a bigger issue of what you do with it than having the ability to control routing at each point.

[D-Lite]

Going one step back, I don't think I would like to have manual (!) control commands transmitted via a connection oriented protocol at all, no matter if it's priorizised or not. There's no need to queue, to retransmit lost packets etc. And in a connection loss/re-connect situation, there will be a bigger gap compared to just losing some packets. It's basically the same as with IP networks, where most realtime applications use UDP instead of TCP and connectionsless protocols perform better over unreliable networks.
For a vehicle that's mostly autonomous, it's a different story but for something that needs manual control to stay in the air savely, things like that should be considered.

[Rattler]

I know that it has been brought up before but I have been looking at some of the 2.4 and 5 GHz. Wi-Fi stiff around 1.5 to 2 watts used as a point to point device.  The cost is low around $40 and there are a lot of different antennas around at some good prices. The only question would be to re-right some code to let it use USB and serial at the same time

The one I’ve listed below is listed for an example as it has a good manual available.

 ap-awus036nh_main.jpg   40.8K   14 downloads

Link to sight
http://www.wifi-antennas.co.uk/2-watt-150mbps-usb-wifi-dongle-with-detachable-5dbi-antenna-rp-sma-.html

[PT_Dreamer]

Rattler, on 17 November 2011 - 05:43 AM, said:

I know that it has been brought up before but I have been looking at some of the 2.4 and 5 GHz. Wi-Fi stiff around 1.5 to 2 watts used as a point to point device.  The cost is low around $40 and there are a lot of different antennas around at some good prices. The only question would be to re-right some code to let it use USB and serial at the same time

The one I’ve listed below is listed for an example as it has a good manual available.

ap-awus036nh_main.jpg

Link to sight
http://www.wifi-antennas.co.uk/2-watt-150mbps-usb-wifi-dongle-with-detachable-5dbi-antenna-rp-sma-.html

That device would require CC to act as USB Host witch it doesn't, and a lot of coding to write a driver for it. In other words, it's virtually impossible to use that device with CC or any other FC.

[D-Lite]

PT_Dreamer, on 17 November 2011 - 09:16 AM, said:

In other words, it's virtually impossible to use that device with CC or any other FC.

Not to mention the fact that with 2 Watt output power it has the same legal issues as most other long-range devices. There really is no solution for this -

- legality
- long-range
- low-cost

.. you have to drop a least one of those, all three in one device is most likely not possible.

[Rattler]

It's not virtually impossible to use that device. The j-tag that we currently use to program the CC board acts as USB Host and is a good example. There are boards out there that convert USB to serial communication. It wouldn’t be much to change the code for that. Actually that device I listed is FCC Part 15 Compliant hear in the US so 2 watt is legal. We used similar devices for building to building and large open area Wi-Fi..  But hopefully the Pip Pro will be hear soon just wished it had more power.  Say 500-800 mw so you could find a good amp to put behind it if you needed more range

“Part 18 ISM rules prohibit using ISM for communications"

perhaps this isn't the place to ask this, but could someone clarify this part of the rules for me? It would seem to me that wireless networking and 2.4Ghz phones are probably used for communication. What do they really mean by prohibiting communication on the ISM band? —Preceding unsigned comment added by Venevus (talk • contribs) 16:26, 15 June 2009 (UTC)
"Prohibiting communication" means exactly as it reads, use for telecommunication purposes is not allowed. The reason that this is seems confusing is because there is a common misconception that wireless networking and cordless phones qualify as ISM equipment. They do not. Cordless phones and the like operate under Part 15 rules in the United States, and they operate under similar provisions to Part 15 in other countries. These unlicensed devices are permitted to operate in ISM bands because of the undesirability of these bands by licensed services, due to the requirement to accept harmful interference from ISM equiment. –Sparkgap (talk) 06:11, 10 August 2011 (UTC)

Wikipedia

http://en.wikipedia....i/Talk:ISM_band

In another part of the forum Lew posted a link to his project page that has one of the best list of gear I have seen hears his link  
http://lewpayne.blogspot.com/

[D-Lite]

Rattler, on 17 November 2011 - 03:46 PM, said:

The j-tag that we currently use to program the CC board acts as USB Host and is a good example.

The FOSS-JTAG? No, that's not an USB Host device, it's a USB/serial bridge. But you are right, if we really wanted to use WiFi, I'm shure there would be a way to do so.

Rattler, on 17 November 2011 - 03:46 PM, said:

Actually that device I listed is FCC Part 15 Compliant hear in the US so 2 watt is legal. We used similar devices for building to building and large open area Wi-Fi..

That regulations differ very much from country to country. Here in germany for example, the limit for 2.4GHz WiFi is actually 100mW only.

Rattler, on 17 November 2011 - 03:46 PM, said:

In another part of the forum Lew posted a link to his project page that has one of the best list of gear I have seen hears his link  
http://lewpayne.blogspot.com/

That's a pretty interesting collection!

[Spydmobile]

D-Lite, on 17 November 2011 - 04:37 PM, said:

That regulations differ very much from country to country. Here in germany for example, the limit for 2.4GHz WiFi is actually 100mW only.

That sure makes sense when you consider population density and literal contry area, 357,021 sq. km. for germany (highest density) vs USA at 9,826,675 sq. km Germany is nearly 30x smaller than the US, so radio frequency licencing (in regards to trasmission stregth) make some sense.....

I have had some success with my 900 mhz Xbee Pros, extended range for reduced bandwith, is 900 mhz ok in EU?
Franco

[D-Lite]

Spydmobile, on 21 November 2011 - 08:44 PM, said:

That sure makes sense when you consider population density and literal contry area, 357,021 sq. km. for germany (highest density) vs USA at 9,826,675 sq. km

That makes some sense and may certainly be a reason for the strong regulations. But on the other hand, the situation in cities is probably mostly the same in every country..

Spydmobile, on 21 November 2011 - 08:44 PM, said:

I have had some success with my 900 mhz Xbee Pros, extended range for reduced bandwith, is 900 mhz ok in EU?
Franco

No, at least not in germany. I think GSM is in that frequency area. As Dave already said, 2.4Ghz Xbee seems to be the best solution for EU. 5.8Ghz is also okay but haven't seen anything beside WiFi and video links using that frequency.

[Berkely]

Spydmobile, on 21 November 2011 - 08:44 PM, said:

I have had some success with my 900 mhz Xbee Pros, extended range for reduced bandwith, is 900 mhz ok in EU?
Franco

No, definitely not. 900Mhz is GSM as D-lite stated. Those mobile phone operators really do not want anything close which could compromise their network. They actually do search for people using the same bands illegally. 2.4 or 5.8 is the only way to go free in Europe I believe but even then it's quite restricted.

[Rattler]

D-Lite

I spent some time in your country in the military and there are times I still miss it.   I didn’t realize how limited you are on bands and power until I followed another link and read about it.  I also know that in your country’s you don’t want them looking at you.   Hear in the US unless you are direct interfering with the Government or some other broadcast you can get away with testing without to much fear of anyone hassling   you. Although if you were to do it long term you had best get a ham Lic.. I’m just trying to think out of the box for something  that was cheep and easy to use that would get everyone some range.  I have found some interesting stuff in Len’s blog an other palaces

Have you seen any of these APC802 APC802-43 Wireless Digital Communication Module for Arduino+USB Adaptor 3KM Distance.  I found the web sight that sells them some ware I thin on the foum.  It my be one of Berkley’s links. I think Berkley’s info on the APC 220 / 230 should work with this one.  It’s a cool sight has all kind of cheep stuff  KK boards Arduno.

Feature of APC802:
- GFSK transceiver Module
- 433Mhz ISM frequency band
- 9.6k bps data rate (or More)
- Multiple channels
- 27dBm Max. output power
- Baud rate configurable
- 256 bytes data buffers
- Standby current < 5uA
- Supply voltage 4.7~8V

Application of APC802
- Home automation
- Security alarm
- Telemetry
- Automatic meter reading
- Contact less access
- Wireless data logger
- Remote motor control
- Wireless sensor network

http://www.goodluckb...m-distance.html


The web sight is Goodluckbuy.com
http://www.goodluckb...o-1-page-2.html
I have some real interesting other ones I’v found that I’ll try to post in the next day or two.

[D-Lite]

Rattler, on 23 November 2011 - 08:12 AM, said:

I also know that in your country’s you don’t want them looking at you.   

Well, if someone calls the R/F agency ("Bundesnetzagentur") because his TV gets jammend, they will come and search for the source and it can become expensive if that's you. There's one of this R/F hunting car's base station located only some blocks away from me so I'm careful not to violate any regulations :-)
About the APC802, 27dBm would certainly be a problem. Also AFAIK, the ISM bands (443 & 886MHz) are restricted to 10% duty cycle so the effective bandwidth would be very low.

[Rattler]

D-Lite, on 26 November 2011 - 11:59 AM, said:

Well, if someone calls the R/F agency ("Bundesnetzagentur") because his TV gets jammend, they will come and search for the source and it can become expensive if that's you. There's one of this R/F hunting car's base station located only some blocks away from me so I'm careful not to violate any regulations :-)
About the APC802, 27dBm would certainly be a problem. Also AFAIK, the ISM bands (443 & 886MHz) are restricted to 10% duty cycle so the effective bandwidth would be very low.

D-Lite

Yup I knew in your country you had to be carful.  I have a couple of stories you would get a laugh at. Maybe I’ll PM you with them. ;<).  As far as the APC802 I think am going to try one as must of the info for setup has been done thanks to great work done by Berkely and the APC220.  It a good starting point for me for range testing.  Hear in the US we are much more open as fare as frequency range and power output.  I wish it were so in other country’s.  I am trying to get around 10 to 15k range for what I want to do. Although it would be fun to tests some 40k radios.  

Edited by Rattler, 30 November 2011 - 08:26 AM.

[Dane]

I'd be happy to help test the first batch wink wink.

Excited for long distance telemetry!

[jamie]

you are welcome to come here dankers to my buller for distance testing