Blogs

All Posts (14048)

Sort by

Ardupilot goes into the water Part 9

Posted by Harald Molle on April 11, 2010 at 1:01pm
Yes i know!
I am late with this post, compared to the other ones.
Easter holiday is over, back on work.

Had to prepare a presentation and a demonstration of the surveying system, which i held at our local diving club on the weekend.

And i felt in love with the Dr. Depth Software. Real great stuff! After having sorted out the philosophy of operation, it was pure fun, creating new maps. There are good tutorials out in a yahoo group, that make it easier to understand some things.

All this consumed a lot of time which in turn choked my writing organs.

The presentation went good, hope that the spectators were not too confused about the technical stuff.
And the demonstration on the lake busted one of Murphy´s laws, stating that "If anything can go wrong, it will".
Nope!
All went boringly easy:
The ship went off for a 30 Minute ride, did its criscrossing over the lake, came back, switched off the motor 3 meters before it hit the shoreline and glided smoothly back to the launch point. This moments are rare in live! All systems worked as they should. No evil buoys, no panicked swans attacking the ship, no motor switch-offs, no oscillations. I still can´t believe it!

Stop dreaming Harald, back to reality.
I wanted to tell something about the Autopilot Hardware in this episode, here it is:

I think it is of no use, explaining the ArduPilot Hardware in depth on this site, because this has already been done in the ArduPilot manual. I will only focus on the differences to the "original", which are very minimal.
The biggest difference between the original is that i do not use the "fallback" solution for the RC-controlled recovery, because the missions of the ship (in future) will be by far beyond the reach of a (legal) RC system. (And the thrill is much bigger, when you know, that a software error can ruin your day by forcing you into a recovery-swimming action!)

The "fallback" solution is realized by the ATiny processor (U3 in the schematics). The ATiny measures if there is a switch signal from one channel of the RC receiver, and controls the multiplexer (U4). This multiplexer switches the source for the servo-controls. (either the control comes from the ATMEGA or from the RC-receiver).
Normally this should work without problems, because the multiplexer defaults to the ATMEGA (for the RTH / RTL functionality). But in my case there is no RC Receiver connected to the "switch" input. There are no pull-up resistors involved to keep the input level to a default level and i do not know if the internal pull-ups of the ATiny are used. To avoid erroneous readings by EMC effects, i disabled that functionality "hardwired".

This is done by two measures:

1) isolating the "TSCK" pin (pin 7,U3) of the ATiny by lifting the pin.
2) connecting Pin1 of U4 with VCC (Pin 16 of U4) to force the multiplexer to the B inputs, which come from the ATMEGA.

The modifications can be seen in the following pictures.




This are the only modifications on the Arduino-Board. Maybe this is unnecessary but i wanted to be shure, that nothing inwanted can happen. Maybe Jordi can tell me if this was necessary or not.

The rest of the hardware configuration is fairly easy:

EM 406 GPS connected directy to thec onnector U2,
The ESC ( Electronic Speed Controller) connected to the port "OUT1",
The yaw servo (the windmill turn servo) connected to the port "OUT2".
A DataLogger for Debugging purposes is connected to the Output UART from the ATMega.

The ArduPilot Board is powered by the BEC-functionality from the ESC, so there has to be a bridge between Pin 2 and 3 on the Jumper JP7.



Here is a Block diagram of the whole stuff:



Some of the components:

The ESC..

The (optional) DataLogger...

the well-known EM406

