jbd

Inspecting fields. Counting cattle/goats/livestock. Checking for downed fence lines. Checking water, mineral trays, ...

Of course, you would need video on the UAV, and a high-speed data/video connection to its camera.

Weather is the biggest challenge - it can't be used in moderate wind or gusty conditions. So a fairly good "localized weather" station system might be in order too. Another challenge might be areas of high pollen concentration - depending on the drive mechanism for the UAV.

What we found is if we have to go to the field anyway, then we might as well do the inspection ourselves rather than fool with setting up and packing away a UAV. Having a fixed, computer controlled flight path for a large field might make it more worthwhile - but then there's problems with RC radio range.

The number of reads and possibly the popularity of the article wrt other articles in the same group. I think exposing user names might be seen as a challenge to privacy.

Water weighs about 8lbs/gallon, so a full 250 gallon container would weigh at least a ton, and a lot of roofs can't support that kind of weight in a small area.

Another thing to consider is surface area - the more surface area you expose the water to, the more heat loss there'll be. So on a cold night, you may lose all of your heat by midnight instead of 6am! Using a variable number of bladders that can be easily filled from a larger water mass (tank) is probably best. Good idea Louis!

The http://farmhack.net/forums/tool-wiki-template link above results in a "Page not found" error.

Feel free to delete this comment when/if the above is fixed!

I believe Louis was indicating that we could do positioning without GPS; which is technically correct but not necessarily desirable, and assumes we know exactly where the anchor points (aka base stations) are located.

Synchronization of the end points (ear tags) with the anchor point is no longer required since the anchor point will be sending the signal to the end points (ear tags), which will just echo it back; and all timing (with a 700 MHz clock) occurs on the anchor point. However, synchronization of the anchor points will be required for the reasons you pointed out. Since all the anchor points will have GPS's on them, this can be done with reasonable accuracy, and be checked/re-done frequently.

Latency in the radio, GPS, and CPU (deterministic and non-deterministic) will have to be empirically determined. And we'll have to re-run the tests with every new batch of processors, CPUs, GPSs and XBees. Sigh.

I like the two way transmission idea. The anchor point doesn't have to be quite as fast - but still needs to be able to sense the departure and return times within 300 microseconds. And we can "fake" a signal by wiring the TX to the RX on the ear tag.

I too am making the assumption that turn-around time is constant - at least between the XBees. We'll need to empirically test how much latency the mesh network adds too.

I'll start looking at a device driver to do this (because it needs to be done at interrupt level to keep the OS from introducing latency). Once I get the driver done and tested, we'll need more beaglebones and XBees to test/write the trilateralization logic.

Oh, I guess we'll be needing the GPS interface logic written too. That is critical for translating the "local" positioning info into global positions.

So, I guess the real next step is software architecture planning.

You'll need something to convert the sensor signal to serial data so it could be sent over the XBee's modem.

Unless you're just sending 1 bit of info, in which case you can use the DTR pin on the XBee. This would probably work for preset alarm info.

I really like the idea of having classifieds. Although I think it would be best to exclude companies from submitting things for sell, just let it be individuals.

The GPS has arrived and I verified its operation on the beaglebone.

Also, Ben Smith (from CCOM at UNH, and an old sailing buddy) has joined the project and briefed me on the PPS (Pulse Per Second) signal provided by most GPS's. Since, to keep cost of the "roving radios" down, we won't have much computational ability on the rovers (if any); rovers == cattle ear tags.

I've noted that the chronodot has something similar to the PPS, but I don't know if it is tied to the "start of the second" like it is on most GPS devices. Iif it is, and if it gives us sufficient accuracy, then we can use it for sub-meter accuracy. (I'd really like to have 1-inch accuracy, but I'm willing to give up on that somewhat.) The chronodot is low power and relatively temperature insensitive, and we can probably get it to shut down every few seconds to improve the power consumption.

I think the next steps are:
1. Prototype an "ear tag" rover with an XBee, battery, and chronodot.
2. Verify the rover can talk, over the XBee, to an anchor (Beaglebone with GPS and XBee).

This appears to be http://www.farmshow.com/

We can always transmit the data we get from the radios on the mobile units, upload it to the anchor points, and let a server do the computations. Supposedly the anchors are fixed positions (and may be GPS enabled).

However, as I remember my radio theory, we will need a number of samples to get a reasonable approximation to use in differential distance computation to the anchor points. Each radio will have to be calibrated to determine what its "reasonable sample rate" would be. Or does the Zigbee already do this? (does it provide a signal strength, or do we have to get the analog strengths in real-time)? Or am I thinking too deeply?