Replies to This Discussion

Permalink Reply by David on August 6, 2009 at 6:45pm

Hi, Bill:

So if I connect ESC to Radio 1 and connect the Rudder and Elevtor servos to Servos 1 and 2 on the UAV board, I should be ok to modify the code and to drive the servos, is that right?

Thanks

• ▶ Reply

Permalink Reply by William Premerlani on August 6, 2009 at 7:50pm

David,

Right. If you connect ESC to Radio 1 and connect the Rudder and Elevator servos to Servos 1 and 2 on the UAV board, it is ok to modify the code and to drive the servos.

Just remember, though, in that configuration, there will not be any PWM inputs coming in from the radio, so be sure to drive the servos from computed values only, not from any PWM input information.

Bill

• ▶ Reply

Permalink Reply by Elardus Erasmus on August 12, 2009 at 3:20am

Hi All,

Has anyone out there tried to apply the DCM approach to a terrestrial vehicle (car, bus, etc.) to determine pitch and roll while driving (these angles would of course include both the road attitude and vehicle attitude relative to the road due to stabilisers, dampers, shocks, and such).

Having read the draft documentation on the theory behind it, and the paper from Mahony et al. it seems that this approach would be well suited for use in cars too. Maybe even a bit of overkill. I.e. if it works for planes it seems that it should work equally well and probably even better for an earth bound vehicle which is more restricted in terms of movement/direction of acceleration and turns (no wind effect for example).

One thing that does not fit too well with the current DCM approach is that it makes use of the GPS indicated speed, which (if we leave the effect of wind alone for now) is never zero during flight, therefore always having a good indication of true (ground) speed. But in a car the GPS would show small (erroneous) values for the speed while the vehicle is actually standing still, possibly affecting the outcome of the rotational matrix. One can probably work around this though.

Any thoughts?

BTW, great work Bill!

Regards,
Elardus

• ▶ Reply

Permalink Reply by William Premerlani on August 12, 2009 at 1:38pm

Hi Elardus,

I do not know if anyone has tried DCM on a car, but it should work just fine, even if the car stops from time to time.

Somewhere along the way to the firmware that I have now, I controlled an RC truck with GPS and gyro only. It worked ok even when the truck stopped. It did lose track of its orientation when it stopped, but it quickly recovered it when it started up again.

With DCM, here is what would happen: when the car stops, there will be yaw drift. But if you do not stop very long, the drift will not be very much, and you can start right up again. In fact, since you do not have wind to worry about, you could use PI feedback gains for a car that are much lower that what you would need for a plane, so you could stop for quite a while without much drift.

Once you start up again, there could be some directional error, but the car will travel in a curve that will eventually approach the desired direction.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Brian Wolfe on August 12, 2009 at 2:14pm

Elardus, Bill,

I used the DCM to control an RC car. Here is a Video.

It worked great. I got good plots of vehicle pitch and roll. I was using a magnetometer to determine heading and control the Yaw drift instead of the GPS, but I had a heading offset because I didn't account for my local magnetic decliniation of 13deg. It resulted in a curved path similar to what Bill describes. My plan is to merg mag heading with GPS heading, favoring the magnetometer when the speed is slow and the GPS heading as velocity increases. Should give the best of both worlds. Once you get moving, the GPS heading is really pretty good. The difference between the two could be used for wind estimation as well but that's not so important with a ground based vehicle.

I controlled the velocity manually, but if you wanted to control the speed automatically your right the GPS velocity when stationary would have to be considered. Many GPS receivers will filter that to minimize false velocities when stationary, but that introduces problems of its own. Your best bet would be to add a simple pickup encoder to one or more of the wheels to determine speed. You could use one of the PWM inputs on Bill's board to read in the pulses.

I don't see off hand how the velocity error will cause a problem with the DCM however. It's more an issue of holding a desired speed which is a loop outside the DCM equations. Bill would know if he uses it for a correction term but my implementation is not at this point.

Brian

• ▶ Reply

Permalink Reply by William Premerlani on August 12, 2009 at 3:28pm

Hi Brian,

I completely forgot about your work with an RC car, thank you very much for your thoughts. I somehow imagined you were working with aircraft.

Regarding velocity error, the accelerometer inputs to the DCM algorithm do need a velocity estimate for the acceleration compensation. However, GPS is accurate enough for the way the velocity is used.

When the velocity is small, the acceleration compensation is small anyway, so a velocity error has little impact.

When the velocity is large, the acceleration compensation works quite well, I have tested it out in my car while driving around a traffic circle.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Brian Wolfe on August 12, 2009 at 3:49pm

Hey Bill,
I still need to implement the acceleration compensation. It's next on my list. I just got all the stabalization/navigation code done last night for my Easy Star clone. I'm sure I'll need to tweek gains once I get in the air, but I think I have a good starting point. I have the pitch and heading commands coupled so as the aircraft rolls the pitch command will be performed by the rudder and the heading commands by the elevator. Should make for nice coordinated turns once the gains are set. Should even be able to do knife edges and the like. Right now the loops are type 0. I still need to add integrators to tighten things up but I wanted to start with minimum chance of instability.

I'm hoping to have things far enough along to get a run in for the DIY contest by the end of the month. Are you plannign on doing a run? Should be easy to hard code a series of waypoints and have a go.

