355 replies to this topic

[Arthur P.]

-AT-Mr Cam-Man, Very nice little PCB. And interesting solution to the failsafe issue. I-ve been thinking about the latter as well. I think I would rather see that solved in the FC firmware as almost all MK's have an airpressure sensor, all have gyro's and accelerometers, and then some have compass and GPS. The changes needed to the firmware, from a logical perspective, would probably have to do the following:

on first throttle up over x% get airpressure value as zero altitude value (could be a handstart, but we can correct for that) and set flightflag
if no ppm signal (receiver without failsafe) or if no change in ppm signal for x seconds (receiver must be in failsafe mode) then
if flightflag then
if altitude close to or below zero, motors on, and sensors indicate movement cut throttle to 20% (controled drop for the last couple of cm)
if altitude close to or below zero, motors on, and sensors indicate no significant movement, turn motors off and set flightflag to NO (avoids any throttle activity until there is signal again)
if altitude >> zero, motors on, and sensors indicate movement, reduce throttle and check decent rate for adjusting throttle to reach predetermined decent rate until altitude close to or below zero
if alttude >> zero, motors on, and sensors incidate little or no movement, then we must have landed on a roof or in a tree or something, so just cut the throttle and turn flightflag to NO.

In case there was a GPS reciever this would become more complex as you could then have the option of return to takeoff point (and hopefully ability to define a safe altitude at which to fly backto takeoff (you don't want it to come in at 5m if you're in between 20 meter trees), or maybe even to the nearest predefined safe landing point.

[Mr.RC-Cam]

Jim was kind enough to make several of his PCBs for the v2 PWM2PPM converter for me.

Is this V2 the same V2 circuit that evolved here, or something else? If it is something else, can you offer a link to Jim's (?) project?

... interesting solution to the failsafe issue. I've been thinking about the latter as well. I think I would rather see that solved in the FC firmware as almost all MK's have an airpressure sensor, all have gyro's and accelerometers, and then some have compass and GPS.

Just about every problem has several opportunity solutions. I'm just trying to solve this one with some simple technology I can nail down with the e-hammers I have on the tool bench. First one to the finish line gets the beer.

[brashley]

Is this V2 the same V2 circuit that evolved here, or something else? If it is something else, can you offer a link to Jim's (?) project?

I think its a typo, he meant Richard (aka brashley)


Richard

[Mr.RC-Cam]

I think its a typo, he meant Richard (aka brashley)

Oh, that Jim.

[Arthur P.]

I think its a typo, he meant Richard (aka brashley)


Richard

Sorry about that Richard. It was indeed late, and it indeed concerns your v.2. PCB. I-ve corrected it in my post above (but can't correct the quotes which still call you Jim).

[Arthur P.]

Well today was "the" big day, the first outdoor testflights. Conditions were "near perfect": 8 degrees Centigrade, heavy overcast, and winds gusting to 45km/h (about 30 mph) But in view of the good stability the machines had shown during some indoor handheld testing, I decided to just go ahead. Of course all did not go completely as planned. APMk (Aerial Photography Multikopter, but also a jab at my initials APM) nr 1 had a wrong and incompletely charged battery, so only several short hops, but still it managed the wind quite well, immediately hanging into it as soon as it got light on its feet.

APMk nr 2 had a bit of a thump after the first hop due to my twitchiness on the controls and "lost a leg". But on a bit of a little slope it was stable enough on the remaining 3 to still do some more and increasingly long "hops", even going up to about 10 meters. And with a bit more weight, even more capable of handling the gusting winds. Really amazing.

Only APMk nr 3 didn't make it into the air as motor nr 1 wouldn't start for some reason.

All three have the Spektrum AR7000 on board, with the PWM2PPM v.2 converters. Work excellently !!! Thank you !!


More pics and details here:
http://forum.mikroko...pic-1023-2.html
and here:
http://www.rcgroups....121#post9312892

Attached Thumbnails

• 

Edited by Arthur P., 08 March 2008 - 12:34 PM.

[Terry]

WOW ! looks like an alien invasion....

Cant wait for the AP tests

Terry

[Mr.RC-Cam]

You've got three of them! That's insane, but in a good way.

It's great to hear that the AR7000 PPM V2 interface is working well. I expect to spend some time next week to finish up the failsafe equipped version. The code to detect the AR7000 failsafe is written (detects exaggerated low throttle), so it's almost a done deal. Or so I hope.

osvaldoljunior: did the Quadrocopter folks ever come through with a AR7000 fix? That is, did they reorder the channels for it?

[Arthur P.]

You've got three of them! That's insane, but in a good way.

It's great to hear that the AR7000 PPM V2 interface is working well. I expect to spend some time next week to finish up the failsafe equipped version. The code to detect the AR7000 failsafe is written (detects exaggerated low throttle), so it's almost a done deal. Or so I hope.

osvaldoljunior: did the Quadrocopter folks ever come through with a AR7000 fix? That is, did they reorder the channels for it?

Actually I have the FC ready and the parts all lined up for APMk nr 4. Got stuck with an additional one on a group order. I-m going to use that one as "experimental", i.e. for testing different frame improvements, new firmware, etc. Motors for that one initially will be Turnigy 2830 - 1050kV, so it will be a "lightweight", but may get 4 more and go for an octocopter on that testbed ;=))