and the battery-Pack, which consists of three surplus LiIon Packs from medical equipment. (12V/16Ah(


Thats all fir the moment about the hardware-configuration.
In the next Episode the Focus will be more on the Software side.
I think one episode for the software will not be enough.
Lets see what future writing will bring...

Read more…
3D Robotics

Preview of Turn-Rate Limiter ArduPilot shield

Posted by Chris Anderson on April 11, 2010 at 11:00am


While we work on ArduPilot's big brother (Mega), we wanted it to have a little brother, too: a cheap and easy entry-level autopilot.


The best way to do that is with a tried-and-true design, a turn-rate-limiter. The way these work is that they have a yaw gyro and a GPS. The yaw gyro stabilizes the plane, based on the correlation between bank and yaw (it works best with relative stable aircraft, ideally those that are flown with the rudder rather than ailerons, such as the EasyStar or many high-wing trainers). Meanwhile the GPS corrects for yaw gyro drift and handles navigation. It's not meant for FunJets and flying wings, but for the kind of relatively stable aircraft most newcomers start with, it can perform well and be very easy to set up.


One example of this style is the UNAV PicoPilot, which was designed nearly a decade ago. We thought it was time to come out with a modern version, based on the faster GPS modules and better gyros available today, and make it open source.


Ideally it would be priced well under $200 with everything all included. It's USB-native and self-contained, requiring no additional parts--it just a shield that plugs on top of the current ArduPilot, so it can use the standard groundstation and configuration utilities.


The above image shows the board design, which is close to going into prototype production. We may switch GPS modules to the 5Hz Locosys (Mediatek) module before we release it (cheaper, possibly better performance with the small patch antenna), and we're going to test the 25mm ceramic patch antenna vs the 18mm antenna to see how much difference they make.


Jeff Turner and Scott Plunkett are leading this team, with board tweaking by Jordi Munoz.


We'd love your feedback at this stage!


The Eagle files are here:

Turnrate_shield_nice.sch

Turnrate_shield_nice.brd



Read more…
3D Robotics

Podcast/Livechat tomorrow (Sunday) night with Project Andromeda, 9:00 PST

Posted by Chris Anderson on April 10, 2010 at 11:48am
Free video streaming by Ustream

Tomorrow night we'll do podcast #21, which everyone here is welcome to participate in by listening to the chat live above and commenting and asking questions via the DIY Drones chat function. We'll be starting at 9:00 PM PST and will probably go about 40 minutes.

This week we'll by joined by Nima Kayvan, of the Project Andromeda team, which is competing in this years Australian Outback Challenge. Along with creating their own autopilot (using a commercial IMU), they built their own CNC machine to make their beautiful airframe a reality.

As always you can subscribe to the podcast here. Tonight's livecast will be recorded and available as a podcast by Tues of the next week.
Read more…
Developer

Altitude sensing - Ublox versus SCP1000

Posted by Doug Weibel on April 9, 2010 at 1:30pm
I got a SCP1000 absolute pressure sensor and have been looking at the relative performance versus ublox.


Here is the data from my first flight test - ublox is blue, scp1000 is pink. The data was taken while manually flying a SkyFun "pusher jet" in somewhat gusty wind conditions.


There are several things that stand out to me. First is that the scp data is a lot "noisier". Does this actually represent the movement of the aircraft? Perhaps. I cannot really say after this one test.


Second is that the ublox appears to lag badly during fast descents. Seems to keep up going up, but not so much coming down. I suspect this has something to do with the ublox filtering algorithm.


The third thing I see, about which I am the most curious, is that something produced some kind of offset to the pressure at the beginning and end of the flight. If you look closely at the beginning of the graph, you can see that the pressure altitude starts at the same value as the gps altitude (by definition in the software). However, while still on the ground, something causes the pressure altitude to jump down about 22 meters. It bounces back and forth for one period before takeoff. Then at the end of the flight, you can see that the landing altitude is about 22 meters below actual, but then something happens on the ground that causes it to bounce back up around the correct value. This is a real problem. My only theory so far is that putting the canopy on may be trapping some small amount of pressure. However, if this were the case I don't know how the sensor would have the relative level of accuracy it does during the flight. The effect does not appear to be related to airspeed, as the changes noted at the beginning and end were while not in motion.


I also noted that except for the bottom of the "second valley", the effect I noted above, if it is coming and going, could produce the "noise" seen in the pressure altitude. You can see that the peaks of the "noise" correspond fairly well with the gps altitude for much of the flight.


I welcome all thought and comments.....


Read more…

AIPTEK P-HD WARS

Posted by Jack Crossfire on April 9, 2010 at 10:57am
MARCY 2 FOAMED UP




Replaced the radio foam with Marcy Foam #2009 & that fixed the vibration, driving the gains way up. Yeah, it's that important.




Discovered PWM on Marcy 2 only updated at 166Hz. These problems are caused by lack of bits, so you try prescaling the timer to fit it in 16 bits. That broke rate damping. Only explanation is PWM granularity got too low. Reverted back to the unprescaled timer & added PWM debugging code. That got it to 200Hz. More points for ARM.

AIPTEK P-HD AT NIGHT

Back in the HD world. 3 years after spending $450 on the Canon TX1 & crashing it, spent $55 on an Aiptek P-HD. Though lacking zoom, it's intended for aerial video only.




So you wanna fly the $50 Aiptek at night, eh. In night shot mode it does 15fps. Results with & without night shot mode are comparable to the Canon A480. Not bad for a pinhole lens.

Your best move with the Aiptek is to stack stabilized frames shot in normal mode. It actually looks better than daylight footage because the warping is hidden.


Rolling shutter warping abounds in daylight. As expected, the corny pistol grip case vibrates sideways. It's bearable at night, but daylight footage is worthless. The 848x480 60fps mode just crops the image instead of scaling it. The Canon A480 remains the still photo champion.


It's so cheap, suspect we'll destroy it eventually & install a wide angle lens.










Without nightshot.



With nightshot.


4 stacked frames


Video is recorded at 5mbps. Headed up to our top secret altitude for some HD video. Had perfect radio contact this time, probably from flying 20m horizontally from base. Actually came out 25m lower than desired due to barometer temperature.








Unfortunately, the rolling shutter is making the video worthless. Not likely to get that stupid pistol grip to stop shaking sideways. Not likely to reorient the circuit boards to make a better case. Best idea is a balsa pyramid with foam.

Finally, there's no way to disable the Chinese piano chord which plays every time it turns on.


MARCY 2 FLIGHT

With any new design, every golf course trip ends in a crash. Every day, Marcy 1 & 2 take turns being repaired while the other 1 flies & crashes. The main causes are drifting out of radio range with Marcy 2 & getting blown out of radio range with Marcy 1.



Marcy 2 did some autonomous hovering using sonar before she crashed due to radio range. Only got 1 shot where Canon light metering worked.






Got a loop antenna & then the Hitec HS81 burned out.





MARCY 1 FLIGHT

She once again proved the difficulty of monocopter control. If you command a monocopter to tilt, it's going to tilt 1 way & immediately start oscillating the other way regardless of cyclic. Defeating the oscillation & not sensing attitude is probably all that's required to solve position hold. Cyclic doesn't flip her over.



Then She got blown out of radio range & crashed.

After extensive negotiations with the Air Force, managed to move forward on declassifying the Marcy vehicles. They're in a place Major Marcy can easily see them, but She probably never will. She seemed to put up with the idea of aircraft named after Her despite consistently shutting us down over any attempt to see Her in real life.


MORE AIPTEK P-HD 4 U



Another attempt to stop the sideways shaking. FUGGEDABOUTIT. Doesn't look good in the sideways shake department. Also, the battery won't charge anymore. It's 1 of those chargers where the voltage has to be below a certain amount before it'll charge & the maximum voltage gets lower & lower. Getting closer to the next teardown.

Read more…
3D Robotics

Can it actually be true that the Wasp MAVs cost $291,000 each???

Posted by Chris Anderson on April 7, 2010 at 9:55pm
According to Defence Tech:

"The Air Force is asking for $3.2 million to purchase 11 WASP micro air vehicles – those wicked little Aeorvironment throwable drones that peek over the next ridge. The Air Force says the drones will allow:

Battlefield Airmen to rapidly adapt to the dynamic war fighting environment of the Overseas Contingency Operations (OCO). The system provides increased situational awareness in a combat environment, enables ground-based Battlefield Airmen to find and track time-critical targets, and provide bomb damage assessment and force protection for forward-deployed troops."



That's $291,000 each. Can this possibly be right?
Read more…

ardupilot goes into the water Part 8

Posted by Harald Molle on April 7, 2010 at 11:06am
Fighting with Dr. Depth.


No No, i am sorry, no Talk about the Autopilot in this episode, this will be done in the next one.

Yesterday i bought one copy of the DrDepth Software.

The first hour playing with it was frustrating.
Putting the NMEA Raw Data from the Sonar into it was a struggle.
If yo push the convert button, it says "conversion OK", but nothing happens.
After some time i found out, that this function does what it means: It converts the data. But nothing more. You then have to re-open the converted file, then it worked. The next problem were the depth artifacts from the launch-point. They created a real abyss on the launch point (about 6600m in depth)
Which in turn made the rest of the plot very flat ;-)
After having sorted out all buttons and switches, the Batteries of my MacBook went down. (the AC Adapter i have left in the company). Close to the finish and i missed it!
Nearly sleepless night.

In the morning i first did a little bit of NMEA Archeology, to find all the various files i have sampled in the past six months. A pretty lot of files!
Then i manually took out all the artifacts (the times, when i knew all the switches of GREP by heart are long ago and so i did it with a text editor). Where is that copy of this old UNIX manual from ´84 ? Maybe Ken is reading it on my bookshelf, should have a closer look in the cellar.

Then all data converted (and re-opened :-) ) in DrDepth and :

