Hello to all,

A new VTOL OAT Bicopter fully stabilized by a 9DOF IMU (arduIMU v2 + HMC5843) has successfully done its fist series of flights. This is the SCORPID-450 build by Matthieu Bourdarias from the french VTOL-UAV Team. The Scorpid-450 UAV uses an innovative design based on Gary Gress concept. The Oblique Active Tilting (OAT) at 45° of the twin engines allow a full pitch control by using the induced gyroscopic moment. Now with only a 9D0F IMU its flight is fully stabilized on its all axis with a dedicated firmware (AutoStab v3.31 JLN) and a special mixing software.

Here the setup used by Matthieu Bourdarias:

- ArduIMU+ V2 flat,

- HMC5843 Triple axis magnetometer,

- Firmware AutoStab v3.31 by Jean-Louis Naudin,

- Two brushless motors + ESC: EMax CF2822 (202W, 1200KV),

- 1 propeller GWS HD9050Rx3 - 1 propeller GWS HD9050x3,

- 1 receiver Futaba R617FS,

- 1 Lipo Turnigy 11.1V (3S1P) 2600 mAh,

Stay tuned on: http://diydrones.com/profile/JeanLouisNaudin

This is a quick and dirty flight visualization tool I use with scicoslab for autopilot/ control design. Its great when you are running on a laptop or older computer and you don't have the horsepower to run scicoslab and flightgear at the same time. I'm working on an airplane version that should be done soon.

hello all on this forum,

i have started building my quadrotor. and i am using arduimu v2 flat as a main controller.

i am very new to all those things,uptill now i got my arduimu v2 and i just programmed it with

the latest firmware 1.7ver with the parameters said in the program for testing and

i also tested it with the happykillmore sofware and is working well.

so now my question is the values which are said to be set in the firmware should i change them

since i am using only arduimu v2 flat and no magnetometer and no gps module.

and 2nd is how to do PID tuning since i dont have any idea about this.

and how the arduimu recognizes the perticular s isnal coming from transmitter.

please anyone help me out.

thanks in advance

From the description: "The robot is equipped with an IMU, camera, and laser scanner with deflective mirrors. All computations are performed onboard using a 1.6GHz atom processor. The robot is able to navigate autonomously in indoor or outdoor, GPS-denied environments.

A SLAM module with vision based loop closure allows the robot to map large-scale, multi-floor environments.A sparse 3D map is generated on the robot based on sensor data, enabling high-level planning and visualization.

An RRT* based planner provides an anytime planning solution that fits the computational constraints of the robot. This planner also enables online re-planning and obstacle avoidance.

An LQR optimal controller with external force compensation enables reliable autonomous flight in highly constrained environments, such as hallways, doors, and windows. The robot is able to track the high-level plans accurately."

From I Love Robotics: "More quadrotor action from the team at UPenn (Shaojie Shen, Nathan Michael, and Vijay Kumar). A previous video of their earlier work is here.

ROS seems to be helping with the team's productivity, but I am still looking for a paper to go with these videos for more details. Once again thermodynamics and energy storage look like the biggest performance limits facing quadrotor aircraft."

Sikorsky Cypher; Although the Wikipedia article on this UAV claims it was developed in the late 80's, It was a classified project in the 70's. I know this because I personally put many of the used and damaged blueprints in the "burn barrel" with other top secret documents in 1974.

I am not sure why this was classified as it was devloped at a university in the 60's and quite well known at the time.

Now, here is my question: What was the university and professor that invented it ? for the life of me I can't remember. I think it was at Stanford but I can't find any info on it anymore. There was a video clip of it in an old documentary but I can't remember it either. Getting too old I guess.

Hi Guys

Good news from OpenLRS (Opensource Long Range System) project!

Today i received 7 watt RF booster chips and at last i'm ready to finishing the PCB designs. This weekend i will finish the booster design and PCBs will be ready in 3 weeks.

Here is the latest PCB designs of Tx, Rx and IMU modules of OpenLRS

Tx and Rx modules size smaller than most of RC modules. Rx module including I2C (or 3 adc) conector pads on back side. I'm planning to connect my new 6DOF IMUnext v3 board there. Rx can stabilize the plane (or quadro) without any external parts and it sends the parameters to the ground over telemetry system. And Rx's rs232 port already available for digital telemetry or direct GPS connection.

Some advantages of OpenFARC:

• Direct ground computer based remote control and telemetry (Autopilot by computer?)
• Rx based Autopilot/stabilization/return to home.
• No Frequency hoping. I'm planning to using static 2 frequency switching for safety. You can use 2 or more modules for receiving the telemetry signals or transmitting the controls with static frequency, because you know your frequencies. Or hopping already possible.
• If you want to use it for really long range, you can add 7W booster on Tx module (only one way control without telemetry)
• Direct analog RSSI output on Rx
• RS232 telemetry and commandset (like "S2512" mean turn the 2th servo to center position,etc)

