RCAP board converted to altitude hold

[muc]

First I need to say that I didn’t add altitude hold to the RCAP2. I used the RCAP2 board and modified the software to convert the autopilot to a standalone altitude hold. I know that Walter is working on integrating altitude hold into the RCAP2 autopilot but I wanted to test this out anyway. I would prefer everything run on one board like Walter and probably everyone else envisions. I used the Zlog to provide altitude in 1ft resolution. The Zlog is connected directly to USART Tx/Rx pins of the Pic. The MAX232 is eliminated from the circuit. I probably won’t have time to test this in the air anytime soon so hopefully someone out there can and will report back. It would be great if someone could combine the code from the RCAP2 and this to run together. I’ll try to answer any questions. Attached are the code (PBP) picture. I'm still trying to figure out how to post a small video clip 150kb. I know the code can be cleaned up. There may be a few small mistakes but it worked on a hardware test today.

Mark

[muc]

short video clip here

http://media.putfile.com/alt-hold

[hihptsi]

short video clip here

http://media.putfile.com/alt-hold

i essentially did the same thing a couple days ago with my rcap it works good,we need to write some code for a 16bit adc and were set then we can either add to the rcap board or build a whole new OPENSOURCE board.interested in tackleing this with me mark?

[twinturbostang]

Why does the servo "snap" back to zero several times?

[muc]

Hihptsi,

I think Walter is already on this. http://www.rcgroups.com/forums/showpost.php?p=5165410&postcount=111 It looks like the code is already written and he’s been doing a few tests. I hope it works out because I’d like to see the RCAP2 have the altitude hold feature built in. I’m new to programming so maybe I’m wrong here but; the RCAP2 has to wait 2 seconds before updating, if you’re using a Geko. So that would limit your updates from any altitude sensor to the same delay. Is that right? This is why I can see the advantage of separate processor to handle the elevator and altitude corrections. Would 2 seconds be okay or is a faster update needed? The way I have the Zlog setup I’m getting updates every 100ms. It seems to be working pretty good. I’m just thinking out loud as I write so I hope this makes sense.

Twinturbostang,

Maybe it’s hard to tell in the video but the plastic cover is moving. The cover, with the RCAP2 and other components, is moving vertically ~2.5ft. So when I enabled the hold circuit with my spare channel it read and stored the current altitude. As the cover moves above and below the “zero point” the servo makes the necessary correction. The wire on the end of the servo is there to replicate the elevator. The amount of travel is adjustable.

[MX]

Cool!

[twinturbostang]

Hihptsi,
Maybe it’s hard to tell in the video but the plastic cover is moving. The cover, with the RCAP2 and other components, is moving vertically ~2.5ft. So when I enabled the hold circuit with my spare channel it read and stored the current altitude. As the cover moves above and below the “zero point” the servo makes the necessary correction. The wire on the end of the servo is there to replicate the elevator. The amount of travel is adjustable.

Yeah, I see it moving up and down. But what I don't understand is why the servo snaps back to zero several times during one steady motion in a particular direction. It seems like as you get farther and farther away from the set point, that the servo should deflect more and more to compensate (to a point of course). But what seems to happen is the servo deflects, then snaps back to zero, and then deflects again. I don't understand why it would do this. It looks sort of like a ratcheting motion.

[typicalaimster]

I don't understand why it would do this. It looks sort of like a ratcheting motion.

You can adjust the rate and how agressive the RCAP adjusts. It does ratchet a bit. These were the adjustments that I was toying with to get a smooth complete route.

BTW great job everyone working on the project!

[MX]

Yeah, I see it moving up and down. But what I don't understand is why the servo snaps back to zero several times during one steady motion in a particular direction. It seems like as you get farther and farther away from the set point, that the servo should deflect more and more to compensate (to a point of course). But what seems to happen is the servo deflects, then snaps back to zero, and then deflects again. I don't understand why it would do this. It looks sort of like a ratcheting motion.