The ESC on motor 1 of the heavy APMk nr 3 has me stumped. All connections are intact. The motor arms correctly with the nice Quax tones. But it isn't responding to I2C/TWI throttle commands at all. I-m considering trying to reprogram it (maybe it lost it's address??), or just convert a next TowerPro 25A ESC, and only then reprogram this failing one as a "spare".

[brashley]

Great to hear about your success Arthur, amazing they hold up to that kind of wind. WOW!!!.

If I get the chance, I will try the failsafe beta tomorrow and will report back. Hopefully I will get enough time to 'hack' it in and test it out.

Richard

Edited by brashley, 08 March 2008 - 08:19 PM.

[brashley]

AR7000 PWM-to-PPM failsafe beta test:

RC-Cam provided a HEX file for a PIC (12F509) that detects either a low or high exaggerated throttle pulse width (position) and then provides a low or high signal that can be used to signify a lost signal state. The process goes like this;

1) set your throttle low throw to 150%
2) bind your receiver to the TX (this sets the lost signal throttle to the low 150% value)
3) once the binding is done, reset the throttle throw to the standard 100%
4) add the PIC to the converter and hook up the Failsafe Low Output to the two CLR inputs of the HC221 (PIC pin 3, HC221 pins 3&11)
5) hook up the throttle to the PIC (pin 7)
6) add a LED to the failsafe high if you want (pin 6) [with appropriate resistor of course RC_Cam recommended a 220 ohm series resistor for std bright LED]
7) Hook up power and GND (pin 1, pin 8)
8) Add .1uF cap across V+ and GND on the PIC (needed for the PICs internal oscillator stability)

When the signal is lost, the AR7000 sets the throttle to the preset bound position (very short PWM signal) and the PIC detects this low state and then switches off the HC221s output shutting off the PPM out. Turn the TX back on and the throttle jumps to a normal range and the PIC turns the HC221 output back on and the PPM is live again.

I tested it with the MK as well and the MK started beeping (lost signal state) as soon as the PPM goes silent . On-Off-On-Off no problem. There is a second or two delay though (AR7000 obviously does not go into failsafe mode instantaneously, nor does the PIC code)

RC-Cam also added some changeable offsets (for high/low PWM threshold settings) that would allow some one to tweak the failsafe threshold detect levels but I did not find I needed to do that

I hacked it into my V2 board (I have been using my V1 [MK still not flying] and had not yet cabled my V2 one up so this gave me the motivation to go ahead and finish it up). I simply glued the programmed PIC on the PCB and white wired up the rest (RC_Cam suggested bending the CLR pins up on the HC221 to disconnect them from the rest of circuit and that worked great)

Richard

The Converter with PIC hacked in:

TX On Scope picture:

TX Off Scope picture:

Edited by brashley, 10 March 2008 - 08:34 PM.

[Mr.RC-Cam]

brashley, that is great news. It's Miller time!

Attached are the V3 firmware files and revised schematic. The microcontroller is a Microchip PIC12F509, which is a Flash part and can be reprogrammed. Just don't change the factory calibrated OSCCAL value when you erase or program it.

If you cannot find the PIC12F509, then you can use the one-time-programmable PIC12C509 or 509A.


.

Attached Thumbnails

• 

Attached Files

•  DXfs1_0.zip   6.29K   392 downloads

Edited by Mr.RC-Cam, 08 December 2008 - 06:45 PM.
Fixed schematic

[brashley]

For those who are actually paying attention, I mentioned that the PIC output gets hooked up the HC221 CLR Pins 3 & 10. That was incorrect ; it was actually Pins 3 & 11 (I will change my earlier post). Looking at the Function table for the HC221, the end result is about the same (I will get one extra pulse on the rising edge of the B input but other than that it is the same) I soldered it to the wrong pin and then documented what I soldered. You may also notice from the picture above that I did not have the cap in between V+ and GND, I have also now added that as well. I also now tacked down the white wires with a dab of glue to hold them in place. A new picture is included in this post

Richard

Updated Picture of Converter:

Edited by brashley, 10 March 2008 - 08:46 PM.

[LabMaster]

After a lot of work to do i finally found time to go further with my own Spektrum RX PPM solution.

My solution is a Microcontroller (to not overwrite the original chip) or Firmware replacement (the isp pins are available on the AR7000 PCB) for the Spektrum AR7000 with a lot of extended features compared to the original AR7000.
The main features are, PPM Sum. Output on the BAT connector, support for a second satelite receiver (3 receivers at all), configuration for "hold only", "failsafe after hold" and "no failsave at all", the last one is important for the MK to use their own failsafe and LMA features. Configuration is simply done by putting the bind jumper onto different Channel pins or the Bat connector for entering binding.

