Back over the golf course to test yet another camera mount.
Unfortunately, we've done everything possible with the Aiptek & it still warps.
AUTONOMOUS MARCY 2
Marcy 2's roll gyro failed, but before the gyro failure & crash She finally hovered Herself long enough in sonar to get some shots. Definitely the hardest vehicle ever because of the number of things built from scratch.
There's the broken gyro.
The answer is yes. Pads on $11 chips can fall off. Fortunately had 1 spare gyro. This is the last of the analog gyros. All future gyros use high speed I2C, which means either mounting on the main board & facing temperature instability or using an off board microcontroller to convert the I2C to something useful.
& there She is hovering in sonar.
The radio still won't initialize on the golf course, so we're limited to 1 battery. Would be so much easier to use off the shelf parts. Sonar hasn't been precise enough to get the tight hovering we need. Overall very dissapointing.
Next, the tethered ground station cables are 25 years old & if they go, it's siyonora in 60 nanoseconds.
OCEAN VIEWS
Have some aerial shots over Half Moon Bay. The weather was spectacular, the aircraft was perfect, & the view from 400ft was stupendous. Surprised the weather was perfect. It's never sunny here. Limited the altitude because it was very crowded & a human airport was nearby. Can't fly any closer to the humans.
Next, we have the videos.
Didn't shoot for timelapses but decided to throw it in the editor & see what happened. 1st impression is the taxpayers are going to have some killer flooding damage to pay for.
1st impression is the taxpayers are going to have some killer flooding damage to pay for.
Can't remember where to find those Arduino pin mappings? Forgot your FTDI wire meanings? You need this handy cheat sheet, which has all the most commonly needed info in one easy-to-print form. Pin it up your workshop wall!
This is my first fight with a Sony Webbie mounted on my Twinstar 2 attempting to target a known GPS location on the ground using the gyro information from the UAV DevBoard.
Specs Shrediquette DLXm Motor shaft distance: 132 mm Max. dimension: 259 mm Weight: 230 g Props: 5x3 3-blade GWS Motors: Roxxy 2216-25
ESCs: Turnigy Plush 6A with I²C->PWM converters Battery: 3S, 800 mAh Max thrust per motor: 237 g Thrust to weight ratio: 3.1:1 Total current during hover: 4 A Endurance: 11 mins
Following on with Chris' humerous submission today, and the bit of storytelling we have been enjoying in recent blog posts, I figured I'd post my latest tale of woe. Hopefully you will find it entertaining!
So, this past Saturday I competed in the SparkFun Autonomous Vehicle Competition using an ArduPilot with 2.6 firmware and ArduIMU. My airframe was the SkyFun from HobbyCity.
A few days before the competition SparkFun sent out an email saying I must submit a "team name". At the time I was in a bit of a panic because I was rebuilding my UAV from a crash suffered a few days earlier. While working on autonomous landing I discovered I had not planned my final waypoint very well and hit a pine tree. So, I told SparkFun that I was Team Death by Pine Tree! I glued the 2 halves of the fuselage together and continued on.
Friday, Ryan Beall was in town and we were sitting around and just couldn't stop ourselveds from trying to make 1 FINAL IMPROVEMENT.... I was not entirely happy with my altitude hold. It was tight enough for regular flying around, but not as tight as I wanted for doing auto landings. Ryan said (see how I try to give him part of the blame ;) ) lets just work through the math and see if the gain values make sense. So we did - and concluded the gain on the altitude error was way to low. We boosted it by a factor of 20. Does something smell fishy here. Of course when I worked through the math I forgot that I should be using altitude error in centimeters, not meters, so we had made the gain far too high. This caused a huge pitch oscillation that ended in a very spectacular sounding crash into a Maple tree. Time to call SparkFun and change the team name? Team Death by Maple Tree? This time the airframe was too far gone so I pulled all the electronics out and put them in my backup SkyFun.
Saturday was the big day. My UAV was flying great, with the fastest lap times by far, but I was too chicken to try auto landing the first 2 rounds. The final round came and I figured it was now or never. Mentally prepared for whatever auto land might bring out I saw my UAV inexplicably ignore the bits of code telling it to slow down at waypoint 9 and cut the throttle at waypoint 16. Instead it just kept ripping around and starting over at waypoint 1. SparkFun had assigned a 15 second deduction for auto landing and a 30 second deduction for auto landing with the UAV coming to rest inside a roughly 10 by 20 meter area. I asked the judge standing next to me "If I do nothing and the UAV arrives on the ground, then that is an auto landing and good for 15 seconds, right?" He looked a bit perplexed and said "well, yeah...". OK I thought, low voltage cut-off here we come. And a few minutes later it did come, followed by a nice little crash into an adjacent parking lot. The SparkFun band picked up on that immediately and began singing about Death by QualComm Parking Lot. On Monday I glued the 4 pieces of the fuselage back together.
Peter Hollands has been stuck here in Colorado since the SparkFun competition due to the Iceland volcano eruption and cancelled flights. He emailed me about getting together and I told him that today I would be taking the UAV to show to the local high school robotics club. He was quite happy to come along. We met a great group of kids and had fun talking with them about all kinds of robotics and UAVs and Arduino stuff, etc. Then we went outside for a demonstration. The high school has a lot of athletic fields, but the track team was using the football field, the soccer fields were all in use, as were 2 of the 3 baseball diamonds. With only 1 choice we headed to the open baseball diamond. I looked it over and said I was a bit nervous about the poles and fences so I told the kids they would have to settle for manual take-off and landing. But we had a pretty good demonstation. Then it was time to land. The first pass it was apparent early that I would float too far and hit the outfield fence, so I went around. The second pass was better, but still too high. For the third pass I figured I would come in nice and low over the outfield fence on the first base side and head towards the other corner of the outfield. All I had to do was steer around the foul line pole. Peter said "your going to hit the pole". "No," I said, "I see it". Then whack!
Tomorrow I will glue the pieces together again......
Team "Death by Foul Line Pole" just doesn't sound quite right.
Power: 8V to 12V DC power supply. Some transmitters, especially those FUTABA ones, can supply power directly by trainer connector. (ex. T9Z, FF9C). Some transmitters cannot supply power to X-GYRO, for example 14MZ and 12FG. The simplest solution is to use an extra battery for those RC transmitters. The connector is already included in package. Size: 25mmX35mm Weight:20g Range for measuring: +-90 degree/second rotational speed movement.
Default Setting: Channels: X axis- channel 7 Y axis-channel 8 Detective range G45 degree
The ground station electronics box houses the telemetry hardware that keeps Andromeda connected to the base. The ground station controller keeps communication flowing even if the ground station computer is disconnected while the routerboard will relay digital video via ethernet.
Currently we haven't got any antenna connectors but they'll be coming soon. The usb and ethernet connectors above are for telemetry and video respectively. The other two connectors are for the catapult and dynamixel actuators. The catapult connector allows the GSC to launch the aircraft and measure launch speed. The dynamixel connector facilitates the movement of the antennae. Next update will hopefully be some AHRS progress and equations,etc.
I just thought you guys might like to know that we are still making REAL progress over in our workspace. Sarel has been working hard on his prototype and as you can see, mine is coming along as well - we should be combining all of our trials an errors soon and have final schematic and board designs soon. So who else might be willing to help out and lend us a hand programming all that graphical goodness??
I've been reviewing the latest developments in "Adaptive Control" as opposed to PID control and came across this video of a quad adapting to a broken rotor blade. Hopefully, we will soon use these types of algorithms in our own diydrones projects. Read more…
I have been wanting to fully document my SAGAR (Semi Autonomous GPS Assisted Rover) for some time now, and the 'ardupilot goes into the water' series has been so entertaining, it gave me the motivation to finally start. The first post was simply a demonstration of the LabView ground station, which has been redesigned one last time before my girlfriend is turning in the project. First I'll show the new interface, and talk about how it communicates with SAGAR, and give some background on why I built SAGAR.
Here is a video of the new interface, with an inset of SAGAR as it runs the mission.
During the run we recorded, there was a glitch half way through. It appears Labview started to slow down and the gap between live events and what was being displayed grew, until the Labview buffer overflowed and sentences where lost. I have yet to look into that problem, as it is the first time we have observed it.
When my girlfriend came to me for ideas for her LabView class, I suggested she write an interface for my robot. I knew I would have to develop a communication protocol that I could hand to her from the start. I took a look at the structure of the ArduPilot communications, and it seemed odd to me. Is the structure a known protocol? I'm sure one of the developers will tell me.
I decided to stick to something I knew, the NMEA protocol. For those who are not aware, GPS systems communicate via the NMEA protocol, as do many other robotics systems. The structure of a NMEA sentences starts with a header that identifies the sentence, then comma delimited fields that contain the data to be passed. The sentence is usually followed by a checksum, to validate the integrity of the data. I came up with my own header, and added the fields of sensor data I wanted to have displayed on the interface. Here is an example of my structure.
$SAGAR,heading,pitch,roll,wheelspeed(Commanded l+r, actual l+r), distance_trav,GPS_Fix,GPS_Lat,GPA_lon,GPS_speed,GPS_COG,Battery_V,Battery_I,processor_load*CS
This is one of two sentences SAGAR will send to the interface. The other sentence contains mission statistics like current waypoint number, distance to waypoint, etc. There are also 4 sentences that the interface sends to SAGAR, each representing a different mode for SAGAR to enter, and commands to follow. There is a fail-safe in place, if SAGAR doesn't receive a command sentence in 500ms, it halts and enters stand-by.
To finish off this oddly ordered intro, I 'll give my motivation for building SAGAR to begin with, starting with a quick life story.
To most of the locals around here, I am a young gun. This time last year, I was nearing the end of my college career. All my life I knew I wanted to be an electrical engineer, but I never really knew what branch I wanted to specialize in. The family business was generators, so I took as many power classes I could sign up for. It was ok, but I wasn't a fan of all the extra math involved as opposed to other fields of EE. My last year of school, I had to build a senior design robot as defined by the IEEE 2009 SouthEastCon Hardware Competition. I had a blast. I instantly realized the field I wanted to be in was robotics. The robot my group built did so well, if it had gone to the competition (long story of why it didn't) it would have crushed the competition as during every test run it easily doubles the score of the robot that did win. Here it is:
I am very proud of how well it works. After graduation, A division of the U.S. Navy that specializes in unmanned robotics got a hold of this video and asked for my resume. Now I work with million dollar underwater, surface and ground drones; ie my dream job. The only problem is I don't have much experience building robots that are not made of Legos, or the only purpose is to pick up recyclables. So the month I started working, I started building SAGAR to gain the experience I wanted of the internals of unmanned drones. SAGAR started as a bag of parts nearly a year ago, and grew from there. (Almost) everything is from scratch, down to DIY battery packs.
Not too shabby? Forgive and spelling/grammar, I am definitely bad at both.
Comming up next: The importance of a good chassis, and building my own closed loop motor controller.
Hi Guys found this today which was one thing lagging in my setup , I was unable to get/hack RSSI signal out for my Spectrum AR7000 RX to be used in Remzibi OSD or any other OSD for that matter. It is 18$. I hope this helps droners with Spectrum RX and similar wish, have fun ,Cheers
A video below demonstrates how Skilligent Visual Localization System can be used to solve an outdoor localization problem. The camera is mounted under the belly of an unmanned aerial vehicle (UAV). The camera is used to search for visual landmarks on the ground (a terrain matching based navigation)
The creator explains: "No jailbreaking. No WiFi. Stock receivers. I fly model airplanes and helicopters with my iPhone. I use an off-the-shelf 2.4GHz module and a custom iPhone app. The app is now in beta testing.
I use the phone's headphone jack to communicate with the Spektrum module. I make no modifications to the module or the receivers. This application does not use WiFi, Internet, external servers or microcontrollers."