I just used the car for initial testing. I've since switched over to a Tri Rotor and an Easy Star Clone. I do plan on going back to the car though. Just need more hours in the day.
Brian

• ▶ Reply

Permalink Reply by William Premerlani on August 12, 2009 at 4:02pm

Hi Brian,

Let me know if you need any help with centrifugal compensation. Its all about engineering units and conversions. I hate units and conversions.

Regarding flight feedback gains, I was able to get by just fine with proportional plus derivative only, no integral terms, for both MatrixNav and AileronAssist.

When I say "derivative", I am talking about applying the direction-cosine-matrix to transform the gyro signals to obtain rotation rate in the earth frame. For example, it is easy enough to compute the pitch rate perpendicular to the horizontal plane in the earth frame of reference.

I am not planning on doing a run for the DIY contest this year, I have too many irons in the fire right now.

Let me know if you find out where they are selling those extra hours in the day. I could use a few.

I am retired now, but there just does not seem to be enough time to do all the things I want to do.

Bill

• ▶ Reply

Permalink Reply by Elardus Erasmus on August 13, 2009 at 12:18am

Bill, Brian, many thanks for the replies.

I think I came across something which may be a bigger hurdle to overcome in a car than the low speed GPS one.

The RollPitchCorrectionPlane is computed as the cross product of the Zrow of the rotation matrix and Gref. That is good. But, Gref is the measured acceleration adjusted for centrifugal acceleration only. That is, Gref still has all the components of forward acceleration/deceleration and sideways (cornering) acceleration/deceleration.

Thus, Gref will be accurate enough during constant speed situations, but anywhere else (which is much of the time during driving, not so much during flying), the Gref vector will be skewed by the linear acceleration experienced at that time.

For example. Say we are driving down a simple straight and level road and slam on the brakes fairly hard. Gref during that period will be equal to the resultant of 1g gravity in the Z axis and ~0.7g deceleration in the X axis. I.e., quite a bit off of the true gravity vector. Resulting in a good deal of pitch/roll error. Looking at the pitch and roll angles during these situations, it would effectively look as if we are driving up and down small hills/ramps depending on whether we are accelerating or decelerating.

Maybe one can adjust Gref for any acceleration that may be experienced based the orientation of the car during that time, and feed that back through the PI controller. Though it seems like it would be using a bit of error (in the orientation at the time) to fix error (in the orientation at the next step). Not good.

It seems that the rapid and frequent acceleration typical of a car (compared to that of a plane) possibly makes it more difficult to achieve timeous and fair roll and pitch angle indication than in plane.

• ▶ Reply

Permalink Reply by William Premerlani on August 13, 2009 at 2:04pm

Elardus,

Actually, the accelerating and braking are not a problem, in practise, for a couple of reasons.

The main reason is that the drift compensation gains are low. So, you need a large drift compensation error for a long time to cause trouble.

Forward acceleration and braking are transient events. Their errors tend to cancel each other.

It is the area under the acceleration curve that causes trouble, which is the change in velocity. The compensation gains are low enough so that they do not respond to changes in velocity, because they are relatively small.

The main challenge is centrifugal effects, because they can continue for a long time, so the area under the curve is large.

If you are talking about very large changes in velocity, for example if you car is going to get up to 800 miles per hour, then the forward acceleration/deceleration needs to be taken into account.

That is easy to do from the GPS velocity, you can compute the forward acceleration by taking the derivative of the velocity. I have actually done that in some of the most recent versions of some of my firmware, and eventually will put it in all of my firmware, so the question will become moot.

There is a time lag between the actual acceleration and the GPS report, but the impact is negligible, since it is the total area under the curve that is important.

By the way, I have made some measurements: I have taken the roll-pitch-yaw demo out on the road, with the GPS forward acceleration computation, with a friend of mine who has Porsche. We subjected the board (and us) to some significant centrifugal acceleration, forward acceleration and braking, with negligible roll-pitch error.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Roy Brewer on August 13, 2009 at 10:05pm

Elardus, Bill,

I was thinking that the accelerometer should really be used as an inclinometer to offset gyro biases only if the net (resultant magnitude) acceleration is 1 G (with some tolerance for noise, etc.). This is a necessary but not sufficient condition. If the vehicle is not experiencing any actual acceleration, then the sensors will read (about) 1 G and can be used to detect the direction of gravity. It is still possible, however, that the vehicle is undergoing some acceleration and the net magnitude is one G, but I think that would be rare - especially for a ground vehicle.

I don't know how easy it would be to gracefully suppress the accelerometer input into the DCM algorithm while this condition is not met. From Bill's reply, it might not be necessary.

I designed a (simpler, linear) attitude complementary filter that has this magnitude check. I have not yet flown it on my quadrotor project (mainly because it isn't built yet :-), but other folks have used the code.

Also, if the vehicle is not an automobile and the dev board is part of the control system, then you could (in principle) compensate for the braking/acceleration via a feedforward path.

- Roy

Permalink Reply by Jeff on August 15, 2009 at 8:13am

Roy,

Your attitude complementary filter sounds interesting. Is there a discussion of it anywhere? Is your code available?

-Jeff

• ‹ Previous
• 1
• …
• 22
• 23
• 24
• 25
• 26
• …
• 58
• Next ›
• Page