- thats it -

... in 2D ...

...in 3D...


... And the contour lines
Real amazing! It also creates the.kml reference files for the 2D and the contour files with alpha-blending.

It is crazy, what it produces with such a low amount of data! I took only a few criscrossing trips and a better result than all that MatLab crunching.
OK, there are some weaknesses in the Program, but actually im am still in the enthusiastic phase.

Thats all for today, next time something about the ArduPilot Hardware (i swear)...

Read more…

Submit your robot & win $1,000 in robot prizes from GoRobotics

Posted by William Cox on April 7, 2010 at 9:00am

april_giveaway1.png


I'm giving away $1,000 in robot prizes to celebrate the 10th birthday of my robotics blog, GoRobotics.net, this month! To enter, just post a comment with a link to your best robot here: http://www.gorobotics.net/the-news/robot-giveaway-10-years-of-gorobotics-1000-in-prizes/. Big thanks to our sponsors Pololu, Trossen Robotics, Zagros Robotics, Solarbotics , Vex Robotics, Apress, and No Starch Press.


Here's the prizes:

Grand Prize –Vex Dual Controller Starter Bundle with RobotC (donated by Vex Robotics), Pololu Jrk 21v3 USB Motor Controller (donated by Pololu), Build Your Own CNC Machine (donated by Apress), LEGO Mindstorms NXT One-Kit Wonders (donatedby No Starch Press). ($605 total!)


