Hi all,I was wandering around and guess what I found, an M.Sc. Thesis by Philip S. Anderson about the development of a UAV ground control station.I haven't read it yet but it seens to be a really nice reference. He uses LabVIEW which by what I have seen is a very popular software among us(uhhh but I still a newbie).What I think is a nice point of his project is that he actually built the system and put it on a van, so we can have a taste of what the military guys have :DJust for the sake of knowledge, I'm attachig his work(am I infringing any law, copyright or anything like this?).Ground Control Station.pdfRead more…3D Robotics
We've been describing ArduPilot as a navigation-only autopilot and saying that it needs the FMA Co-Pilot to provide stabilization. But that's actually not true--we just hadn't written the stabilization code yet. ArduPilot is powerful enough to handle both functions, something that Jordi proved this week with his ArduPilot-powered FunJet.
The above picture shows all the elements (click for a larger version): A FMA X-Y sensor is connected to two of ArduPilot's analog inputs. The four wires in the FMA sensor cable are, in order, roll, pitch, 5v, gnd. Connect roll to ArduPilot's analog 0 port and pitch to analog 1.
This is an example of how flexible the basic ArduPilot hardware is. It's the exact same board, but with different code and sensors added on the analog ports. We're going to add an airspeed sensor, too, and other goodies over time. You can do a lot with this little board!
Here is the alpha code, which is just so you can see the basics of how he did it. It's got the GPS stuff stripped out, but Jordi also has a working version with a 5Hz UBlox GPS.
For the public beta, we'll use a 3-channel EasyStar, rather than the FunJet, and the standard 1Hz EM406 GPS. The FunJet is, well, fun, but hard to fly (Jordi crashed it three times this week alone!) and not for everyone, and we want to stick with the simplest, easiest to use equipment for our main releases. Stay tuned.
Read more…3D Robotics
Big win for Dean! Purdue has been getting great press for its AttoPilot-powered UAV. Excerpt from Network World: (Slashdot coverage here:
"Researchers at Purdue will soon experiment with an unmanned aircraft that pretty much flies itself with little human intervention.
The aircraft will use a combination of global-positioning system technology and a guidance system called AttoPilot that uses GPS signals and an on-board flight-stabilization system to guide the aerial vehicle to predetermined points. Researchers can be stationed off-site to monitor the aircraft and control its movements remotely. AttoPilot was installed in the aircraft early this year, and testing will begin in the spring, researchers said.
According to Purdue, researchers have been using a small, lightweight unmanned aircraft - essentially a model airplane equipped with electronics - to collect agricultural data for Calmar Labs in Remington, Ind. The vehicle is equipped with infrared and digital cameras to take photos to assess the effects of shadowing on corn growth or to monitor the effects of drought or floods on crops. Until now, the aircraft has been controlled by a conventional radio receiver, which required human intervention to begin and end the missions, Purdue stated."
Read more…
Default baudrate of EM406a GPS device is 4800 baud. Then this baud rate dictates entire communication of serial port on ArduPilot - also those for Serial OUT (telemetry).Here's simple way how to permanently increase baud rate of EM 406. Once done, the device will remember the baudrate, and you can increase serial speed in ArduPilot code.1) Temporarily connect your GPS directly to FTDI cable:
Pin connection:FDTI GPSblack <-> 5 (from right)red <-> 1orange <-> 3yellow <-> 4Note: I used original half-cut cable + connector left by this cable modification. No soldering, just careful wire plugging into FTDI connector.2) Connect FTDI cable, and check if GPS works in RealTerm using default baudrate 4800:
3) Switch to Send tab in RealTerm:
and1) type command $PSRF100,1,19200,8,1,0*38 in marked field2) check +CR +LF line-ending3) click "Send ASCIIThis will configure your GPS device for 19200 baud rate.I didn't test with higher baud rates, but if you change it, you'll need to recalculate command checksum (*38 at end), otherwise GPS won't accept the command.4) Now GPS start to send at 19200 baud, so you'll see some garbage in RealTerm. Go to Port tab, close link (untick Open button), change baudrate to 19200, and Open link again. If you see valid GPS data, then all is OK:
5) In ArduPilot code, search for line Serial.begin(4800);and change it to Serial.begin(19200);Done! You have now faster serial communication in your ArduPilot code. GPS device will remember the baud speed as it has internal battery and memory and keeps the setting.You're now prepared for more data to be sent by telemetry link.
Read more…3D Robotics
Posted by Ross Mansell on January 28, 2009 at 1:13am
Posts are much easier to read if the poster uses capital letters where required AND correct punctuation!! Text type posts are not much use either, as a number of people do not bother to use a telephone for texts
Read more…T3
The UAV development board is back in stock at SparkFun.SparkFun also plans to eventually carry 12" cables for the GPS connection, which could be used for the UAV development board, as well as for Chris Anderson's ArduPilot. Sparkfun also plans to eventually carry 12" servo cables for connecting from the board to the RC receiver.Presently, there is C code available for getting you started with the UAV development board. There are two separate programs. One is for simply making sure that the board is working, used at SparkFun to test the boards before they ship. This one is available both at SparkFun and on this website, and is the program that is in the board when it is shipped. There is also a program that I call "GentleNav", available on this website only. It is a port of the program that I have been using for a couple of years on my previous hardware platform. It performs pitch stabilization and/or RTL for an electric sailplane.By the way, there is a "feature" of most GPS radios that you should be aware of if you plan to use both programs. If you command GPS radios to switch baud rate or between NMEA and binary formats, they only listen at the new baud rate and in the new format. If you run the "GentleNAV" program, it will switch to binary format with an NMEA command. If you then run the self test program, which trys to communicate in NMEA format, the GPS radio will ignore all commands, and the self test will indicate a failed GPS. If you plan to switch back and forth, you should revise the self test program to have it send the GPS command in binary format to switch to NMEA. With older GPS radios that I have used, they eventually default back to NMEA. The EM-406 somehow seems to forever remember the commands to switch, it will never switch back. I eventually plan to revise the self test program. In the meanwhile, it might be a good starting point for you to revise the self test program to send a binary command to the GPS to switch to NMEA format, its not hard to do.You should also be aware that the status light on the EM-406 only works when the radio is in NMEA mode. At least I haven't figured out how to make it light in the binary mode, it just goes out. It resumes operation when you switch back to NMEA.Presently, I am working on two projects related to the UAV development board. First, I am finishing up the documentation for the "GentleNav" firmware. Its taking longer than I thought. I will post a blog when it is done.Second, I am working with Paul Bizard to develop theory and implementation for "artificial horizon" firmware for the UAV development board. It will combine gyro, accelerometer, and GPS information into a stable, responsive, accurate representation in matrix format of the orientation of the plane that it is mounted in. We believe we have a method that will work, but we have a few more details to work out. We will publish the theory when we have something we are satisfied with, and tested code some time later. What we have in mind is an algorithm that will maintain the 3X3 direction cosine matrix that describes the relative orientation of the plane and ground. Each entry in the matrix is the cosine of the angle between an axis on the plane and an axis on the ground.Best regards to everyone, and acknowledgements to Chris Anderson, Paul Bizard, and all the staff at SparkFun for their help.Bill Premerlani
Read more…3D Robotics
Posted by Jordi Muñoz on January 27, 2009 at 1:00pm
This is a quick video tutorial to explain how to re-flash the attiny45 in ardupilot boards. You can also tweak the attiny code if you wish...But first you need to fallow this steps:1.-Buy an AVRISP MKII programmer, you can buy one in DIGIKEY, MOUSER and FARNELL (for Europeans)2.-Download and install AVR Studio from here, if the link don't work try this one (you must register). When your are installing it, when it ask about "Jungo Drivers", say always "Yes, yes and yes!" (are AVRISP drivers).3.-Now AVR studio will only let you program ATMEGAS in assembler (yeah, sure). For C/C++ you must install the WINAVR (AVR GCC). It will automatically fuse with AVR Studio, so don't worry about anything else... The main page is here, and the direct download here. After download, install it please.4.-Now plug you AVRISP programmer and make sure the drivers are well installed, if you want to know more about AVR studio and AVRISP please read here (very suggested).5.-Download the Fail Safe firmware (or code), to download the one i'm using in the video click here. Lasted updates will be published here. You can also download the HEX directly here, if you want... ;-)6.-Watch my quick-made video:
Read more…
nothing new since last post, but here's a video:it might look stressful but keeping it this way was really easy, easier than my rc helicopter.
Read more…
The Sparkfun guys and we diagnosed the issue today. It was our fault--we had a version control problem with the Attiny code we sent them, and the bad news is that appears to have affected a total of 60-80 boards. For those of you affected, our apologies--we'll make this right. Here are your options:
1) The fastest way, if you have an AVR programmer, is just to reflash the chip with the updated code (hex file is here; full source code is here). Instructions are here. If you don't have an AVR programmer, but have always wanted one, this is your chance! The AVRISP2 is excellent, comes with the terrific AVR Studio software, and is cheap ($34)
2) If you don't have an AVR programmer, the solution is to return the boards to Sparkfun and they will reflash or replace them at no charge, testing to ensure that you have a working board. Just send an email to techsupport@sparkfun.com, who have been alerted and will help you with the process.
All board shipped from today on will have the correct firmware, so this should be the end of the problem. Again, our apologies for the inconvenience and confusion. Our aim is to ensure that everyone has a working board as soon as possible, and Sparkfun has been great about responding quickly and making sure this doesn't happen again. Thanks for your support and understanding.
[Update. If you have this problem and live in the LA area, Jordi has volunteered to come to your house and reflash the board himself, no charge. Just PM him. For those in the Bay Area, I'll do the same, although depending on where you live, we might have to meet at some mutually convenient location. For those in Europe, we might be able to match you with someone who lives near you and has an AVR programmer. Please post in the comments if you need that.]
Read more…
a little info i couldnt find anywhere else. while programming my quadrocopter, i somehow messed up the throttle start and end-points of one of the esc's. the motor started only when the throttle was already in the middle. after some googling and experimenting, i found out how to reprogramm the endpoints. this will probably work with other esc's too.here's the exact procedure:- connect esc to receiver and motor, do NOT connect battery- on the (turned on) remote move to full throttle- now connect the battery- the esc will beep twice (two short beeps)- right after that, move the throttle back to idle/off/stop- the esc will now do the normal beeps (in my case 3 beeps for 3s lipo)- it can probably be used now, but i would "reboot" (disconnect battery and connect again) just to make sure it worked.this procedure fixed it. i then did this to all 4 esc's, and for the first time, all the props started moving and stopped at the same time. also got the best and most stable hover up until now.im surprisingly quickly getting to very stable results. all the axes are stabilised now. i removed the accelerator mixing for the moment (vibrations are problably making it useless right now) until i connect a display and see what's going on exactly. for short flights this isnt a problem. the quadro lifts off and stays very calm, no wobbling, no heavy vibrations (except motors of course), it's just slighty moving around, but i can control it with the remote. this probably can be stabilised with the accelerometer to.also did some hacking to the board, and connected another 4017 (to the unused output compare unit of timer 1) so i could drive the esc at 200hz, works perfectly!! love those esc's!here's the code of the PI-controller:int sens_nick = (gyro_y>>1)+(y_angle2>>10); //the current gyro data + integrated gyro data (shifting is precise enough at the moment :)int sens_roll = (gyro_x>>1)+(x_angle2>>10);int sens_yaw = (gyro_z>>1)+(z_angle2>>10);int inp_nick = -50+((serinp[1]-3750)>>3); //a little trim, plus the input from the ppm-decoder/remote-controlint inp_roll = -50+((serinp[0]-3750)>>3);int inp_yaw = -30+((serinp[3]-3750)>>3);//seradj is added to the throttle-input and passed to each esc.seradj[2] = (sens_nick-inp_nick) -inp_yaw-sens_yaw; //backseradj[3] = -(sens_nick-inp_nick) -inp_yaw-sens_yaw; //frontseradj[0] = (sens_roll-inp_roll) + inp_yaw+sens_yaw; //rightseradj[1] = -(sens_roll-inp_roll) + inp_yaw+sens_yaw; //left
Read more…3D Robotics
This is the first post in what I hope will be a mini-series on doing hardware-in-the-loop simulations with ArduPilot. A simulation is something you do to test your autopilot on the ground, where you won't get in trouble. It's an absolutely necessary thing when you're writing your own code or fiddling with ours and constructing a simulator is part of basic autopilot development.
It's called "hardware-in-the-loop" because you're using your real autopilot hardware, but feeding it simulated sensor or GPS data to make it think that it's in the air and moving around. Then you watch its reactions and see if it's doing what it's supposed to.
Eventually this series will take you to a full closed-loop simulation, where the simulator talks to the autopilot and the autopilot talks back to the simulator, totally replicating the interaction between plane and space. But for now, we'll start with the basics: simulated GPS in and telemetry out.
To do this, you'll need a computer with two USB ports (or two computers, as I've shown above) and two FTDI cables (or other USB-to-serial converters). Although it's not totally necessary, you'll also probably want a breadboard to do all the wiring on.
[UPDATE: See the comments below. You can download a utility that will turn one physical port into multiple virtual ports. That way you can use a single FTDI cable, and plug it straight into ArduPilot as usual. If you're using this method, ignore all the stuff below about the breadboard and wiring.]
You'll be running two programs on the computer(s): a GPS simulator and a terminal to see incoming serial data. I like the FlyWithCE GPS simulator and for a terminal, I use Realterm.
Plug in your FTDI cables one at a time. If you go into your Device Manager (Control Panel/System) after you plug each one in, you'll see which ports they're assigned to. Now set up the GPS simulation software and the terminal so each is using a different one of those ports, and set the baud rate to 4800 for each.
Now we're going to connect them to ArduPilot. Set up a breadboard with header pins and plug your two FTDI cables in on each side, with one 3-pin header off to one side on its own row. Use jumper wires to connect the 3-pin header to the following ArduPilot pins on its FTDI port: GND, TXO and RXI.
Depending on which FTDI cable you're using you can figure out which pins are which this way:
--If you're using the Adafruit cable, the black wire is ground, the yellow wire is TXO and the orange wire is RXI.
--If you're using the Sparkfun breakout board, the pins are labeled.
Now wire up the breadboard as follows:
The "GPS" cable (the one that's associated with the GPS simulator) should have its RXI pin connected to ArduPilot's RXI pin. The "telemetry" cable (the one that's associated with the terminal program) should have its TXO pin connected to the ArduPilot's TXO pin. All the grounds should be connected together.
It looks like this when you're done:
Needless to say, you should disconnect ArduPilot's GPS module, but otherwise keep the autopilot in the plane wired up to the servos and Rx as usual. Power it on.
In your GPS simulator program, enter a starting location lat/lon (it doesn't matter which if you're just doing RTL, although you might want to keep it in your hemisphere!) and pick move or circle and some speed at which you want it to fake the aircraft's motion. In your terminal program, there's nothing to do as long as you've got the right port and speed selected.
Now press "Start" in the GPS sim. It will start spitting NMEA sentences down the FTDI cable, which ArduPilot will think are coming from its GPS module. Meanwhile ArduPilot will start sending data (wherever there's a Serial.println command in the code) out its TXO pin to the other FTDI cable, which should show up in the terminal program. The autopilot should also respond the way you would expect if this was real GPS data, including moving the rudder to steer back to its starting position when you toggle it on with your RC transmitter.
Of course it won't really steer home because A) it's on the ground and B) we haven't enabled a feedback loop yet. But you can at least test program logic and see what the autopilot is thinking as it gets moving GPS data.
In the next post, we'll use a flight simulator program instead of the GPS simulator utility, and we'll discover what a "human in the loop" simulation is!
Read more…3D Robotics
FMA just announced their new Co-Pilot. The main difference appears, along with smaller sensors and all-digital operations, is that it's now part of a wireless onboard communications system that will eventually include other components such as GPS and telemetry. It's controlled with a IR remote control with a LCD display that you hold. Much more expensive, too. Eventually, FMA will be offering a RTL autopilot as part of this package.
Here are the details.
AVAILABLE SPRING 2009
Complete Package with all Accessories Priced at under $250 USD
1. Stand-alone operation – computer module installs between existing receiver and servos.
2. Micro-size components – Utilizes SMT components and tiny infrared thermopiles reducing the profile of sensor modules by approximately 50% over previous CoPilot models.
3. All new, digital sensor technology – Digital conversion now takes place within the sensor units. Communication between the sensor modules and the CoPilot computer is accomplished on standard, 3 wire servo connectors. The potential for analog noise in any installation is virtually eliminated.
4. Unprecedented Accuracy – As with all previous CoPilot models, the system offers accuracy to 1 degree of the horizon by sensing the temperature variation between the earth and the sky. Just center the control sticks and CoPilot-II will right your model from any attitude in split seconds.
5. The optional Vertical Sensor module forces the system to roll out of inverted to prevent the potential for striking the ground upon low altitude recovery. When installed, the vertical sensor also allows for automatic and continual calibration.
6. Supports all types of radio systems including any spread spectrum radios.
7. Stabilizes up to 4 channels for compatibility with virtually any aircraft configuration including CCPM heli’s, differential or dual ailerons, flapperons
8. Supports high-resolution digital servos as well as analog servos
9. Works in most weather conditions with the exception of heavy rain or severe overcast making it the ideal and affordable solution for radio control enthusiasts. Automatic weather check can be read out on the LCD at any time.
10. Flight Stabilization with a “Natural Flight” Feel – The CoPilot-II now includes “stick priority” as a built-in option to provide a natural flying “feel” when using flight stabilization. Using stick priority, the CoPilot-II is now capable of automatically reducing flight stabilization sensitivity just by moving the stick further away from center. This results in a natural flying experience without sacrificing recovery time.
11. New 3D modes (currently under development) include automatic vertical hover, knife edge, and inverted flight.
12. On/Off remote control can be set up on any type of auxiliary transmitter switch or knob.
13. New “Flight Modes” access allow for setting up different stabilization characteristics on any type of auxiliary transmitter switch or knob. Now it is easy to switch between basic stabilization and 3D modes with the flip of a switch. Learn new aerobatic maneuvers with safety and confidence.
14. Simple to Setup and Operate – Includes streamlined “wireless” user interface for vastly improved and simplified system setup and monitoring. The wireless system which makes this possible is a new technology developed by FMA termed “IRNet”. CoPilot-II is therefore the first IRNet peripheral to be made available by FMA/Revolectrix, but IRNet applications will extend far beyond the CoPilot-II. This means that with the purchase of the Co Pilot II, you are already set up to use any future IRNet peripherals that become available. Items under consideration include GPS integration, on-board watt meter, tachometer, temperature sensor, digital servo matchbox, tools for selecting appropriate electric propulsion components and others.
15. IRNet offers a fresh approach to Controlling and monitoring On-Board Avionics – IRNet consists of a wireless, infrared, 4 button programmer containing a 2-line, 16 character LCD, and a wireless network router. IRNet range is dependent on weather conditions but ranges from 30 to 200 feet, line of sight. The router is mounted in the aircraft and is capable of supporting multiple IRNet compatible devices. Each device on the “network” communicates with the IRNet programmer using a unique address much like the network of computers in your office, but on a smaller scale. Connected IRNet peripherals are represented as separate devices in the programmer, each supporting its own unique menu system. Setting up an IRNet device is as simple as scanning for the device’s welcome screen and answering a series of questions, much like using a television remote. Monitoring system information in real time is as easy as scrolling through the available data screens. Imagine being able to pre-flight check every critical piece of electronics in your aircraft prior to takeoff, and all without having to bend down and remove a wing or even plug in a wire.
Read more…
a few weeks ago i decided to build a quadrocopter. this would be a real challange but still inside the capabilities of the pcb i made. i actually designed it with plane-uavs in mind. but there's no reason it wont be able to controll a quadrotor.here's the finished board connected to a display. the display i a cheapo 128x64 graphics lcd controlled by another atmega168 and connected with spi. i removed the yaw-gyro from the board to get to the spi bus (also needed for programming the main atmega)... always include a isp-port on every board involving an atmega!that was mainly build to port the arduino code (using crystalfontz serial lcd) to winavr/gcc (using my spi-display). i already had everything working on the arduino and could do some testing with gyro integration and sensor fusion with the accelerotmeter.this is the frame. i used 10x8 cf-tubes and glued aluminium-profiles for mounting the motors and attaching them to the central gf-plate. the motors are TP 2410-09, supersimple 30A ESC and EPP1245 props.here's the test-stand. these motors+props are very powerful, so there are 3 bottles of coke in the basket, so it doesnt lift off. getting it to stabilise was surprisingly simple, here's the code. this code is run whenever there's new data from accelerometer, that's 640 times per second. gyro-data is also read then//gyro_x is current gyro output//x_angle is current integrated gyro angle mixed (127/128 gyro, 1/128 accelerometer) with little accelerometer angle (fixed point 20.12)seradj[0]=(gyro_x>>1)+(x_angle>>10); //adjustment/stabilisation for x-axis, basicly a simple PI-controller//serinp[2] is the throttle channel, serout[0] is the ppm-output for the back rotorserout[0]=serinp[2]+seradj[0]; //the values are micro-seconds x2 for the ppm-outputserout[1]=2000; //left, currently offserout[2]=serinp[2]-seradj[0]; //frontserout[3]=2000; //right, currently offthat's stabilising it very nicely. would probably be good enough for flying. the angle it stabilises to isn't exactly 0, probably the accelerator isnt perfectly parallel w.r.t. the frame. ppm is only output for the 4 esc's, one after the other as fast as possible, thats 250hz update rate at idle and 125hz at full power. works great so far.TODO:- better mounting for the pcb, receiver and battery- connect serial display for debugging- stabilise roll and yaw- tons of currently unknown problems- fly :)
Read more…
Okay, I just bought my freeduino and a ADXL330(Wiimote 3-Axis Accelerometer module). I bought everything at seedstudio which cost me USD $45, a bargain, since here in Brazil just the freeduino would cost me slight less than the double.When these two little babies arrive I will start myself in arduino programming and DIY stuff, since I started my computer science course I felt in love with this kind of stuff. I started reading in a daily basis things about PICs, eletronics, automations, DIY, you name it. But I think I have read enough, I need to go to the next level the one which we do something :DFreeduino - way too expensive in Brazil.(USD $40)
Posted by kitemaker Ken on January 23, 2009 at 1:07am
An old friend developed a nice Rogallo winged RC plane which he calls the Hawkeye. If interested, you can read about it at his site- http://electricflights.com/hawkeyemainpage.htmlI test flew the Hawkeye last summer into the fall, until the rains returned to the northwest. It is very portable, easy to fly and designed to carry a camera. Shot lots of video and then realized that I want an autopilot to increase my odds of getting the shots I'm after. I'm game to try an ArduPilot, as its design and open platform appeals to me.
The Hawkeye flies fine with its rudder and throttle controls, being quite stable and impossible, in all my experience, to invert. So, can I assume that I won't need to use a FMA IR stabilizer? Wouldn't know what to control with the FMA Co-Pilot, as there's no elevator or ailerons on this bird. Has anyone successfully flown anything with the ArduPilot and no FMA Co-pilot? Will the current ArduPilot firmware work as designed without a FMA Co-pilot on board, or will I need to rewrite some of the code?All questions, comments, advice or fore warnings will be read, appreciated, and answered, thanks!
Read more…
Posted by BRANDYHans on January 22, 2009 at 11:37pm
I dream about building an UAV Predator Desk (cockpit). Does someone already has experience about ?Friendly Regards. BRANDYHans - www.HansaMarine.orgRead more…
Posted by SLUGS Team on January 22, 2009 at 4:13pm
The Santa Cruz Low-cost UAV GNC System (SLUGS) is a high-end UAV Autopilot that is currently under development by the Autonomous Systems Lab at the University of California Santa Cruz. Although not ready for prime time, the project's website shows some significant progress towards a fully functional platform.The SLUGS autopilot is heavily geared towards research in small to medium sized UAVs. Great care has been taken to assure that it has enough processing power for moderately complicated control tasks and at the same time is easily reprogramable via Simulink. This effectively allows to rapidly iterate from simulation to implementation with no intermediate coding.The developed architecture physically decouples sensor integration and INS filtering from the control algorithm and communications by using two 33Fj256MC710 dsPIC Digital Signal Controllers (DSC) interconnected via a high-speed Serial Peripheral Interface (SPI) bus. The SLUGS autopilot has been designed to be modular and extendable in order to extend the sensor and peripheral suite as the need arises via CAN bus daughterboards.The Ground Station Software has been developed to decode the incoming telemetry messages from the SLUGS AP. It also works as a Hardware-In-the-Loop interface to Simulink and is the central point to configure the Autopilot.One of the main features of the SLUGS AP is its ability to interact with virtually any Simulink model via a Hardware-in-the-Loop Simulator. There is a predefined protocol to send simulated sensor readings to the AP, as well as a protocol to receive control commands back. But aside from that, one can make the HIL simulator as simple or as complex as one needs. Currently we have a six-degree-of-freedom model of our UAV, and an engine model. Some work is underway to include an atmospheric and weather model.We are currently working very hard to write some sort of documentation and getting all the code ready for public release under the MIT Open Source license and under GIT version control system. We expect this to be ready around April this year.
Read more…