I'm developing OpenLRS project with AVR-GCC on Atmega328 chipset. All ATMEL developers are welcome ;)

Here is a link to another Skywalker platform. Looks interesting. Big? Seems to have alot of room in fuselage and cheap?

http://www.bevrc.com/skywalker-168cm-epo-airplane-version-ii-specially-designe-p-17.html?zenid=1df4381c909c643178cb5447f0e67c7f

This week's "EAA Hotline", an email newsletter for EAA members has a story on the Team Black Sheep video. They don't state a position on the flight, but report AMA's position, and conclude with:

"The FAA includes R/C aircraft flown by modelers in its definition of Unmanned Aircraft Systems and states its “recreational use of the National Airspace System is covered by FAA Advisory Circular (AC) 91-57, which generally limits operations to below 400 feet above ground level and away from airports and air traffic."

http://www.eaa.org/news/2010/2010-12-09_zephyr.asp

That video is getting notice in a lot of places...

Perhaps I was missing something in VB6. Life seemed so much easier when using the serial port control. Granted, MSCOMM has some serious limitations (see max limit of COM16). But back then, sending a character from ASCII 1 to 255 was a non-issue. If you sent a &HA0 out the serial port, you got &HA0 out the other end. More specifically, if your hardware was streaming binary data in to your serial port, it was simple enough to decode. In .NET that changed.

In my GCS project, my intention is to be able to handle many different types of data input, both ASCII and binary..so I had to make a decision on how to handle the data stream. Should I import it as a byte array (encoding is not an issue if you receive data this way) or as a string so I can use SubString (or Mid, Left and Right) functions on the data. Since there's no easy way to do an InStr function (searches the string for an occurance of another string) on a byte array, I opted for the string.

When dealing with human readable data, there's no problem. Even without specifying anything for the .Encoding property of the SerialPort anything that is ASCII 127 or lower will pass through the port, no problem. As soon as you start streaming binary data that goes all the way up to 255, funky things start happening. So what's the deal? Well, in .NET the data coming out of the serial port is automatically encoded (or really decoded). That's because it's sending Unicode data. This means that some characters are not a single byte but instead are represented by 2 bytes.

But I don't need any of that. I just needed one byte per character. Nothing fancy. 1 to 255 is just fine.... but there's no option to turn this "feature" off. The SerialPort1.Encoding property can be set to all sorts of settings. Generally, I knew I needed 8 bits, so UTF7 was not an option. So I tried System.Text.Encoding.UTF8, System.Text.Encoding.GetEncoding(28591), System.Text.Encoding.GetEncoding(65001) System.Text.Encoding.GetEncoding(1251), System.Text.Encoding.GetEncoding(1252). The best results came from GetEncoding(28591) initially. I thought everything was working great... but then throw in Regional settings and everything gets whacky again.

In XP, click Start, Control Panel, Regional and Language Options and change your Standards Format from English (United States) to Polish and you'll see what I mean. It's the craziest thing. I created a sample project using a com0com feedback port to pump ASCII 1 to 255 out one port in VB6 and I received it in to my GCS on the paired port. 246 of the 255 characters came through just fine. 9 of them were goofy (either a 3F...which is the "unknown" replacement by the serial port or something comepletely odd like &H54 where &H98 should have been).

So the Google search began. How if the world do I fix this or turn it off or something? The first solution was to try and use Chr on some ASCII values and ChrW on others...but that didn't fix all of the bad characters either. The data was coming in with the right hex value, but the change from Byte to ASCII was the problem. In the end, the solution was not to look at every byte. I get rid of the Serial Port's DataReceived event and instead am firing a timer every 75 ms looking for .BytesToRead > 0 and using a built-in encoding function to get the right string from the serial port.

nReadCount = serialPortIn.BytesToRead 'Number of Bytes to read
Dim cData(nReadCount - 1) As Byte

serialPortIn.Encoding = System.Text.Encoding.UTF8

nReadResult = serialPortIn.Read(cData, 0, nReadCount) 'Reading the Data

sNewString = System.Text.Encoding.Default.GetString(cData)
sBuffer = sBuffer & sNewString

Originally, I had been allowing the DataReceived event to fire after 1 character arrived in the ReadBuffer and then evaluating the new character(s) one at a time to build my strings. Without the GetString function, I was unable to get the correct string data from the serial port.

