Blogs

Hi All,

I made a little video clip of the Groundstation yesterday!



Let me interduce the FY-3ZT autopilot for small UAV.

Yes! it's made in China.
Yes! it will be low cost. Price level (not set yet)
No! I didn't test it yet. Working on it.

The company who made it call it FY-3ZT! Lets call it jealouspilot. Just a joke.

The Data modem I got with the test sample is the small 2,4 Ghz. (Also provide a long range 433 Mhz 500 mW like the one on the picture.

The 2,4 Ghz

This is the Autopilot system: It's like "PnP" Everything fits and ready for installation.

This is for Ground station Plug into PC via USB. Also more or les "PnP". (I know this is not the best antenna bla bla) This was what was in the box)

The driver for USB to Serie was on Chinese!.

And now for the Commodore 64 look a like GSC.

You are able to fine tune the settings in Air.

FY3-ZT provide high-precision attitude through to use 32 ARM7microprocessors, integrate
GPS receiver, three-axis MEMS gyro, three-axis accelerometers, pressure altimeter, inertial
strapdown attitude algorithm and combined with Kalman digital filtering and data fusion
algorithms .

Integrated UBLOX 5th generation GPS receiver, 4Hz output, 35 seconds fast positioning time
and accuracy of 2.5 meters CEP.

50HZ inner attitude control, 4HZ outer navigation control.

Multi-channel mixed-control output can be easily adjusting the mixed-control. Including
normal layout none mixed rudder control navigation, elevator and aileron rudder navigation,
elevator and aileron mixed-control navigation, none ailerons rudder navigation. And can
adjust the neutral position in real-time.

Three kinds of control modes: Manual remote control, Auto balance remote control and
Automatic navigation control.

Two kinds of automatic navigation control modes: Air route navigation mode and Mouse
pointing flight mode.

Integrate automatic and manual remote control, higher reliability and practicality, and is
compatible with all common RC remote control facilities, and to provide Servo output
checking.

Auto-return protection of communication interruption.

Distance Automatic photography.

The ground station software contains electronic map that can change the route and tasks online,
real-time semi-autonomous remote control, and can real-time record flight data and play back
off-line.

Adjust and save all the control parameters on line, with the convenience standalone parameter
adjustment software.

Contains the autopilot power supply voltage monitoring, electric aircraft power voltage
monitoring, GPS accuracy of detection and autopilot temperature detection.
Technical parameter.

This is what I have! Feel free to ask and comment!.

Latest documentation

FY-Autopilot.pdf

HOOKS.

I'm sure alot of us have been waiting with anticipation for this one.Let's get some samples and/or eval board and test its performance to determine applications that it may be suitable for.

Digital-output X-, Y-, and Z-Axis angular rate sensors (gyros) on one integrated circuit with a sensitivity of 14.375 LSBs per °/sec and a full-scale range of ±2000°/sec

Three integrated 16-bit ADCs provide simultaneous sampling of gyros while requiring no external multiplexer

Enhanced bias and sensitivity temperature stability reduces the need for user calibration

Low frequency noise lower than previous generation devices, simplifying application development and making for more-responsive motion processing

Digitally-programmable low-pass filter .. and more....

http://invensense.com/mems/catalog.html

http://www.flightglobal.com/articles/2010/04/01/340168/pictures-farnborough-beckons-for-italian-uav-display-team.html

While the Boeing 787 and747-8 appear set to be the commercial showpiece of July’s Farnborough Air Show, military eyes are likely to be drawn to the Italian unmanned formation display team intending to debut at this year’s event.

Farnborough 2010 organisers have yet to give final authorisation for the Foggia-based ‘Squadriglia Tranquilla’ (‘Quiet Squadron’) to participate, but Flightglobalunderstands that approval is likely to be granted this month.

The nine Alenia Aeronautica Sky-X UAVs have been heavily modified, mainly to reduce fuel and maintenance costs. All of the expensive surveillance equipment used during military operations has been removed, leaving relatively simple pre-programmed on-board guidance. Each Sky-X has also been fitted with a smoke canister.

I will be at Farnborough so will enjoy watching that from the beer tent.

For the last T3 round before the weather improves (in the Northern Hemisphere), we're going to do something indoors! It's a simulation round, which I previewed here.

I'll repeat the basics:

There are two kinds of simulations: "open loop" and "closed loop".

