A new 10Hz GPS is available on SF and it looks a lot more sturdy than the Venus module... Does anyone has it?
http://www.sparkfun.com/commerce/product_info.php?products_id=9758
All Posts (14056)
Sort by
Excellent poster. How long until that car becomes a plane?
Last year Fritzing came along as a virtual Arduino sandbox, a way to simulate a breadboard and components and run Arduino code to test the circuit. Now VirtualBreadboard, which has been around for a decade, has expanded to simulate Arduino, too. I haven't tried it out, but it looks very handy for travel coding (which I've been doing too much of lately).
BTW, I hear that Fritzing lost their German government grant, so I'm not sure what effect that will have on the project's development. It is an awesome concept, improved by the ability to order a PCB of your design, so I hope they can find other funding sources soon.
(via Makezine)
There are a zillion quad- and tri-copters out there, from the priciest commercial ones to the funkyiest DIY rigs. This guy has done a tremendous job of trying to bring all the available info in one place: a RCG thread (scroll down past the poll results). If you're into quads, you'll want to check this out.
This article was brought to my attention. It might be of interest here. The gyro in the article is made by STMicroelectronics. There is another post (click HERE) about the first-ever 3-axis digital gyro made by InvenSense.
Click HERE to read article in IEEE Spectrum magazine.
Paul
Could this have been the end?
The platform with the fire brigade ship was something like OK.
The vizualization was something like OK.
For the data-collection we could have lived with that solution.
All members of the team have an engineering background (for sure not in ship building).
As an engineer you look always for better solutions (especially if you are a german one).
Grmbl...
Thinking...
Sleepless nights...
Pling!
What about catamaranes?
No bad idea!
Anyone around who knows somebody who knows someone who has ever built a cat? -nope-
So went the discussions in the weeks after the success with the fire-brigade ship.
The last days of summer went away and i was looking for new horizons.
First try with two 100mm PVC sewage-tubes, four PVC 45° fittings, a styrofoam board, meters of Gaffer-tape and countless sticks of hot-glue.
The windmill on top and here we go!
Not bad for the beginning, but looked not satisfying. No pictures left, maybe i can fake some to see, how it looked like.
Next try.
I have found a good material, while physically googling the diy-stores around my hometown: 2.5mm thick PVC hard foam boards.
They can easily be cut with sharp cutter-blades and glued with hot glue. This was the ideal material for somebody who wants to have the results of his ideas realized some miliseconds after the idea hit his brain -me-.
Building the two hulls of the cat in three hours looked quite attractive to me and it was feasible. The simplest form was a V-shaped hull with V-shaped endings.
The three hours turned to six and after that i had the two hulls manufactured. I took a 30mm styrofoam board to connect the two hulls and the platform was ready. The windmill still served as propulsion system.
This assembly will shurely not a candidate for the "Germany´s next ship model"-contest
Tadaa! The new Platform
The first course was a triangular one, starting from the the launch point, turning right in a 90° turn after 100m then 60m and then back to the launchpoint.
Looked good.
The first tries...
In the picture you can see the course of three runs, each one was started with a different launch-angle, to see, how stable the PID control loop works.
The proportional part of the PID was increased by a factor of 5 compared to the firebrigade-ship and the rudder-horn attachments were also altered to give an estimated factor of 2. So in total the proportional part was multiplied by 10! The straight-line behaviour was excellent, the cat went like it was on rails. The radius for the turn was about 10m, which is more than i had on the previous platform, but this is OK.
No oscillations!
I was happy. And it was already december.
On the morning of december the 24th we had our traditional meeting from our diving club on the lake where we drink some amount of hot wine and we have some cookies - nice event-. I wanted to test some new parameters this morning, but we had ice on the lake. Very early in this year... And the winter was long and hard, the ice lasted until mid march this year. A long time, if you are addicted to optimizing! Some years ago, a friend of mine sent me a postcard from a holiday, it was subtitled "The only ice in florida is in the drinks". I thought a lot about that in the past months.
On 25th of March i started the new season with a zigzag-course from north to south with longer legs than i did before.
The ZigZag
In this screenshot we see two trips: the green one was the first one
the blue one is the optimized one. The white is the mission planning path.
Lets have a closer look to the green one:
We can see, that there is a curve with a big radius, when heading from one point to another. Analyzis showed, that the Integrator part was the bad guy. In the past experiences we set the integrator limit to a very high level and the integrator factor (Ki) to a very low value compared to the Kp. Kp is 2.5, Ki is 0.03.
The problem came from the hard (nearly 180°) turns. While turning, the integrator adds up to very high values, because we have a big difference between the setpoint and the actual value. And with this "heritage" of integrator values, i takes a lot of time for the decay of the values.
The Integrator is needed for accuracy and i wanted to keep the ki low, to avoid oscillations.
The cure: When looking at the time, the ship needs to make a "full turn" we found about 20 seconds in every case. We already had a "integrator holdoff" function in the software that cures the NMEA parser startup bug. Increasing this time from 5s to 25s led to the blue track. (The integrator part is not needed for the turn, because it is overriden by the p-part)
This is close to being optimal. The direct straightline (a real zigzag course) is theoretical not possible because the turn itself has a fixed radius. The actual waypoint algorithm always calculates the course to the next waypoint from the actual position. If we take this into account, the result is OK. I measured the maximum lateral deviation from the straight line with about 3 meters (on a leg length of 300m).
Not bad for a pure GPS-based autopilot solution.
All for today, the weekly TV thriller starts in a few minutes and will not miss it.
Next episode will focus on the autopilot system.
Hey all, here is the new AttoPilot website which is almost complete.
Just want to get some feedback as to what everyone thinks.
In our discussion the other day about what programming language to use for our next generation of ArduPilot Ground Control Station (GCS), I mentioned the PixHawk GCS, which is written in Qt. I've been in touch with Lorenz Meier, the team leader, and he's been super helpful in explaining the project and sharing code (see below). We're considering basing the ArduPilot Mega GCS on this code, so this is an opportunity for the community here to check out the code and evaluate how appropriate it is for us.
PixHawk in a general-purpose Micro Air Vehicle (MAV) platform. The first version is a small coaxial helicopter that won first prize in the 2009 European Micro Air Vehicle Indoor Autonomy Competition. It's got an x86 computer onboard, running Linux. Since then, the project has expanded to include a quadcopter and a full open source robotics computer vision toolkit.
Here's a video showing the progress to the competition win:
Although there are lots of impressive aspects of the project that may be of use to us, we're now focusing on the groundstation. Here, from the project's website, is the project description:
"The groundstation is the only interface to an autonomous operating
robot. Even when not operating autonomously, e.g. during system tests,
just a joystick or the remote control is not enough as measurement
values have to be available in real-time and configuration settings have
to be changed.
Features
- Multi-MAV support
- Support for rotary and fixed-wing (Airplanes, helicopters, coaxial and quadrotor designs)
- Joystick control
- Voice/Audio output tested on Mac
Implementation
- Cross-platform: Windows, Linux, MacOs, Maemo
- Open Source (GPLv3+)
- C++, Qt 4.6 based
- Look and Feel completely customizable
Supported Hardware
- Any PC/Mac
- iPad
- Smartphones (iPhone, Nokia N900, currently untested)"
Here are some other views of the interface:
The source code (in zip and rar forms) is now hosted here.
There is a very complete API, with documentation here.
They're just cleaning up the code a bit, and once they do the latest versions will be hosted on github here.
I'm no programmer, but I've been very impressed by what I've seen so far. Rather than reinvent the wheel, I'm leaning towards recommending that our team start with PixHawk
There are loads of open source quadcopters out there, but they're all a bit too DIY for me--I just want something cheap that works right out of the box. I love the Parrot AR.Drone, which fits that bill, but it's not really a UAV, because you can't give it waypoints and it doesn't know where it is since it doesn't have GPS.
Adding GPS to the AR.Drone would be easy if you could get access to the datastream the AR.Drone is sending back via WiFi, and there is indeed a physical port that could allow that, but Parrot has not enabled that and they don't want to emphasize that possibility for fear that the AR.Drone might get regulated as a UAV, rather than a flying toy.
So rather than wait for them to turn that on, I decided to take matters into my own hands. As you can see above, I just added an ArduPilot, a GPS and an Xbee to the AR.Drone. They're powered by a tap off the balancing connector of the quad's battery, but otherwise they don't have any connection to the onboard electronics.
(Note: you don't really need ArduPilot for this--you could probably connect the GPS right to the Xbee--but I'm using it right now to parse the GPS data and just send down the essentials, along with providing a power regulator for the Xbee and GPS module. But going forward, having ArduPilot onboard will let us add other sensors and do more onboard processing.)
All this setup does is send back GPS coordinates to the ground station, with an Xbee at each end. But that's enough to turn the AR.Drone into a proper UAV, since Parrot has already released software that lets you control the AR.Drone from a PC. So all we need to do is modify that code to take the GPS telemetry in from the Xbee, compare that with given waypoints, and calculate a directional vector for the AR.Drone to fly to hit the next waypoint. Then that XYZ command can be sent back to the AR.Drone via WiFi using the Parrot data standard.
So in a sense, the AR.Drone handles the inner loop (stabilization) of an autopilot onboard, but the outer loop (navigation) we'll do from the ground station, along with image processing and other mission planning. Because the outer loop only needs to run at GPS speed (1Hz-4Hz), wireless latency isn't an issue.
Right now, the only official AR.Drone PC ground station is for Linux (here), which is a bit over my head. But now that the quads are getting out to developers, I'm sure someone will port that to Windows, at which point I can have a go at writing the software to read the incoming Xbee data from the serial port and turn it into flying commands to send back via WiFi.
Stay tuned....
From the numbers to the pictures.
We took all the NMEA data from 10ths (feeled thousands) of test-drives and concatenated them into one big file, we then converted to the UTM/depth representation as mentioned in the previous episode.
This file was finally fed into a MatLab script, that produced a 3D image, where the depths are represented as colors, ranging from red to blue. Red was 0m and blue the maximum depth of this (shallow) lake with about -11m. MatLab does an automatic adaption of the colors and the axes in this case. In the first run, the x and y data (resp. Easting and Northing of UTM) were also plotted in blue color. The derivated picture looked like that.
This is not very spectacular, because the whole picture is covered with blue lines.
The next one is without them:
This Picture shows the color-of-depth-representation only, and the aspect ratio is now about to be correct. (sorry, these are only screenshots)
This "Pizza Margherita with blue Curacao"-like JPEG will later on be the overlay for the Google-Earth representation.
But first, a 3D view of the lake:
This view is from below, looking up, so the "deep-Spots" in the lake are better visible. The spikes on the right side are depth-artifacts, coming from the launch-point, where the sonar transducer hit the ground.
There are three "deep" holes in the lake, they go down to about -11m, but the rest is in 3-5m range covered with waterplants, which gives a "billowing" effect in the orange and red area.
I think this view can be improved by changing the color scheme and putting a grid over it. (some new project for Jochen...).
Now back to Google Earth.
In GE, there is an overlay feature, that lets you mix the GE view with a picture. Now we have a picture, but how putting it all together getting it matched in terms of size and aspect ratio?
First of all, i activated all tracks, that we have produced in the past (the GPS Vizualizer thingy - you remember?). This will give us a picture like that:
Then, we activate the Overlay function in GE and take the picture with the blue lines as overlay. After adjusting the transparency, we can see both pictures. And then we can tear,push,shove and move the picture until it matches the tracks. This overlay we keep. Then, we do the same with the other picture (The Pizza-view) and take the overlay, we created before as a reference. So we arrange an overlay over an overlay over an overlay. Quite strange, but it works. This last overlay is THE overlay. If we save it as a .KMZ (not .KML!!!). We can distribute it to anybody who wants a quick pizza-service on Google earth.
So it looks like, before the matching of the overlays:
This is the picture it looks like, when all is done.
I try to provide the .kmz file here as a reference. (i splitted up the picture and the depth legend, so the legend can be placed anywhere.
Back to reality:
We tried it out on the next weekend-dive we had in the lake. We took the course from the launch-point to the "big-hole" on the leftmost side from Google-earth (the ruler-function), adjusted our compasses to that course and we hit the hole exactly!
Theory and practice in perfect match - that´s rare.
This was the Past. On my first blogpost on this site, a member (Tom) gave me a link to a swedish company which provides a software that does all the above with a few mouseclicks and the 3D representation looks even better. I tried the demo in the last days and it looked good. I think i will spent the 99 Euro-bucks and try it out.
Is anybody out there who has eventually experience with that Software?
It is called DrDepth: http://www.drdepth.se/
This is not the end of the story...
I think there will be another episode. Maybe you remember the oscillations on the plots? The solution to that will be posted next.
Here is a sneak preview:
Fighting with the Integrator, the NMEA parser bug, and a new platform...
Bye bye fire-brigade ship have a nice stay on the cellar shelf with Ken.
This may be of interest to the group !
>>>>>>>>>>>>>>>>>>INVITEFLY-IN
<<<<<<<<<<<<<<<<<<<<<<
OK people...How is this for the "First Annual EZ* (and More) Fly-In"
May 14 thru May 17 2009 (Friday thru Monday)..... Sunup till Sundown
with night flights optional.
Mountainair,NM 87036 (Center of NM)
75 miles SE of ABQ
Altitude 6500 feet (faster TO and Landings !)
Average sunny days .... 24
Average rain days ....... 5
Average Rain amount < .6 for entire month
Average wind for month 10 mph
Average high .............. 75
Average low ............... 41
Looks like middle of May is good.
No neighbors for over 2 miles and area is quite foot-able for those
pesky run away flights. Plenty of room for RV's or tents, and nice
motels and one hotel in town 3.5 miles away.
Noise is not a problem.......Neighbors are usually quiet.
Earl
1.-Download SparkFun Model from here
2.-Open Goggle Earth and click on the Tab Add>Model or just press Ctrl+Shift+M.
3.-In the next window click on "browse" and select the model you just downloaded with extension ".dae".
4.-Drag the building to any position you want and VOILA!!
Your own SparkFun building!
Hello, I did this because I noticed that the altitude of GPS is not stable. GPS coordinates are correct however.
They remain well within a radius of ten meters around the real point. But the altitude is completely crazy, it depends on the day, and even the moment of day. This is related to the position of satellites, I am in Europe, Is this the problem?.But, it's may be a problem for the stabilization of our plane in altitude. And increasingly it is not very accurate.
And with two I2C devices it works, cool.
What do you think of this approach?
After half a year of finding an adequate platform for the surveying system, we returned to the roots of the project: The survey of lakes. Further on, the project was called "Sea-Survey". The reaseon for that name did not arise from gigantomanic phantasies of surveying the oceans but in German the word for lake is "See" and the pronounciation is a little bit like "sea" in english, and this gives the project a kind of international touch :-). And -maybe in the near future- we might use the system for finding reefs and shipwrecks in the mediteranean sea, which is one of our beloved diving sites.
I am also talking of "we" instead of "i", because meanwhile the project attracted some of my colleages, who helped a lot, especially for the data conversion software and the 3d vizualization.
Thanks to Robert, Frank, Uli and Jochen.
One of the key requirements of the whole project was:
-keep it as simple and cheap as possible-
In terms of "workload" and "time-spent-swimming-in-the-lake" it definitely was not!
But, in terms of hardware and software costs, compared to professional systems, it was.
So we tried to use as much as possible "free" Software for the data processing.
The hardware cost added up to under 1.000$ (not counted the the "titaniced" Garmin etrex summit), which i find is still adequate.
The mission-planning tool was Google-Earth.
The analysis and PID-loop optimization tool was Google Earth.
The vizualization and publishing tool was Google-Earth.
The ArduPilot firmware development tool was not Google Earth, we used the Arduino platform instead :-)
The "extract-lat-lon-depth-from-NMEA-and-convert-it-to-something-useful"-tool was done by a PERL-script, written by Frank.
The "convert-the-whole-file-generated-by-Frank-to-UTM-data"-tool was a C-Program, that was written/adapted by me, consisting mainly of a WGS84 to UTM conversion routine that i found somewhere in a corner of the internet.
The 3D Vizualization was done by a MatLab script, written by Jochen. (I was lucky, knowing somebody who had a valid licence). Still working on this issue, because it will definitely be no lo-cost solution if you have to buy a MatLab licence. We tried SciLab instead, a FreeWare tool, which is close to MatLab, but it lacks in some essential functions that ease 3D vizualization.
The NMEA-data conversion to Google-Earth was done via a server-based tool called "GPS Visualizer" that can be found on this site: http://www.gpsvisualizer.com/map_input?form=googleearth
This tool is absolutely great! you can upload up to 3 NMEA Data files and convert it to .kml or .kmz files. The result can be viewed with Google Earth. As an option, you can convert every NMEA sentence to a waypoint, that contains all relevant data like speed, bearing, time and position.
Lets go back to the mission planning:
In Google Earth, we created a path, that merely was a zigzag or meander-pattern for the criscrossing of the lake (we are still looking for an optimal pattern). The path was then exported as a .kml file, that contains the latitude and longitude coordinates covered among lots of XML data. With a text-editor and some "copy-paste-search-and replace" operations we had a "const" data field that was pasted into the ArduPilot code.
Yes i know!
That can all be done much easier with the "ArduPilot config tool", but we are talking about the past!
I still prefer putting the waypoint data into a predefined array instead of the eeprom for several reasons:
- it is easier to handle
- i still use large parts of the V1.0 code of ArduPilot as reference.
- the space left in the Flash and RAM can hold up to several hundred
of waypoints, which is absolutely sufficient for a multi-hour mission, so why bother?
- you have to connect the FTDI-adapter and to disconnect the GPS module anyway, so there is no much difference between loading up the new code or loading up the new mission data into the EEPROM. Hopefully we will have ArduPilot-Mega available soon in Germany, which will surely change my opinion. I personally prefer having lots of UARTs in a system, but this is another story...
Much text, no pictures till now, so here we go:
This is the same lake, polluted with yellow and blue color, how awful!
The yellow one is a path, that was created by Google Earth and converted to a "C" constant array, that forms the waypoints. The blue one is the "real" path, the ship took. The oscillations are a special case, that will be addressed in one of the next episodes. The circle on the right side came from a collision with a buoy, that was there (the only one in the lake and i hit it...)
The data from the sonar system was sampled with another data-logger, i mentioned earlier. This one had the advantage, that the RS232 drivers are already on the PCB, so the output of the sonar´s NNMEA data could be directly fed into the datalogger. Anyway, if had known earlier, i had would have used the SparkFun one, because it is half the price and the firmware is open-source. The NMEA data from the sonar, which contained the GPS position and the depth information was converted with a perl script to a simple text file, which contains only three fields: latitude, longitude and depth.
In the first approach we had a simple "lat/lon-to-something-like x/y" conversion, but it lacked in accuracy and the picture was distorted.
For a 3D-representation, we converted the the latitude-longitude values to an UTM projection, which is better to handle.
I found some C-code fragments in the internet, which does this calculation. After this second conversion we have a file that contains the northing and easting values and the depth in meters.
so in short, we got the NMEA file, that looked like that:
$SDDPT,2.7,0.0*52
$SDDBT,9.0,f,2.7,M,1.5,F*0E
$GPAPB,,,,,,,,,,,,,,*44
$GPGLL,4821.0295,N,01001.2870,E,064449,A*2D
$GPRMB,,,,,,,,,,,,,*66
$GPRMC,064449,A,4821.0295,N,01001.2870,E,1.3,257.0,060509,0.6,E*7F
$GPGGA,064449,4821.0295,N,01001.2870,E,2,7,1.20,476,M,,,1,0*0B
$GPGSA,A,3,11,,20,14,19,17,28,,120,,,,2.30,1.20,2.00*32
$GPGSV,3,1,9,11,78,274,45,32,74,238,,20,42,245,42,14,35,53,39*78
$GPGSV,3,2,9,19,33,171,40,17,18,317,40,28,16,281,41,3,5,165,*43
$GPGSV,3,3,9,120,29,212,35*4F
$SDMTW,14.4,C*05
$SDDPT,2.9,0.0*5C
$SDDBT,9.8,f,2.9,M,1.6,F*0B
after the first conversion it looked something like that:
10.0214716666667,48.3505433333333,2.7
10.0214683333333,48.35055,2.9
10.0214633333333,48.3505566666667,2.7
10.0214583333333,48.350565,2.3
10.021455,48.350575,2.1
10.0214566666667,48.3505816666667,1.9
10.0214566666667,48.3505916666667,1.8
and after the UTM conversion it looked like that:
575685.808035, 5355782.793725, 1.100000
575685.064694, 5355782.969104, 1.200000
575684.321354, 5355783.144484, 1.300000
575683.580482, 5355783.134613, 1.200000
575682.713664, 5355783.308347, 1.100000
575681.599888, 5355783.478792, 1.100000
Please note: This fragments do not correspond, i took it out of the converted files arbitrary.
This file was finally fed into a matlab-script, that does the 3d visualization.
And this will be the story in episode 6.....
This board comes with a dsPIC30F6015 CPU and just for control servo ,receive redio-in and RF datalink.
It can provide the RF moden power directly and driving 4 futaba 3003 servos in the same time.
The sensors and gps will be integrated as one board and connect with this via connector for using new components in the future.
Just for fun.
The only pieces left to complete are numSV doesn't seem to be set right with the Ublox GPS adapter so I can't report on the number of satellites and I need to figure out a UTC clock source for the UTC time and DATE field. Might have to enable those messages on the Ublox.
I've only done bench testing with this as I'm still building my UAV, so if anyone wants to help out please add this to your print.pde file:
void print_remzibi(void)
{
int nMult=0;
int nMeters=0; //Change this to 1 for meters, 0 for feet
long current_lat;
long current_lng;
float lat=0;
float lng=0;
int lat_dd=0;
float lat_ff=0;
int lng_dd=0;
float lng_ff=0;
char *lat_hemi;
char *lng_hemi;
char *lat_zero;
char *lng_zero;
if (nMeters==1)
nMult=1;
else
nMult=3.2808399;
digitalWrite(13,HIGH);
Serial.print("$GPGGA,");
Serial.print("064951.000");//UTC time
Serial.print(",");
if(current_loc.lat < 0)
{
current_lat = current_loc.lat * -1;
lat_hemi = "S";
lat_zero = "0";
}
else
{
current_lat = current_loc.lat;
lat_hemi = "N";
lat_zero = "";
}
lat_dd = (int) (current_lat/10000000);
lat_ff = (float)((current_lat - (lat_dd * 10000000)));
lat_ff = 60 * lat_ff;
lat_ff = (float)(lat_ff / 10000000);
lat = (float)(lat_dd * 100) + lat_ff;
Serial.print(lat_zero);
Serial.print(lat);
Serial.print(",");
Serial.print(lat_hemi);
Serial.print(",");
if(current_loc.lng < 0)
{
current_lng = current_loc.lng * -1;
lng_hemi = "W";
lng_zero = "0";
}
else
{
current_lng = current_loc.lng;
lng_hemi = "E";
lng_zero = "";
}
lng_dd = (int) (current_lng/10000000);
lng_ff = (float)((current_lng - (lng_dd * 10000000)));
lng_ff = 60 * lng_ff;
lng_ff = (float)(lng_ff / 10000000);
lng = (float)(lng_dd * 100) + lat_ff;
Serial.print(lng_zero);
Serial.print(lng);
Serial.print(",");
Serial.print(lng_hemi);
Serial.print(",");
Serial.print("1,");
Serial.print((int)numSV);//number of sats
Serial.print(",,");
Serial.print(current_loc.alt/1000);
Serial.println(",,");
delay(50);
Serial.print("$GPRMC,");
Serial.print("064951.000");//time
Serial.print(",,,,,,");
Serial.print(ground_speed/100,DEC);//ground_speed
Serial.print(",");
Serial.print(ground_course/100,DEC);//ground_course
Serial.print(",");
Serial.print("020410");//date
Serial.println(",,");
delay(50);
//$M message bus system for remzibi OSD
Serial.print("$M");
Serial.print("82"); // Hex Column (01h - 1Eh) for small fonts add 80h (81h - 9Eh)
Serial.print("09"); // Hex Row (01h - 0Dh for NTSC, 01h - 10h for PAL)
Serial.print("BA"); // Hex address of First Character
Serial.print("00"); // Hex address of Last Character
switch (control_mode){
case MANUAL:
Serial.print("MANUAL");
Serial.println(" ");
break;
case STABILIZE:
Serial.print("STABILIZE");
Serial.println(" ");
break;
case FLY_BY_WIRE:
Serial.print("FLY BY WIRE");
Serial.println(" ");
break;
case AUTO:
if (wp_index == 0)
{
Serial.print("HOME:"); //Min length = 7
Serial.print((int)(wp_distance*nMult));
Serial.println(" ");
}
else
{
Serial.print("WP"); //Min length = 6
Serial.print((int)wp_index);
Serial.print(":");
Serial.print((int)(wp_distance*nMult));
Serial.println(" ");
}
break;
case RTL:
Serial.print("RTL");
Serial.println(" ");
break;
case LOITER:
Serial.print("LOITER");
Serial.println(" ");
break;
}
digitalWrite(13,LOW);
}
Then in your main Ardupilot_25_04 file add the following below the if print_telemtry section:
if(REMZIBI)
{
print_remzibi();
}
Also you'll want to then set REMZIBI to 1 in your define.pde
https://www.youtube.com/watch?v=MdQxBZTAv4Y
Its based on Arduimu - flat version.
Everything works at 50hz.
I used SPI to communicate between the CPUs.
Stabilization is simple gyros(drift corrected) feedback loop.
However when I tried adding proportional component to the stabilization (using the euler angels from the IMU) Icouldn't get reed of the oscilations... I gess its becouse of the delays...
any suggestions/comments will be appreciated!
Very nice prototype of a iPad UAV groundstation in this RCG thread. Was originally designed for the iPhone but clearly works better on the bigger screen.
MARCY 1 ATTITUDE HOLD 4 U
Attitude hold on Marcy 1 seems to be a disaster. In the wind, She seemed to actually stabilize with the attitude hold on. When She got near the trees, that must have confused the thermopiles & caused her to bank away from the trees, leading to a seemingly stable position in the middle of the fairway.
In 1 short break between storms, the attitude hold was a disaster.
Cyclic seems to be responding properly but is lagging by 1/2 a complete phase.
Lacking thermopile calibration, currently hard coding the gain & sign. Relying on manual takeoff, taking neutral from whatever the attitude is when the autopilot is engaged.
There is a way to sense when the magnetometer flips over due to pitch. Detect when its gain gets below a minimum. Record thermopile pitch at that point. When gain rises above minimum, if thermopile pitch is reversed, phase is reversed. Theoretically it couldn't reverse pitch & get mag above minimum at the same time. What if it really reverses pitch in 1 revolution where mag is below minimum?
The magnetometer can sense pitch with the thermopile for roll only. The thermopile is a much better pitch estimator than the mag.
Marcy 1 uses throttle modulation for attitude control & maximum flight time, but it reduces thrust by 1/2 & is worthless in wind. 1 option is to overdrive the motor with a 3S or a longer propeller. Also still searching for an actuator which can survive thousands of cycles & is light enough. Not happy about giving Canadia $20 for a crummy coil.
Throttle modulation may also reduce flight time if it causes the motor to run outside its optimum RPM & causes inertia changes in the propeller's airflow.
MARCY 2 CONTINUES AS A TRI ROTOR
With the weather closed back in, desired a more weather proof Marcy vehicle.
Rebuilt her IMU using the straight LISY300AL's from last year's buying spree & a 3/4" balsa cube. The ancient IDG300's just have too much trouble initializing & are too unstable to bother with. Can't see them ever being used for anything now.
Went back to radio foam instead of Marcy Foam #2009 because of the lack of space.
Unfortunately, a 1st flight test revealed the need for Marcy Foam. A bit too much vibration. Despite using the same motors & battery, the smaller Marcy 2 configuration has a lot more power than Vika 2. Maybe the extra cable, CF tubing, & plywood is significant.
RETURN OF STILL PHOTO TIMELAPSES
These are made in 1920x1440. If computing power wasn't so limited, they could go up to 3000x2300.
Now some notes on still photo timelapses.
Create a JPEG list of all the photos: ls `pwd`/*.jpg > list.jpg
Add the file format to the beginning of list.jpg. The format is JPEGLIST, framerate, width, height:
JPEGLIST
4
3648
2736
Create a Cinelerra project with framerate 4, canvas size 2048x2048, YUV color.
Load list.jpg into Cinelerra
Shrink camera so the images fit on the canvas.
Disable track playback.
Rewind to frame 0.
Attach motion.
Set motion thus:
Set the following:
Track translation & track rotation enabled.
Calculation: Save coords to /tmp
Action: Do nothing
Previous frame same block enabled
Draw vectors enabled
Position settling speed: 10
Maximum position offset: 50
Translation search steps: 256
Translation direction: Both
Rotation search radius: 10
Rotation search steps: 4
Rotation center: 0
Max angle offset: 50
Rotation settling speed: 10
Enable track playback.
Set translation block size so the block covers 1/4 of the scaled image & not the black area.
Adjust Block X & Block Y so the block is over an area which always has detail.
Set translation search radius to cover entire area of scaled image but not black area.
Remove all /tmp/motion0* files on every render node.
Render using renderfarm to compute the motion vectors. Use Quicktime MPEG-4 quantization 5.
Disable track playback.
Copy all the /tmp/motion0* files from every render node to the master node.
Set the following in Motion:
Calculation: Load coords from /tmp
Action: Stabilize Pixel
Draw vectors disabled.
Attach Time Average below Motion.
In Time Average set the following:
Frame count: 1
Restart for every frame: off
Don't buffer frames: on
Replace: on
Threshold: 1
Border: 4
In Settings->Set Format set Color model to YUVA-8 bit
Rewind & enable track playback.
Render to Quicktime JPEG maximum quality WITHOUT the renderfarm. That's the rough stabilization print. Motion must be rendered contiguously to accumulate the motion history. Next comes the smooth stabilization.
Disable track playback.
In Settings->Set Format set Color model to YUV-8 bit, Frame rate to 24.
Import the Quicktime movie in a new track & play through it to determine the new range of motion.
Disable playback in the new track.
Rewind to frame 0.
Attach Motion.
Set the following:
Track translation enabled.
Track rotation disabled.
Calculation: Save coords to /tmp
Action: Do nothing
Previous frame same block enabled
Draw vectors enabled
Position settling speed: 3
Maximum position offset: 50
Translation search steps: 256
Translation direction: Both
Enable playback of the new track only.
Reduce translation search radius to cover only the new range of motion.
Remove all /tmp/motion0* files on every render node.
Render using renderfarm to compute the motion vectors. Use Quicktime MPEG-4 quantization 5.
Disable track playback.
Copy all the /tmp/motion0* files from every render node to the master node.
Set the following in Motion:
Calculation: Load coords from /tmp
Action: Stabilize Subpixel
Draw vectors disabled.
Attach Time Average below Motion.
Use the same Time Average settings as the old track.
In Settings->Set Format set Width: 1920 Height: 1440
Rewind & enable track playback.
Render to the final output format WITHOUT the renderfarm. This is the smooth stabilization print.
This is our final timeline.
The Fire-Brigade-Ship era
The time came, when i left the idea with the bodyboard and turned to something more „ship-like“. A colleage of mine got the RC-model of a fire-brigade-ship on ebay. This monokeel-hull, was the new platform for the further testings. I kept the windmill-propulsion system for this ship for two reasons:
1. No trouble with water plants and algae that will clog the propeller
2. The air-propellers coming from the RC-model scene are better engineered and tuned to the motors than the ones for RC-ships.
This is a picture of the fire brigade ship before the violation.
First i ripped off all the superstructures of the ship. (The hardcore scale-model enthusiasts will kill me someday for this sacrilege).
Then i put the windmill assembly on the aft of the ship and about 1.5 kg of lead in the keel and tried this assembly with the RC. This approach seemed to be a better solution than all that fiddling-around wirth the body-board. Very stable straight-line behaviour.
Around this time i stumbled over the ARDUPILOT on the diydrones.com homepage when googling for a GPS module. I looked at the schematics and the software and one hour later i ordered the ARDUPILOT board and an EM406 GPS trough a German reseller of the SparkFun products.
Thank to god, my wife was on a wellness trip on the following weekend, so i had enough time to get the Arduino enivronment running. I took the V1.0 Software from ARDUPILOT, as a starting point, because it was simple enough to control a ship. First i got it running on the Jet-Ski Platform to prove, that it works.
And it worked! (1000 Thank-yous to Jordi, you have done a very good job!)
It was fascinating to see the little ship oscillating to one waypoint and comming right back to the shore. It was kind of an electronic water-boomerang.
If i look back to this first try, it must have been pure coincidence, that the ship managed to find the waypoints. Afterwards i found some bugs in the software and in the conception of the ship´s mechanics, that i still can hardly believe that it really worked on the first hit.
After the violation
A look inside (and on my shoes)
From now on, the really hard times started.
I moved the whole assembly to the „violated fire-brigade ship“ and tried the Software. Not bad for the beginning, the ship oscillated, but found its waypoints.
Thinking, i had the breaktrough was false at that time, but i did not realize that.
In the following i describe the setbacks and the successes.
The optimization of the PID parameters started.
Meanwhile it was plain summer and the temperatures of the lake were OK for recovery-swimming actions.
Optimizing is frustrating, but good for your body-fitness. I stopped counting the times i had to swim to the ship, that managed to crash to the shoreline on the opposite side of the lake, or to stop the motor in the middle of the lake, because my timeout-security mechanisms fired too early.
By the way, the body board turned now into a "recovery-device", which makes it easier and faster to swim if you have fins on your feet.
The project started to turn from a „Survey-the-lake-and-draw-a-map“ to a „build-a-ship-and-optimize-an-Autopilot“ one. But the journey is the reward.
The main objective was to get the ship driving a straight line from one waypoint to another. The waypoints should form the edges of a mesh to get a kind of a x/y/z grid of the lake.
The Problem was the straight line. Sometimes it was OK, sometimes not. In rare cases the ship made absolutely crazy figures on the lake, which i first supposed to be GPS malfunctions.
After a couple of weeks, the course of the ship was very stable and then i mounted the GPS-Sonar assembly on top of the ship. The NMEA output of the GPS/Sonar was stored on SD card of a Datalogger, which i bought some weeks earlier.
Here is the link of the manufacturer: http://www.engelmann-schrader.de/usbstick.html
Horror of Horrors. The ship started oscillating very heavily, the behaviour was unpredictable. If i was lucky, the waypoints were hit after loitering around some times, but often it happened, that he ship circeled around a waypoint without finding it. My swimming skills went better and better in this time. First i thought, the PID parameters had to be optimized again, but theory and practice were quite different at that time.
Inreasing the differentiator part helped a little bit but not much.
The process of optimization of the PID is very time consuming if you make it by the try-and-error method, but it was the only one that worked.
It worked like this:
#1 Driving to the lake in the early morning (before work)
#2 Starting the ship with the new parameter set.
#3 Regarding the behaviour of the ship.
#4 Sometimes swimming for the recovery of the ship.
#5 Thinking...
#6 Changing the PID parameters by reprogramming the ARDUPILOT
Restart at point #2
Go to work, think about why that f...ed ship does not behave as it should.
Discuss with colleages.
Everybody had his own theory.
„Increase P, „decrease I, no D, because it will make it unstable“
„no, no, increase D, this will make it more stable“
#7 Go back to the lake after work and restart at #2.
After three weeks i found the problem:
Very simple.
Very Very simple.
Too simple to tell.
The center of gravity has been slightly shifted to the fore by the weight of the Sonar assembly (about 1.5kg)
Shifting it 20cm more to the aft and into the ships belly cured the problem.
Then there was the black day.
On one of the test-drives, all peripherals (batteries, sonar, autopilot) were on the top of the ship, lousily attached with some sticky tape. My beloved handheld GPS (a Garmin etrex summit, which i used as a data-logger) lied on the deck without any attachment. The ship went off for some 100m and, in in a sharp turn, the battery-pack went off-board and the attached cables teared the whole ship upward down. It was pure coincidence, that the ship did not sink. The etrex summit GPS was gone, the whole electronics and the motor was under water an i broke the world record in recovery-swimming. After some hours of air-drying, the electronics still worked, even the GPS module! Only the servo was dead. Afterwards we made some dives around the waypoint, where the disaster happened, but the etrex summit was gone forever, covered by a bed of water plants.
From this time on, i kept the electronics sealed in a plastic box and the battery-pack was attached inside the ship.
One of the unlucky test-drives. The short straight line on the upper left corner is me, swimming back.
Then another failure became obvious:
The fine tuning of the PID-Parameters turned into a nightmare. Nothing behaved as it should in theory. We made tenths of test-drives with exactly the same parameters, but every time. the ship took a slightly different path. Changing the PID parameters did not really cure the problem. To see, what happened, i bought a second datalogger from SparkFun to look at the debugging-messages, we inserted into the ArduPilot code.
The link to the Sparkfun datalogger: http://www.sparkfun.com/commerce/product_info.php?products_id=8627 (very stable and well priced product)
After long research, we found some obvious errors in the PID control loop (some float to int conversions), but the main problem still persisted. Then one day, we found the cause for The strange behaviour: Sometimes, the NMEA parser yielded erroneous values on startup. So it could happen, that the course over ground value was some 50.000°, which obviously gave a very huge error, which in turn led to very high integrator startup values. This high integrator values led to an offset in the yaw-rudder values, which made it hard for the proportional part to compensate.
We have not found the error in the NMEA-parser yet, but as a workaround, we hold down the integrator value to zero for some seconds after each waypoint switch. (More of that story in a later episode).
Going better and better. The blue line is the path. the ship shall follow, the red lines are the real missions. What you can also see, is me, walking back to the car and reprogramming the Ardupilot with new PIDs.
With this final tuning, we made lots of criscross-maneuvres on the lake to collect as much depth data as possible.
Thats all for today, in the next episode i will tell something about
mission planning, data conversion and 3D vizualization.
