Okay I work for a fire department in northern Arizona and i am looking for a plane with an xyz camera on it that can fly over the 800 acre location we work out of. I was wondering if there is a possibility to have both the controls and the video still work and ranges that long. This plane will be used here for flying over the facility and searching for wildfire for faster response. If anybody has a parts list that could benefit my needs that would be appreciated.
technically I don't know if what you are wanting to do is allowed based on the new FAA rules.. which in its documentations mentions the uses of such UAV platforms.. one of which was fire fighting recon.
I think your best bet for that sort of range would be using the EagleEyes OSD which has a antenna tracker.. and then use a long range yagii (directional) antenna for transmit and receive. If you have a HAM/Amateur radio license then you could use stuff in the 70cm (430MHz) range and get some great distances.
800 acres is 1.25 sq mi.. which doesn't seem all that large.. most directional antennas will give you a TX/RX for those distances. Diydrones.com has a 2.4GHz amplifier.. which would give you 4-8 miles on the TX side if you use a 2.4GHz radio.
For video.. well this is where you get into the HAM/Amateur radio stuff.. over a certain wattage you really need a technician class.. which isn't all that difficult these days.. rangevideo.com has some great TX for video.. like a 1000mW transmitter.
Then the real trick would be a good flying wing with some serious width so you don't have to fly all the fast and thus can look around more. You really only need a Pan and Tilt. UrbanDrones.com has a nice light, cheap one for $6.. that mounted to a lage flying wing should be pretty smooth.
sucks that you didn't get a response until 24 days after your 'bump'.. and a whole month after your original posting.
You can accomplish this task with a Millswood Engineering PTZ version of the Failsafe Device. My group DiyDroneSafety has been working in tandem with the fine folks at Millswood to hopefully be able to put out a Failsafe variant tailored specifically to the niche aspect of the drone community that you find at DIYD.
You may particularly enjoy the ability to use a Digi Xtend radio due to the possibility of up to 40 miles of range. Which ever telemetry link you chose, you will have the ability to operate the PTZ over this link, independently of your autopilot gear.
The normal product page is located here http://www.millswoodeng.com.au/failsafe_device.html and the PTZ version has additional information here http://www.millswoodeng.com.au/failsafe_ptz.html
The Failsafe PTZ provides the usual autopilot, RC and failsafe switching on the first 4 channels, but the remaining channels are dedicated purely to telemetry control of payload.
This means that servo channels 5, 6, 7 and 8 are controlled remotely from the ground by sending commands through the telemetry uplink. They are completely independent from the autopilot and RC receiver, and can be used for virtually anything. Typical applications include:
- Camera pan, tilt and zoom
- Parachute release
- Photo trigger
- And for the UAV Outback Challenge, activating a bottle drop mechanism
The 4 telemetry-controlled channels still have failsafe positions, so if loss of telemetry is programmed to trigger a failsafe event, cameras can be retracted (or at least pointed in a useful direction), parachutes released, and photos of the future crash site taken.
If you have concerns over legality as the previous poster mentioned I would head over to the FAA COA site. http://www.faa.gov/about/office_org/headquarters_offices/ato/servic...
Good luck and let me know if you need any help!
seems like overkill for something that the APM can deal with in regards to failsafe functionality.. continue on to waypoints or return to home... plus back to my original point.. 800 acres = 1.25 sq miles.. which really isn't that much distance.
Seems like most configurations can do a 2mile range pretty easily.
Regarding the FAA link.. there is currently a lawsuit regarding these wavers since the FAA has granted a few dozen of them in total.. and so the lawsuit seeks to get the list of who has been granted wavers.. this path seems like a dead end due to the limited number of wavers really being allowed.
It actually wasn't for the failsafe functionality in this case, more so the PTZ control which works independently of any autopilot APM or otherwise. As I tried to point out with the documentation, you can control your PTZ channels via an XTend or any other telemetry link if need be. It just happens that the product that provides the function is generally intended for failsafe implementation. Considering the fire recon / public safety aspect of things it may not be a bad idea incase this thing evolves a bit more over time.
Since you mentioned it however, with regard to what the APM *can* deal with failsafe wise... please educate yourself and be aware that when the APM code locks up or freezes you are done for failsafe wise, it will never kick in. The APM is unable to perform as a proper failsafe until the Watchdog functionality of the boot-loader is updated and implemented. http://code.google.com/p/arducopter/issues/detail?id=237
Currently at any point that the code has an unexpected failure (or even potentially a logic flaw) your gear can simply fly away... this was last demonstrated when a bad i2c library was introduced (which was fixed aprox 9 months ago). It is however actually an inherent problem in the platform waiting for other issues to uncover it once again. If you are convinced that those sorts of bugs are long gone, I encourage you to look at how the new flip.pde code works as an example. I would argue that a logic flaw was introduced which influenced failsafe behavior, it won't be the first, nor the last time something like that occurs. Luckily It just happens to be in a novelty section of code for now. http://www.youtube.com/watch?v=06KtCxbNBgs
If this still doesn't make much sense you should watch these videos and understand that the APM *can* do nothing at all to prevent the issues that are demonstrated from occurring in its current form. At this point the hung code continues where ever it stopped, indefinitely. Assuming another code bug turns up in the future before the watchdog is properly working, this has obvious implications.
In short... yes the APM *can* deal with some failsafe conditions, but the caveat is that the rest of the code must be running properly (not locked up). Additionally as demonstrated this also assumes that some other sort of logic flaw has not overridden proper behavior. This is a bad chicken / egg scenario for folks that rely on or expect the failsafe to work at all times.
The failsafe page was recently updated with the following information to make its functionality more clear. http://code.google.com/p/ardupilot-mega/wiki/Failsafe
Items 1, 2, 3, and 4 can be influenced by an outside failsafe device such as the Millswood Engineering Failsafe board.
Item number two in particular can be used via the Geofence input pins on the Millswood. Although Andreas has created awesome Geofencing code for use with the APM, it is useless in one of the previously described logic flaw or lockup conditions happens. IF you were able to put the old i2c library back in place in a git clone of the current code WITH geofence support, you would find that the Andreas fence code is unable to prevent a drone from breaching the fence during an i2c lockup. Any other lockup will handle the same way.
I wonder what happens with that flip.pde logic bug when combined with a Geofence ceiling limit from the AP_Limit code... ;). Who wins the race condition Geofence code or flip.pde?
Alas, although the FAA path may be dead it is currently one of the *proper* avenues to head down IF one has legal concerns. If the FAA specifically mentions fire recon rules... don't ignore them simply because the documentation requirements has a history of getting denied or tied up in court.
Monroe I know we tend to have conflicting personalities but feel free to hit me up here or via email if you want to help out. DIYDroneSafety has been working with Millswood Engineering for a few months now in private on this subject. We are still mostly in the cat wrangling & idea fostering phase at this point...Your input would obviously be valued.
Anyone else here is welcome to do the same... we are trying to get a handle on as many scenarios as we can account for and simply provide folks with some options to make intelligent decisions in an autopilot agnostic environment. Hit us up if you are interested.
Interesting stuff.. yeah I am new to all of this.. which is exciting to have such entrepreneur activities going on and other innovative ideas. I think the concepts of the open community will allow for all sorts of awesome stuff to solve all sorts of interesting problems.
I think the original message functionality for fire spotting is pretty cool... granted the reason forest fires are so bad in recent years is the fact we don't let the brush burn out naturally.. so when there is a fire you got a lot of material to burn.
Interesting Topic..... I know there is some video analisys software that can recognise smoke and fire and sound an alarm. The million dollar question is whether it can trigger that alarm based on composite video feeded by your real time av transmition.was you would use a VTOL for this project since the distance you need to cover is not that big and in case you need to doublecheck a spot you can do it very nicely with an autohover.