Open loop means that you connect the output of the simulator to the input of the autopilot. The simulation drives the autopilot with synthetic GPS coordinates and sometimes synthetic attitude data, essentially replacing the autopilot's sensors. This basically fools the autopilot into thinking that it is flying, and you can watch how it responds. This is typically done by having the simulator output data via the serial port and feed that into the autopilot.

Closed loop means that you also connect the output of the autopilot to the input of the simulator, so that the autopilot is "flying" the aircraft on screen. This usually requires a relatively complicated bit of hardware that converts the PWM servo output of the autopilot into what amount to joystick commands via USB or serial that steer the plane in the simulator. It can also be done entirely in software on the host PC, as in the case of Matlab simulations being driven by a flight simulator.

Here are some blog posts that show examples:

--Curt Olson's FlightGear demo

--Faisal Shah closes the loop, Part 1

--Faisal Shah closes the loop, Part 2

Here's the contest structure:

Two sets of winners:

Both must write "DIY" (in cursive) over a place of their choosing. Example above from brakar, who, like Jesse & Jared, have jumped the gun a bit and already submitted successful entries for this round.

--Group One: Open loop (video showing you mirroring the airplanes control surfaces with the arrow keys): First six to complete this win a $25 gift certificate to the DIY Drones store.

--Group Two: Closed loop (aircraft controls the flight simulator): First three to complete this win a $50 gift certificate.

A special top prize will go to the person who best documents how they went about it and creates a useful tutorial for others to use afterward (judge: Gary Mortimer). The prize for that will be the notorious Raven UAV clone (unless the winner requests something else, in which case I may grant mercy and come up with something of equal or greater value).

Also, as suggested by Brian Wolfe, anyone who completes either of these rounds will get points added to their grand total: One point for open loop and four points for closed loop. Here are the current cumulative rankings after five T3 rounds:

Brian Wolfe 31
Vassilis 24
Brakar 23
Mark Griffin 18
Krzysztof Bosak 17
Andrus Kangro 12
Jesse Jared 8
IOS 6
Bill Premerlani 6
MarcS 6
Joe 6
Steve Joyce 5
Steve Westerfield 3
Chris Anderson 3
Icebear 1

Entries must include a video and KML track and a description of your simulation setup (flight sim, autopilot, other hardware). Submit your entry in the comments below by 12:00 midnight PST on Sunday, May 2nd.

https://www.youtube.com/watch?v=cipTQAUM-v4

Note** these are 100meter orbits with really strong winds to provide a setting for this test. Hence the reason why the autopilot has a hard time holding a perfect circle. However the improved algorithm is holding so much better in the high wind scenario than the original algorithm!

This is an example of how to eliminate the oscillation in ground track using a heading error>bank angle type proportional controller. The groundspeed of the vehicle determines its turn rate for a given bank angle. Typically you tune the PID (only P is needed) for a given trim airspeed and assume that the ground speed is fairly constant and something close to the airspeed. However when there is high winds, this isn't the case. The ground speed can change +-50% in some cases in and out of phase with the wind if not more.

This causes oscillations on the "upwind" side because the turn rate is so much higher. To take this nonlinearity out of the system, I added the turn rate equation into the mix and solved this problem. The largest contributor to this problem is the GPS lag. So using this turn rate equation in the middle, it makes the controller more predictable with the changing ground speed.

I made an attempt at a video so hopefully it will better explain what is going on here. Especially beings a lot of people are having this problem!

-Beall

I think I've debugged one of the issues I was having with my OpenLog connecting to Ardupilot. This will probably be blatantly obvious to you veteran Arduino Programmers, but it got me, so I figured I'd post in case it helps anyone else.

After a few flights with only the open log and the ArduIMU, I decided to integrate the ArduPilot board and move the logger to the Ardupilot board. My ArduIMU was now talking to the ArduPilot, and I hacked up the ArduPilot code to remove the autopilot/radio functionality and simply combine the ArduIMU input with barometric pressure, and spit out the aircraft parameters as fast as possible.

