If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.
Special Thanks To:
Aaron Holmes
Aaron Wheeler
Adam Horden
Alan Scrimgeour
Andre
Andrew Haynes
Anonymous000
asabase
Austin Weil
barney
Barry
Bert Hickman
Bill Kukowski
Blitzorn
Brandon Paradelas
Bruce Bowling
BubeeMike
Byong Park
Cesiumsponge
Chris F.
Chris Hooper
Corey Worthington
Derek Woodroffe
Dalus
Dan Strother
Daniel Davis
Daniel Uhrenholt
datasheetarchive
Dave Billington
Dave Marshall
David F.
Dennis Rogers
drelectrix
Dr. John Gudenas
Dr. Spark
E.TexasTesla
eastvoltresearch
Eirik Taylor
Erik Dyakov
Erlend^SE
Finn Hammer
Firebug24k
GalliumMan
Gary Peterson
George Slade
GhostNull
Gordon Mcknight
Graham Armitage
Grant
GreySoul
Henry H
IamSmooth
In memory of Leo Powning
Jacob Cash
James Howells
James Pawson
Jeff Greenfield
Jeff Thomas
Jesse Frost
Jim Mitchell
jlr134
Joe Mastroianni
John Forcina
John Oberg
John Willcutt
Jon Newcomb
klugesmith
Leslie Wright
Lutz Hoffman
Mads Barnkob
Martin King
Mats Karlsson
Matt Gibson
Matthew Guidry
mbd
Michael D'Angelo
Mikkel
mileswaldron
mister_rf
Neil Foster
Nick de Smith
Nick Soroka
nicklenorp
Nik
Norman Stanley
Patrick Coleman
Paul Brodie
Paul Jordan
Paul Montgomery
Ped
Peter Krogen
Peter Terren
PhilGood
Richard Feldman
Robert Bush
Royce Bailey
Scott Fusare
Scott Newman
smiffy
Stella
Steven Busic
Steve Conner
Steve Jones
Steve Ward
Sulaiman
Thomas Coyle
Thomas A. Wallace
Thomas W
Timo
Torch
Ulf Jonsson
vasil
Vaxian
vladi mazzilli
wastehl
Weston
William Kim
William N.
William Stehl
Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Registered Member #2901
Joined: Thu Jun 03 2010, 01:25PM
Location:
Posts: 837
Patrick wrote ...
the N wireless router were used, its complicated settings and code that are cuasing the failures not the transmitting/recieving router itself...
in august 2012 it seemed the routers stayed up and running almost constantly, but the machines/desktops just wouldnt syncronize for useful data. the machines that were flying often hovered, then with a 3 second delay flew themselves into walls then, while crashed in pieces on the floor, it then tried to execute a collision avoiding turn.
With all due respect, if you can't do a simple remote procedure call over a reliable wireless connection of negligible latency and relatively high bandwidth you're doing it wrong. It's only complicated if you work hard at making it complicated.
That said, how are you so sure the connection was reliable? WLAN is prone to interference because it's such a polite protocol and sticks to a single channel, the delay could just as easily be from exponential back off and if they are stupid enough to use TCP that would only make it worse.
Registered Member #30
Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
There's no such thing as a simple remote procedure call. Distributed computing is always going to be tricky, and real-time deadlines only make things trickier.
I say this having written my own RPC library that can do 10,000 RPCs per second.
Registered Member #2901
Joined: Thu Jun 03 2010, 01:25PM
Location:
Posts: 837
Most of those problems come into existence when you don't treat the connection (and the remote party) as 100% reliable ... if as Patrick maintains they are that simplifies everything.
Although as I indicated, I kinda doubt the connection is that good.
Registered Member #30
Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
That's exactly the issue with distributed computing. When you call a regular function, you know it's going to execute and return a value. But when you do a remote procedure call, it could fail. Either it times out, or hangs forever, or if you decided to be very clever and do non-blocking transactions, your program already carried on without knowing if the RPC failed.
If you try to handle this gracefully, you get screwed by the complexity. If you ignore the issue and pretend that remote procedure calls will never fail, you get screwed when one eventually does fail.
I dealt with the issue by using a very simple RPC protocol and making sure the underlying hardware bus really was reliable. Patrick may need some other approach. I would have the drone default to hovering motionless, sending sensor data back to the desktop machine, until the desktop commanded it to make a move, along the lines of "Go 10 yards northeast and wait for my next command".
The drone could have a very basic collision detect algorithm on board to stop it from smashing directly into walls if given bad commands. It's easy to stop the commands getting corrupted in transit by just adding a CRC. But it's much harder to stop the desktop software from interpreting the sensor data wrongly and commanding the vehicle to fly into a wall that it didn't realise was there, so I would want a second opinion from a simple algorithm that has access to fast, accurate real-time data. Not "wall 10 yards away" but "wall real close right now!"
For extra brownie points, you could hook the desktop software up to a simulated vehicle in a virtual maze and test it without trashing anything, except a lot of 1s and 0s, but those are pretty cheap.
What does the AR Drone do when it loses its wi-fi connection?
Registered Member #2431
Joined: Tue Oct 13 2009, 09:47PM
Location: Chico, CA. USA
Posts: 5639
Steve Conner wrote ...
What does the AR Drone do when it loses its wi-fi connection?
the Indian university teams found, if they unplug the wifi router, there Ar just hovers indefinatley, they had to activly transmit a fail-safe turn off command, so they were disqualified and prevented from flying at all in 2012.
Registered Member #2431
Joined: Tue Oct 13 2009, 09:47PM
Location: Chico, CA. USA
Posts: 5639
Steve Conner wrote ...
Is that a safety rule, that it has to shut down if it loses signal?
in the past its been complicated though. yes there must be a positive safety fail... the absence of a "keep alive" signal must cuase shutdown.
They used to have nitro/alchol 700 size helis, a common kill mechanism was to have a servo pinch the fuel tube shut. however when one team did this back in 93ish, the engine ran lean off the float carb remanants producing more power, then it flew out of control closely past the epcot dome continued above the parking lot and crashed in front of a bunch of African school children. no one was injured, but after that they really have been on us about safety.
Registered Member #2901
Joined: Thu Jun 03 2010, 01:25PM
Location:
Posts: 837
Patrick wrote ...
EDIT/UPDATE: found this for 55 USD, 25 Grams!!! i just dont know how to interface to it !?
The processor is nice, but with no GPIO breakout it's kinda limited ... the amount of GPIO broken out on Raspberry PI is sadly pathetic too.
The Cubieboard is shaping up to be the best platform for A10 hacking :
Dunno when it's shipping again though. In the meantime the Beaglebone is one of the nicest development boards with a relatively powerful processor, only 36 grams too.
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.
CSU Chico Tilt Rotor Flying Machine, (Programming and CPU, 3 of 3).