In the meantime i've also done a own small PCB for it to not always break up the AR7000 case when in need for a RX. My own PCB is fully Controller pin compatible with the AR7000 PCB but striped down the one single output (AR7000 Bat connector) where the PPM sum Signal is present.

Here is a picture of my own receiver Board: (simple one side PCB version)
http://www.chiptech....ub/IMGP0699.JPG

here with the satelites connected:
http://www.chiptech....ub/IMGP0698.JPG

And here is a Video where you can see the receiver board in operation including binding process and so on.
http://www.chiptech....ub/IMGP0697.AVI (Attention about 70Mbyte Video File)

A blue LEDs is signaling the Satelite receiver states, by showing how many expected receivers are delivering valid datas.
How many and what receiver is expected depens how many and what receiver where present with valid datas during the binding process.


At the moment i'am implementing the possibility to be able to connect the "Spektrum information display" to show lost frames and fadings betweend the receivers.
Also i've already investigatet the signals and different behaviour when using AR9000 with DX7 and using AR7000 with DM8 and DM7, so i can say that it is possible to get up to 9 channels output on PPM Sum. line when using DM9 or at least 8 when using DM8. Not easy but possible.


Best regards,
Walter

Edited by LabMaster, 11 March 2008 - 05:35 AM.

[Mr.RC-Cam]

LabMaster, that is excellent. Hopefully you can dedicate a thread to it and share the design for DiY builders.

[Arthur P.]

Very ingenous and very impressive Richard and Mr Cam-Man !! Actually, I believe the 2 second delay is in part due to the FC settings. At least in v0.68d the default delay in the MKTool is 20x 0.1 seconds

I converted 8 new TowerPro 25A/2's on Sunday afternoon, am back to just quickly soldering the programming wires to the right legs and then removing them. Those are actually so easy, that it takes about as long as the multiple attempts needed to position the clay programming adapter. Overall time for conversions is down to about 45 minutes per ESC from starting to put on the battery connnectors to finishing up the new heat-shrink with in between connecting the programming wires, reprogramming for the correct motor, removing the porgramming wires, drilling through the existing incorrect route, checking correct resistance, rerouting one port, rechecking correct resistances, making an 3-wire TWI servotype connector, going from servo wire to wire-wrap wire with heatshrink isolation, connecting the SDA/SCL/GND lines, shortening the normal PWM connector wires so that the plug can still be used to power LEDs off of the BEC, testing the ESC over the TWI interface, putting a few dabs of epoxy over the new connections to fixate and isolate them, heat-shrinking the ESC back up, and retesting one final time. Not bad, looking at the number of steps

I also modified the landing gear on all three APMk's by putting 3 6mm carbon rod braces horizontally between the legs about 5cm off the ground (along the sides and behind the camera, putting on carbon 6mm carbon rod "skids" on the bottom of the legs, and wrapping "pool-noodle" type pipe isolation around the skids with the rear 15cm coloured red with marker pen. Connections are made from 6cm pieces of 8mm plastic tubing with a small hole cut in the side halfway in the length (just bend the tube back on itsself and cut off a small corner). Adds just a few grams and has tremendously stiffened the landing gear with better distribution of forces over all four legs. I-ve testdropped the heavy APMk 3 (about 2 kg with battery) on the landing gear from about 20cm, no problem. And I think the skids with the rear 15 cms being red, will help with orientation.

I also modified the camera mounts by putting a little block of wood below the gimbal ring so that it only swivels sideways. The FC can control the tilt correction very nicely, so no need to have gravity do that. On less axis of free uncontroled swinging

Edited by Arthur P., 11 March 2008 - 12:09 PM.

[Mr.RC-Cam]

In case it matters:

The PIC includes some debouncing code before entering or exiting the failsafe state. It is about one second and is suppose to be a feature rather than a bad thing. But you know, one man's software feature is anothers bug, as I was recently reminded while customizing some PanCam project firmware.

The debouncing was included because the PIC may find uses in other applications, including legacy PPM Rx installations. Basically, I'm just trying to get more mileage out of the coding efforts. Long story short, the PIC's failsafe analysis adds to the existing AR7000 and the MK failsafe detection delays.

[Arthur P.]

-AT-Labmaster,

That replacement receiver is really impressive !! Certainly deserves a separate thread ! Btw, where do you order your satelite receivers from?

[brashley]

where do you order your satelite receivers from?

You can get them form Horizon Hobby http://www.horizonho...?ProdID=SPM9545

They also have extensions for the receivers
http://www.horizonho...?ProdID=SPM9012

Richard

[Mr.RC-Cam]

I finally had a chance to test my V3 Spektrum PPM board today. I don't have a DX7 or MK, so I simulated it all with a DX6 and a o-scope. Everything worked according to plan, including the failsafe feature. Success!

FWIW, the failsafe decoder on this version is a PIC10F series microcontroller. These are packaged in a tiny SOT-23 size SMD body. Below is a photo of the bottom side of the PCB where the PIC is located. To help appreciate its tiny size, the nearby components are 0805. That's one small microcontroller!

Attached Thumbnails

•