While stripping down the ArduPilot code for my purposes, I made a whole bunch of changes at once (Mistake #1).

Once everything was back together, I found that I was only getting a log created about half the time. Sometimes there would mysteriously be no log file created. Other times, I would have a small file filled with a bunch of null characters. While debugging I would connect the OpenLog to my FTDI cable and find that it was now operating at 9600baud rather than the desired 57600baud.

The reset to 9600 was the clue. The OpenLog has an emergency reset function. If you get the OpenLogger stuck in an unknown baud rate, you can power it up with the RX line grounded. When this is detected, the OpenLogger goes back to 9600baud on the next power cycle.

So here's my current theory.

One of the changes I made to the ArduPilot code was to add a delay at startup. The reason I added this delay was because of the instructions in the OpenLog datasheet. The OpenLog instructions state: "Turn on OpenLog, wait ~2 seconds and start throwing text at it!" So I added a delay(3000); statement to the void setup() function.

It took a few days of working backwards to figure out what was causing the OpenLog problems. Then I stumbled on this page in the Arduino Reference library:

http://www.arduino.cc/en/Tutorial/DigitalPins

Thats when I realized that I had placed the delay() function before the Serial.Begin() functions in setup().(Mistake #2) I think this meant that during the 3 second delay, the serial pins were in their default input/high impedance state, giving a somewhat random response from the serial logger at the other end.

I moved the delay() line to the end of the setup() function (after the all the initialization is done) and I did 10 powercycles in a row. Each one resulted in log being correctly written to the microSD card.

Tom

As we prepare to migrate our current LabVIEW groundstation from ArduPilot to supporting ArduPilot Mega, we're taking the opportunity to rethink its architecture and code base.

Right now it's written in LabVIEW, a visual programming environment that has the advantage of rapid development and easy-to-make instrument displays, as well as being cross-platform. But the problem with it is that the development tools aren't free (indeed, the ones that can create an executable file start at $1,249!), and distributing the files requires users to download a runtime engine and serial driver. As a result, we don't have as much community participation in the ground station as we do in most of our other projects.

Over the past year, we've been looking for an alternative with free and good development tools. It needs to be cross-platform, compatible with open source code standards, and appropriate for a ground station (ie, able to handle a rich visual environment and to talk directly with the serial port). Eventually a good candidate emerged in Nokia's Qt application and UI framework, and I'd like to present it here for community feedback.

You can see a glimpse of Qt above, but here's the description from the site:

"Qt is a cross-platform application and UI framework. Using Qt, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.

• Intuitive C++ class library
• Portability across desktop and embedded operating systems
• Integrated development tools with cross-platform IDE
• High runtime performance and small footprint on embedded"

Note that it's cross platform on more than just computers--it will also run on phones, too, which introduces the possibility of an ArduPilot GCS on Android or some other smartphone, which would be very cool. Also, we intend to integrate the current ArduPilot configuration utility into the GCS, so one desktop program can handle all the ArduPilot functions, from mission planning to real-time data display, including integrated Google Earth and video handling and image processing.

So what do you think? Is this a good code foundation for a full-featured groundstation? Does Qt look like something you'd adopt for the right project?

[UPDATE: See this Swiss team's MAV groundstation for an example of what Qt can do. Nice! It's open source, so we can build on it if we want.]

Arcus IMU with camera stabilization firmware test #10 from Riccardo Kuebler on Vimeo.

Check out Krzysztof's profile, http://diydrones.com/profile/KrzysztofBosak and his latest post: http://diydrones.com/profiles/blogs/what-can-be-flown-using-rudder

I've mention this project a couple times and finally, here it is.

What: This is an ardupilot board that has been modified as per the picture above. The modifications allow reading the position of 4 channels from your receiver and driving 4 output servos. The firmware has been altered to remove support for gps and instead use the one ATMega328 serial port to write out the receiver channel data and read in servo position commands from an external computer.

Why: I am working on a gumstix based autopilot. The gumstix runs all the "smarts" but I need a simple way to decode receiver channels and drive servos, and I need a manual override safety switch. The ardupilot provides both of these.

I'm no master solder expert, but I managed to avoid soldering my fingers to the board and everything works, so I'm happy.

I am attaching my firmware mods (based on the Ardupilot-2.2.3 firmware with lots of hacking and chopping.) My current incantation only does servos, but I tried to leave the door open to attaching other analog sensors which could then also be reported to the host computer ... this could include pressure sensors, voltage sensors, etc.

ArduPilot_SensorHead_v1.3.zip

I ran into problems using pulseIn() to read the receiver pulses (which made sense after I looked at what pulseIn() is actually doing) so I wrote my own routine that watches all 4 channels at once and times the pulse. I haven't convinced myself that I have the overall board timing locked down exactly the way I want it, but for now it seems to work pretty well. I can read 4 channels of data off my receiver (+ the selection channel state) and I can drive 4 servos from the host computer (tested with a simple sine wave function.)

On the subject of hardware in the loop testing, a board mod like the one described here could be used to read the servo outputs of a standard ardupilot, and feed them to a simulator to be translated into control surface commands there. Some additional software/communication work would be required, but it should be a reasonably straight forward project.