T3--Round 6: The Simulation Round!
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.
-
Comment by Recmaster on April 1, 2010 at 1:20am -
Hello all,
is it not a comlete solution for closed loop test?
http://diydrones.com/profiles/blogs/ardupilot-successful-flight
May be it will be good think to rate all solutions existing at this site at one place, finished the best and
just use it ??
-
Comment by brakar on April 1, 2010 at 1:33am -
For the record, I will not claim a gift certificat for being early. Just wanted to make the post before going up in the mountains.
-
3D Robotics Comment by Chris Anderson on April 1, 2010 at 7:14am -
@Recmaster. That's an open loop simulation. There is no back channel from the autopilot servo output back to the simulator.
-
Comment by Alexander Malikov on April 2, 2010 at 1:51am -
Hi all!
This is my first post here.
I'm not a DIY guy, just could not refrain from participation in the contest. :)
I use FlightGear 1.9.1 with custom model of our real drone (~5 m wingspan, ~90 kg weight). Visual model is ported from SolidWorks, flight model is YaSim based. Autopilot is stm32f103 based with external IMU/airdata. For simulation I use special autopilot software build that uses one of serial ports for connection to PC. Also I've got port of autopilot code to run on my desktop.
I use UDP to get attitude/position/etc data from FlightGear and put servo output to FlightGear. Simple application called "fgwrapper" receives UDP packets from FG, converts text data to binary format and sends it via serial port to autopilot. Then fgwrapper receives response from autopilot, converts binary data to text and sends it via UDP to FG. Also fgwrapper do useful synchronization job, because FG1.9.1 reads UDP packets by specified time intervals (not by reception of UDP packets). This can lead to significant delay in control.
Here is the result:
video
diy_track.kml
ps: sorry for my english :)
-
Developer Comment by Pete Hollands on April 2, 2010 at 2:11am -
Alexandr, that is cool. A nice setup, and a lovely video. Thanks for the post.
Can you tell us more about the autopilot. I've found a development board with the same micro-controller.
But what software are you using ? Is it open source, ?
-
Comment by Alexander Malikov on April 2, 2010 at 2:36am
-
It is not an open source project. On autopilot board there are 5 serial ports (for sensors, modem and servos), FRAM (config etc), SD card slot (log). Used software: FreeRTOS, Chan FatFS (for SD).
FG really helps much in debuging/tuning!
-
Comment by Brian Wolfe on April 5, 2010 at 10:58am -
Alexandr,
Nice setup. I'm doing something similar but am fighting the latency issue. I'm having to lower my gains by a factor of 5 to get a stable but very slugish sim running. It's taking more time to tune the loop for Flightgear than it did for the real system. Doesn't make for a usefull simulation when you have to switch gains other than to visualize the path and confirm it's roughly what you want.
Can you describe your synchronization job that FGWrapper is doing? I've told FG to sample the input at a higher rate than I'm sending which helped some, but still having issues. Are you able to run the same gain in your aircraft that you do in the sim or are you backing off when running the simulation?
Curt and others, any input you may have is greatly appreciated. I'm wondering if I can get the performance back up by some trickery such as running the sim at 5x or something. More experimenting tonight.
Thanks,
Brian
-
Comment by Alexander Malikov on April 7, 2010 at 2:54am
-
Brian,
I fought with latency in the begining of FG use. And I found that rising FG input frequency doesn't solve the problem completely. So I decided to add a variable to FG property tree and use it as a packet number.
FGWrapper does the following:
1. Gets a packet from FG with values of attitude, position, etc and "FG_packet_number"
2. Converts and sends values to the autopilot
3. Reads and converts response from autopilot
4. Checks the difference between "FG_packet_number" from step 1 and "internal_packet_number". If this difference is more than threshold (I use "3" as value) then skip step 5 (synchronization case)
5. Increases "internal_packet_number" and sends it back to FG with other values (normal case)
In other words FGWrapper periodicaly stops sending packets to prevent FG queue flooding.
I use the same gain in the simulation and real life.
-
Comment by Brian Wolfe on April 7, 2010 at 8:17am
-
Alexandr,
Thanks very much. I'll give that a try. Sort of a modified poll and response setup instead of just asynchronously sending packets to FG.
I'll post what I find.
B
-
Comment by Brian Wolfe on April 17, 2010 at 5:25pm
-
I had to chance to try Alexander's synchronization idea with FG but have discovered that FG hangs if I don't send it packets. Rather than using the last values sent to it, FG stops and waits for new values to be sent to it. That makes it difficult to implement a poll and response scheme if both ends are waiting for the other to send a packet. I'm thinking some bugs have crept in to build 2 of FG so I'm going to back up to 1.9 and see how things go. It's my understanding that some of the variables have changed name/location though so I'll need to chase them down.
I've looked a bit at X Planes as well, but I guess body accelerations are hard to get from the sim via UDP (rates are no problem). I need accels for closed loop HWITL if I want to use my internal attitude estimator. A final "punt" approach will be to generate estimated rates and accels internally myself and just feed the attitude to FG so it can display my position and attitude - an approach some of the other sim setups seem to be doing, but I'd really like to take advantage of the heavy duty modeling in FG or XPlanes.
The quest continues.....
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Documentation Editors
51 members
-
ArduRover User Group
185 members
-
ArduPlane User Group
686 members
-
ArduCopter Italian Group
87 members
-
Moderators
24 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
You need to be a member of DIY Drones to add comments!
Join DIY Drones