He's only moving it up and down by one foot in either direction (the resolution of the altimeter), so that's why you only see it move one step. It is a pretty big step and would likely go out of control in a real plane, but this is probably just proof of concept. Real application should have some averaging and a hysteresis band and a much smaller gain.

MX

[muc]

Oh, okay I understand what you’re asking. I’m a little slow sometimes. Short answer, I passed through my “zero reference” point. The video starts at the reference point. Then as I move up I’m 1ft above my reference and the “elevator” pitches down bringing the plane down. As it reaches my reference point it centers the servo. I continue past the reference point and drop below it 1ft. The elevator pitches up bringing the plane back up to reference and the servo centers.

The program only looks for a reading above or below the reference point. If the plane is 1ft below reference or 10ft below reference it would move the elevator the same amount. The code can be changed but I just wanted to get something simple working first. My initial thought was to adjust the throw just enough so that a gradual incline or decline would be achieved. I set the throw in the video a little high so it would be easier to see. Any suggestions to improve performance are definitely welcome.

Does anyone know how the PDC-20 works? I don’t have one and I’m curious how it operates. Anyone want to sell one to me? 

[rclinks2002]

subscribe

[rclinks2002]

So for the altitude hold you used the streaming data from the GPS for altitude reporting? or did you incorporate a sensor?

[MX]

So for the altitude hold you used the streaming data from the GPS for altitude reporting? or did you incorporate a sensor?

It's not a GPS. He's using a ZLog altimeter: http://www.hexpertsystems.com/zlog

MX

[rclinks2002]

Mark,
So how do you program a reference point? Or does it log the altitude when you activate the rcap in flight and go off that? Thanks

Ben M

[muc]

Ben,

Sorry for the late reply. I'm working on the road for almost a month without much access to the web. When you activate the altitude hold with a spare RC channel it stores the current altitude and that's your reference. To change the reference - disable, move to desired altitude and enable again.

Mark

[ALtitudeap]

subscribe

[rclinks2002]

would a zlog mod 1 work for the conversion?

[MX]

would a zlog mod 1 work for the conversion?

muc bypassed the MAX232 level converter for his MOD3. You'd have to go through the MAX232 for MOD1, since MOD1 outputs RS-232 level signals.

MX

[d_wheel]

Are we not considering using GPS altitude data because it can be inaccurate, or because of the 2 second (1 second with some GPS receivers) being too slow for the control loop? Perhaps some other reason?

Later;

D.W.

[LukeZ]

Are we not considering using GPS altitude data because it can be inaccurate, or because of the 2 second (1 second with some GPS receivers) being too slow for the control loop? Perhaps some other reason?I'd say both reasons are show-stoppers, at least in as far as an altitude-hold circuit goes. "Holding" to a range of over 30 feet isn't much use, and even if you could get it to hold much closer, you're right, in the space of one second a plane could really get out of line, depending on how fast it was.

Just my thoughts... I can't think of any others why GPS is inferior - except also that maybe it's more fun to do it this way! ;)


Luke

[d_wheel]

""Holding" to a range of over 30 feet isn't much use"

Having experimented with autopilots in model aircraft, I have come to the conclusion that some of us (me included at first) are not being realistic in our expectations. Without spending thousands of dollars for equipment, holding track and altitude to within 50 feet is about as close as you can hope for in the real world. Remember, we aren't trying to auto land these things, but keep them on a track and altitude within a reasonable window.

At first, I had expectations of watching the model fly a nice straight line, exactly on track and altitude, making crisp turns at the way points and continuing to the next point in the same perfect pattern. None of the autopilots I have seen, either commercially available or the ones I have built, will keep the plane on a track closer than 50 feet left or right. Most of the commercial units consider arriving to within .1 miles (500’) of the way point as being right on target. Garmin autopilots (at least the one I have) use the same .1 mile arrival window. Some only control heading, not track so don't correct for wind drift. The commercial unit I own (over $800.00) waddles along hardly ever staying on a straight line between way points, and probably varies +/- 75’ in altitude while it’s doing it (it uses a pressure sensor for alt hold). Any more sensitive and it starts climbing and diving rapidly. It will get you there, but not in a pretty fashion. My RCAP actually does a better job of tracking. If RCAP would keep altitude to a +/-50’ error window it would be acceptable to me providing it keeps the complexity and weight of the system down.

