Replies to This Discussion

3D RoboticsPermalink Reply by Chris Anderson on October 13, 2008 at 7:56am

That's an ambitious project! Are you sure multiple atmega128s are the way to go for the microprocessors? Running a proper IMU is asking a lot of them (the only reason we use a simlar dual-core approach is that we're running simpler theromopile-based stabilization). You might have better luck with a single, more powerful processors, such as an Propeller or (if you can handle the complicated toolchains) ARM7.

• ▶ Reply

Permalink Reply by Brett W on October 13, 2008 at 12:33pm

Hi Chris! I chose the ATMega128's because I am used to programming them. The fastest in the AVR line is 32MIPs (The XMega Line). I don't know if my BASCOM-AVR compiler even supports that line.

I'm probably going to use 3 AVR's for this sytem. The first will be responsible for decoding the incoming signals from the FASST receiver, and outputing PWM to the servos. It will also connect to the autopilot, which can then send commands to move the servos. Essentially, it's a super-duper servo multiplexer capable of a few extra features. The second AVR is the autopilot, which will have the gyros, accelerometers, barometer, and compass wired into it. As it makes it's measurements and calculations, it sends servo movement commands to the first AVR to be executed.

Lastly, I have a third AVR that is used for all other non-critical purposes such as the data link, and payload related functions. All three AVR's are connected together on a common bus so they can communicate information back and fourth.

I divided them up like this for safety reasons. I didn't want to have one microcontroller in charge of everything, and having to worry about how often a routine is run in order to maintain stable flight. I think three AVRs will make things a bit easier to get off the ground. I have no experience with the Propeller or ARM7. I program with BASCOM-AVR in basic format. Are there more powerful processors that can be programmed in Basic that I am unaware of?

What are your thoughts?

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on October 13, 2008 at 12:38pm

Hmm. Well, C isn't much harder than Basic, but I understand the appeal of sticking with what you know. I love the AVR chips (they're what we use with the Arduino-based autopilots) but I just wanted you to consider the computational demands of an IMU.

I think what you're describing sounds like a fun project, and I'd be delighted to know that an AVR could handle it, so I'll be watching with interest.

• ▶ Reply

Permalink Reply by Brett W on October 13, 2008 at 12:42pm

Which AVR are you using, and what is it sensing/controlling? What's the clock speed?

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on October 13, 2008 at 12:58pm

In ArduPilot Pro we use two Atmega168s at 16mhz. See that tab above for more.

• ▶ Reply

Permalink Reply by Brett W on October 13, 2008 at 1:15pm

Interesting. So your thought is that the gyro and accelerometer computations would need more horsepower than the 16MIPS AVR could provide?

I guess if it takes a lot of computational time, the result would be slower refresh rates overall. For example, if there's a lot of math going on, I might only be able to achieve a 10Hz update rate to the servos. But if it's less math spread over multiple processors I might get away with 40Hz or more.

We will see how it turns out. It will be a little while before I get to that point anyway. I'm still settling in on specific sensors and starting to design the PCB.

Thanks for the feedback Chris!

• ▶ Reply

Permalink Reply by bGatti on October 13, 2008 at 7:57pm

Some comments:

The compass is tilt-compensated, but it uses an accelerometer to determine orientation. It is just me, or is the movement of the UAV likely to be interpreted as a false horizon, therefore invalidating the tilt-compensation. It seems better physics to use GPS vectoring to establish compass bearing?

The Arduino project has several references for interpreting PPM. If you are lucky, the fasst output includes a composite serial line you can tap.

I would second Chris's suggestion that moving from micro-basic to micro-c (ie Arduino) is quite seemless (And I say that as a VB nerd who breaks out in hives around c++) The beauty of Arduino and C is the existing libraries and samples for this work - much more powerful than BasicStamp.

This may be a good time to explain how a gyro maintains a good horizon without an infrared reference. Can the GPS be used to make corrections? Someone? My understanding is that these gyros will drift - am I wrong?

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on October 13, 2008 at 8:13pm

Yes, gyros drift, and an accelerometer alone is not enough to correct a compass. Ideally, you'd run a 6DOF Kalman filter to establish the vertical vector and use that to correct the compass. I don't think the GPS itself will be super helpful since the plane can be crabbing into the wind and basically flying sideway, which the GPS will know nothing about.

As a rule of thumb, a compass will show a 20% error with a 10% tilt, so it's well worth correcting it if you can.

That said, you can have a perfectly good autopilot that doesn't have a compass at all (witness AttoPilot). Frankly, I wouldn't bother with it for a hobby autopilot.

• ▶ Reply

Permalink Reply by Brett W on October 13, 2008 at 8:42pm

Chris,

You bring up a great point. The compass is something I can add on later if I need it. The problem I see is that I am looking to use the already tilt-compensated compass. If I go without it, I'll need to build three accelerometers into the system. Whenever I do add a compass, it will end up being a non-compensated one and I would compensate it myself in the code.

Do you have any examples of tilt-compensation theory for a compass?

Also, why wouldn't accelerometers alone be enough to compensate a compass? My understanding is that the compass is corrected based on how far it's tilted on each axis. A 3 axis accelerometer will give that exact information. Please shed some more light on this. Thanks!

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on October 13, 2008 at 9:47pm

If you're only using the compass on the ground, you should be fine. But in the air, when you're banking, inertial forces are indistinguishable from gravitational ones, so you need gyros and accelerometers to work together to eliminate errors. See this for more.

• ▶ Reply

Permalink Reply by bGatti on October 14, 2008 at 4:57pm

Ever contrary,
Can I suggest that an airspeed indicator and a GPS could be used to unravel the wind effect.

I'm thinking elaborate schemes like circling and comparing ground speed to wind speed would determine wind speed and heading.

But I also think a heading gyro would be required to make any use of it.

In flight the difference between airspeed and ground speed can determine the wind component of the current vector,

Perhaps even small vector excursions could be used to triangulate the full wind bearing.

• ▶ Reply

Permalink Reply by Brett W on October 13, 2008 at 8:14pm

Hi bGatti.

I suppose forward or sideways acceleration of the UAV could throw off the compass. I'd have to research it more.

I tried emailing Futaba for PPM information on the FASST receivers, but they wouldn't help because it's "proprietary information". I've devised a circuit that might do the trick. I still need to finish drawing it into the schematic though.

You reference the BasicStamp. I'm not using this. As far as I know, the BasicStamp line is outdated and pretty slow. I'm using an AVR, which is the same style chip as the Arduino, but I'm programming it in a different language (Basic, not C). I've used this combination before and it's pretty powerful in my mind. I think it can do what I need and more.

Gyros do not use infrared. Thermopiles do. Gyros measure the rate of rotation by sensing the changing characteristics of a mass inside the sensor, so they don't need infrared. The datasheet for the gyros talks a bit about this. I hope my understanding is correct! I would just used GPS for the heading, and it would work well at the 4Hz refresh rate my GPS receiver provides, but I want to be able to sense heading prior to takeoff which is where GPS won't work since I wouldn't be moving.

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page