Andrew Straw, a Caltech scientist who studies neurons and behavior, is leading the research, supported by an Air Force Office of Scientific Research grant. In order to better understand how fruit flies navigate, Straw basically forces the insects to play an immersive videogame of sorts. His lab has designed a virtual reality environment for the flies, giving him complete control over the visual stimuli they're exposed to. He and his fellow researchers also developed a tracking system that locates a fly in 3-D "nearly instantaneously." By tossing the fruit flies in the VR tunnel, controlling what the flies see, and tracking them precisely, Straw has an unprecedented sense of how the flies use visual cues to navigate.

What he found was surprising. Previously, it had been thought that flies measured motion beneath them to regulate their height. Straw's team, by contrast, has found that horizontal edges are the most important cue the flies use."

From AMA Today December 2010 (electronic newsletter)

Update on FAA

The FAA process to create regulation for the operation of small unmanned aircraft systems (sUAS) in the national airspace continues to move forward. There's been a lot of speculation about what will be contained in the sUAS proposed rule that is scheduled to be released as a notice of proposed rulemaking (NPRM) sometime in June 2011.

The NPRM will contain proposed regulation that will most likely have some impact on model aviation. The FAA is prohibited by law from disclosing the exact language in the NPRM until it's released in the Federal Register. However, we have been able to determine, in a generic sense, what some of the proposed language might be. The Aviation Rulemaking Committee’s report submitted to the FAA in 2009 indentifies many of the sUAS issues under consideration; however the specific recommendations in the report may or may not be reflected in the final rule. We know that the NPRM will most likely address things like how high, how fast, and where a model aircraft may fly. We know that the FAA has drawn a hard line between recreational use and commercial use.

AMA is continuing to work with the Unmanned Aircraft Program Office (UAPO) within the FAA and is in contact with the UAPO on a weekly, if not daily basis. Over the past 90 days there have been five face-to-face meetings with AMA and the UAPO staff. AMA’s internal workgroup, consisting of members with a diverse and knowledgeable model aviation background meet by conference call weekly and continues to develop standards that will eventually be submitted to the FAA for adoption that will allow modelers who follow these standards additional latitude from the rule. The foundation of our standards has always been the National Model Aviation Safety Code and its supporting documents including our Turbine Waiver Program and our Large Model aircraft Program. Recently a member of the UAPO office has been regularly attending these calls.

We're fighting a tough battle between keeping our members informed and not painting an overly tenuous picture of the future of model aviation. Not knowing exactly what will be in the proposed rule makes this a difficult challenge. And we're still working through some issues today that may be satisfactorily resolved before the NPRM is released. At the same time we need to make sure our members are aware, engaged, and prepared to react, if necessary, when the time is right.

The FAA has been invited to the AMA Expo in January. They have accepted. Our intent is to hold a roundtable Q&A session to help clarify a number of issues. This roundtable will be open to those in attendance and will also be taped and posted online. The Expo will also signal the beginning of an increased awareness campaign to keep the model aviation community as informed as possible as we move into 2011 and the eventual release of the NPRM.

– Dave Mathewson AMA President

I have noticed that many people aren't aware of the full ARC/FAA document released in April 2009. It is 74 pages long, as opposed to the handful of pages on the AMA website that many seem to be using. Lots of info on what may be coming our way, esp. when I doubt that recreational users wil have less limitations imposed than commercial operators (IE: 400 ft ceiling and 1500' lateral distance)

Get it HERE..

Jason Short, who seems to be able to write Flash faster than most people can write English, created a cool interactive Flash demo to explain Crosstrack Error Correction in the APM manual. Check it out here (works in Firefox and IE, but not in Chrome)

New York City First Person View Video

A recent video posted to YouTube depicts a First Person View (FPV) video flight of an unmanned aircraft over New York Bay; Long Island; the Brooklyn and Manhattan Bridges; Liberty Island and the Statue of Liberty; over and in close proximity to buildings, occupied vehicles and water vessels; and directly over unprotected people. The nature of the flight was outside the realm of recreational aeromodeling activity as defined by the AMA Safety Code and posed a significant threat to people and property.

Although AMA recognizes the ingenuity and creativity of this activity, it does not condone the manner in which this flight was conducted and the threat it posed to the public.

AMA has provided specific guidelines for FPV activity for its members. These guidelines and related safety considerations can be found in the AMA Safety Code and in AMA document #550, “First Person View (FPV) Operations.”

– Rich Hanson, AMA Government Relations and Regulatory Affairs Representative

First Person View (FPV) Operations

1. An FPV-equipped model must be flown by two AMA members utilizing a buddy-box system. The pilot in command must be on the primary transmitter, maintain visual contact, and be prepared to assume control in the event of a problem.
2. The operational range of the model is limited to the pilot in command’s visual line of sight as defined in the Official AMA National Model Aircraft Safety Code (see Radio Control, item 9).
3. The flight path of model operations shall be limited to the designated flying site and approved overfly area.
4. The model weight and speed shall be limited to a maximum of 10 pounds and 60 miles per hour.