As far as the timing between updates, I have found that a speed of around 30mph is just about perfect for aerial video. Much faster and the scenery passes by to quickly to be of much use for an aerial search, any slower and you can’t get much done during our limited flight times. At 30mph, we are traveling about 44 feet/second. A system that updates every 2 seconds would see us travel 88 feet between updates (the same distance we travel for tracking updates as well, I might add). Personally, I see no problem with this. We should be trimming for level flight before engaging the autopilot, so no major corrections should be necessary during the autonomous phase.

Just my humble opinion. What do others think?

Later;

D.W.

[LukeZ]

Having experimented with autopilots in model aircraft, I have come to the conclusion that some of us (me included at first) are not being realistic in our expectations. Without spending thousands of dollars for equipment, holding track and altitude to within 50 feet is about as close as you can hope for in the real world. Remember, we aren't trying to auto land these things, but keep them on a track and altitude within a reasonable window.Actually, I am building an altitude hold circuit at the present that has <1 foot resolution, and updates many times a second. So does the ZLog. That is not to say it will hold a person's plane to within 1 foot of a given altitude, since as you say one can also begin to experience porpoising issues. Some hysterisis will need to be built in to the system. But it should do much better than 30 feet anyways, let alone 50. You can see the board here (http://www.rcgroups.com/forums/showthread.php?t=372869&page=8&pp=15).


As far as the timing between updates, I have found that a speed of around 30mph is just about perfect for aerial video.That's fine, but not all of us are using UAVs for arial video. Some of our applications may require high speed, precision, steady track, etc...

A system that updates every 2 seconds would see us travel 88 feet between updates (the same distance we travel for tracking updates as well, I might add).It's true that a lot of GPSs update at only once every second or two. But consider anyone using thermopiles or one of the other sorts of attitude stabilization - they are all implementing attitude adjustments at much greater than 1hz. Position updates through GPS is one thing. But to fly anything but a quite stable aircraft requires some sort of input at greater than 1 second rate. Personally I consider pitch an essential part to flying, whereas geographical position through GPS is not so much.

Not to say that one can't fly an autonomous craft without pitch control, it's done all the time. Like you say, trim it out, use a stable airframe, etc... All I'm saying saying is, it's not viable for every approach. Some missions/platforms will just require more.

Anyways, I see your point, but I guess mine would be, let's try to make the most accurate/precise/effective device possible, given the constraints (budget, complexity, etc). If it's more than someone really needs, they're still no worse off. And for those who do need more, maybe it will work for them as well.

All the same this is an interesting conversation and I'd be curious to hear the other perspectives out there.


Luke

[kd7ost]

I agree with Luke. Also, the speed at which one films successfully will depend on other variables. Altitude and FOV are pretty big factors. Narrow FOV and low altitude don't mix well. But a real wide angle from up high can really give the illusion of slow movement even if you’re flying 60 mph.

I think technology speaking the altitude hold device should be BP driven with fairly high resolution. I think there will be a bigger window to fly in though to prevent porpoising. I do think whoeever comes up with it needs to ensure adjustable gain as well as proportional control in the software.

Dan

[d_wheel]

"Altitude and FOV are pretty big factors."

Exactly. You have to find the altitude that best suits your camera's FOV. With mine, it is about 200' and 20 - 25 mph. Narrower FOV and you have to go higher losing detail. Wide angle yields "fish eye" video which is difficult to watch for very long.

Can someone please let me know what programmer I need to do some experimenting with the RCAP program? There are several bundles available at http://www.melabs.com/products/bundles.htm but I don't know for sure which one I need. I would like to experiment with GPS based altitude hold and various types of wing levelers.

Later;

D.W.

[radiohound]

Can someone please let me know what programmer I need to do some experimenting with the RCAP program? There are several bundles available at http://www.melabs.com/products/bundles.htm but I don't know for sure which one I need. I would like to experiment with GPS based altitude hold and various types of wing levelers.
D.W.

If you have a bootloader version chip, you will not need a programmer. You will only need PicBasic Pro to compile code for the RCAP or RCAP2. The bootloader allows you to put new programs into the PIC via the serial port.

The MicroCode Studio Plus is also very handy, and will run with the RCAP and RCAP2 hardware. It allows you to view the steps the program is taking via the serial port. (just cant have the GPS plugged in while debugging).

[d_wheel]

Whoops! Didn't plan on spending that much on a compiler.. Might try it with Basic Stamp since I already have all of the equipment necessary.

Later;

D.W.

[CrashingDutchman]

The Basic stamp is different processor. This won't work with the RCAP2 board since this board is using a PIC chip from MELabs.

There are a couple of free PIC Basic compilers available, but the ones I have tried work different from the PICBasic Pro compiler. Maybe someone else knows more about this.

CD

[d_wheel]

"The Basic stamp is different processor."

You can say that again! I have been using the basic stamp for a while now, and really enjoy coming up with new projects for it. One of my autopilots uses the bs as it's processor. It works fairly well but I would like to help with the rcap project if possible since it is a good basic autopilot, has a good group of programmers and users, and only needs a few more features to make it even better. I plan to experiment with gps based altitude control with the bs while still using rcap or one of my other autopilots for guidance. If it works out, it would be nice to incorporate it all on the rcap because that would keep the size, parts count, weight, and complexity down.

Later;

D.W.

[eladiomf]

The Zlog is connected directly to USART Tx/Rx pins of the Pic. The MAX232 is eliminated from the circuit.

Mark

How did you connect the Zlog to the RCAP altitudehold board? Zlog is only 3V TTL and you need 4.0V for the RCAP PIC.

In another thread "Standalone Waypoint Sequencer" , post 331, MR. RC-Cam said:

"But with the direct connect scheme, the WPS outputs 3V TTL logic on its serial data line. This is not fully compatible with the RCAP PIC's schmitt trigger conditioned serial input (4.0V min is required). It is a borderline situation and reliability may be problematic if the 3V TTL is not level converted to 5V TTL."

I think the Zlog also output 3V TTL, is the same board that the WPS.

Eladiomf

[MX]

For the record, ZLog (and WPS) output 3.3v.

MX

[kd7ost]

How did you connect the Zlog to the RCAP altitudehold board? Zlog is only 3V TTL and you need 4.0V for the RCAP PIC.

In another thread "Standalone Waypoint Sequencer" , post 331, MR. RC-Cam said:

"But with the direct connect scheme, the WPS outputs 3V TTL logic on its serial data line. This is not fully compatible with the RCAP PIC's schmitt trigger conditioned serial input (4.0V min is required). It is a borderline situation and reliability may be problematic if the 3V TTL is not level converted to 5V TTL."

I think the Zlog also output 3V TTL, is the same board that the WPS.

Eladiomf

In the simplest form, you could use a Servo, buffer/amp whatever it is called. The unit operates to keep your pulses square and clean on long leads. It reshapes them to nice square waves. A by product though (if they used a CD4049 chip) is that the chip will also ensure the outgoing pulse is the same amplitude as the VCC to the chip. If you're using 4.8 vdc pack to power things, the pulse to the buffer will be the 3 vdc from the WPS but will leave the chip at 4.8 volts to the RCAP. This will meet the RCAP PIC requirements.

You could also use optical isolation and dual battery supplies but that's bigger and heavier solution.

Dan