2nd Place Prize - Penguin Robot (donated by Trossen Robotics), Extreme NXT(donated by Apress), Wall Hugging Mouse Kit (donated by Zagros Robotics), LEGO MINDSTORMS NXT Thinking Robots (donated by No Starch Press) ($268 total!)


3rd Place Prize – Oomlout Arduino Experimenters Kit (donated by Solarbotics),Practical Arduino and LEGO Mindstorms NXT 2.0: The Kings Treasure (donated byApress), and The Unofficial LEGO MINDSTORMS NXT Inventor’s Guide (donated by No Starch Press) ($165 total!)


Hope to see lots of flying robots posted! Good luck. Don't forget to post your comment here: http://www.gorobotics.net/the-news/robot-giveaway-10-years-of-gorobotics-1000-in-prizes/

Read more…
Moderator

From the US Airforce, I'm off to get a fishing boat.

Posted by Gary Mortimer on April 6, 2010 at 11:30pm

dronejpg-bcc5cec385f619c7_large.jpg


EGLIN AIR FORCE BASE, Fla. -- A man fishing about 60 miles offshore from Tampa, Fla., on Sunday spotted something unusual: A BQM-167 drone out of Tyndall Air Force Base.

Instead of calling the Coast Guard in Mobile, Ala. -- which is what the Air Force recommends when people see such objects in the Gulf -- the fisherman towed the drone ashore to Madeira Beach.

The BQM-167 belongs to the 82nd Aerial Targets Squadron, a tenant unit at Tyndall, and was lost March 10 due to an engine flameout during a routine training exercise, the Air Force said in a news release.

MacDill's Explosive Ordnance Disposal technicians secured the drone and a team from the 82nd is expected to retrieve it this week, the Air Force said.

Now it makes me wonder how many more are down in the depths, if only I could find some sort of cheap open source based boat with a sonar on it so I could look.

Reading a little more I see they are water recoverable, so I guess the airforce was looking for it.
Read more…
3D Robotics

Virtual Arduino

Posted by Chris Anderson on April 6, 2010 at 10:00pm


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)

Read more…

Another 3-Axis Digital Gyroscope

Posted by Paul Marsh on April 5, 2010 at 7:00pm

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

Read more…

ardupilot goes into the water Part 7

Posted by Harald Molle on April 5, 2010 at 11:43am
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.

Read more…
3D Robotics

Introduction to PixHawk ground control station (including source code)

Posted by Chris Anderson on April 4, 2010 at 8:00pm

Operator view

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:

Engineer view


Parameter / Settings / MAVLink View


Pilot view

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
Read more…