Replies to This Discussion

Permalink Reply by William Premerlani on September 21, 2009 at 3:56pm

Justin,

It may be that the digital servos are more fussy than other servos, though I would be surprised, but live and learn.

I looked at the specs on your servo, I did finally notice that it said 20 msec +-2 msecs. I thought they were just kidding. Most servos will accept a much wider range than that.

So, I am a little bit skeptical, but it is worth a try.

Give me some time, I will put together a patch for you for the rollpitchyaw demo that will set the pulse rep rate to once every 20 msec, we will see if that works.

The only thing that it could possibly be is pulse polarity, but the spec sheet said positive pulses, so that should be ok.
Bill

• ▶ Reply

Permalink Reply by Justin on September 21, 2009 at 4:47pm

Hi Bill,

Re-programmed with PTPER set to 20000 but still zero movement on the Esky servos. They don't flicker or make any noise or do anything at all.

Justin

Permalink Reply by Justin on September 21, 2009 at 7:13pm

Ok,

Bill helped me get the issue with the servos worked out...although it was a rookie mistake of having the pins connected backward. =)

John,

Can you describe how you've connected your receiver to the 4th input channel? Bill mentioned that the code won't work unless it's receiving input on all 4 in a post above.

I've loaded up your v6 code on my green board. I have the 3 channels from the receiver that would normally go directly to the servos connected (properly this time) to channels 1, 2, and 3 of the dev board. It powers up but only the red light comes on, which indicates that the firmware thinks the receiver is off, according to Bill. Moving the receiver sticks doesn't move the servos at all.

Thanks!

Justin

• ▶ Reply

Permalink Reply by William Premerlani on September 21, 2009 at 7:33pm

Justin,

In the end, you figured it out for yourself. Good for you.

Regarding the 4th channel...not only is it used for the fail-safe function, it is used to switch back and forth between manual and stabilized mode.

As I am sure that John will tell you, during firmware development, there are going to be times when you want to switch back to manual mode. In a hurry. For John's heli firmware, the switch to manual takes place instantly, on command.

Another thing to be aware of when you are using the green board...although the green board has more sensitive, vibration resistant gyros than the red board does, the more sensitive gyros saturate at around 75 degrees per second. As John will tell you, a typical heli pilot will execute motions faster than that, so you will have to be careful. If you rotate faster than that, there will be a pitch and/or roll error that will take about a minute to dissipate.

The controls themselves will help you limit the pitch, and roll rate, with gyro rate feedback terms. Basically, in addition to the yaw gyro that helis typically have, the board will also give you roll and pitch gyros.

Best regards, and happy (and safe) flying.

Bill Premerlani

• ▶ Reply

Permalink Reply by John_Mac on September 21, 2009 at 9:45pm

Justin

I'm on the road right now, so forgive the delay.

I need to get you the most recent firmware version (I think I'm up to version 9 or 10 right now). It has all of Bill's additions to take care of things like, immediate return to manual control, a TILT parameter for both roll and pitch to account for the fact the heli does not fly with the mast perfectly vertical due to the tail rotor torques and forces.

As far as the mode control channel, I did not have a spare joystick or continuous control to pick the three states (auto, manual, RTL). All I had was a spare toggle switch. The code was modified to look for a short or long pulse for auto and manual and did not implement RTL at this stage. It will depend on your radio as to how you want to implement mode control, but the firmware may have to be modified.

I use HiTec digital servos and they work fine with the board.

You can message me with specific questions or post here and I will do my best to answer, but some may need me to be back home to check against the hardware. There are still many cautions to observe at this stage of development, but we have been able to establish a good stable hover with the Green Board. But it appears that the gyro rates on this board my not leave a lot of margin for rapid attitude changes. The consequences are dire and you need to be able to switch back to manual quickly if they occur. I will give you more info on this and other items such as gain settings etc.

Let me know just where you are in terms of implementing the Green board on your heli.

It can be rocky getting through the learning curve, but I'm sure Bill and I can help you get it going.

Best,
John

• ▶ Reply

Permalink Reply by Justin on September 22, 2009 at 9:13am

Hi John,

Thanks for the reply.

I think my biggest obstacle at this point is figuring out how to get all the necessary wiring hooked up. My first goal is to simply get it to the point where it's running your code and the servos respond to movements of the stick and movements of the dev board. At this point I have the servos disconnected from the swashplate so they don't bind against each other until the software is better configured. Not to worry...I plan to leave it firmly attached to my test stand for a while. =)

I suppose it will be helpful if I give you all the details of my setup:

My heli is an Esky Belt-CP 450 v2. It is CCPM with a flybar and I believe a full Hiller system. It has 3 linkages to the swashplate with 120 degree spacing. So I believe our heli's are very similar, although my swashplate linkages are oriented differently than yours (front, right-rear, and left-rear), but we can come to that later.

My Tx/Rx also is a 2.4GHz spread spectrum 6 channel system. My transmitter gives me the basic 4 controls plus a gyro gain adjustment and a toggle switch for "acrobatic mode". Acrobatic mode changes the throttle and pitch curves for inverted flying, which I plan to leave alone.

Here is how the Rx is hooked up to everything from the factory. There are 7 sets of 3 pins and the following is how it's enumerated on the Rx itself:

CH B -> Unused
CH 6 -> Swashplate - Right-rear
CH 5 -> Head Lock Gyro
CH 4 -> Head Lock Gyro -> Tail rotor servo
CH 3 -> ESC
CH 2 -> Swashplate - Front
CH 1 -> Swashplate - Left-rear

I understand from Bill that the code requires inputs on all 4 radio inputs on the dev board and that one of them should be for mode control.

One thing I don't understand is that since the swashplate control still goes through the dev board, "manual" mode control still depends on the firmware having some basic function, correct? It seems that if the firmware completely crashes, so does the heli, and there's really no way around that.

From reading about your setup, it sounds like I don't have the ability to switch to manual mode with a 6 Ch receiver. Assuming I want to try it without that capability for now, what modifications would we need to make to the firmware so that only 3 Rx inputs are required?

Thanks again!

Justin

• ▶ Reply

Permalink Reply by William Premerlani on September 22, 2009 at 9:45am

Justin,

You are correct, "manual" control goes through the dev board. For that reason, from the very beginning, we have been very careful to "bulletproof" that function, and we have never had a problem with it, or with the board ever "rebooting" in mid flight. There are several reasons why we have been able to achieve that:

1. Everything is interrupt driven with a separate interrupt vector for every interrupt source, with assignable priority to each source. So the firmware runs as a collection of many separate, independent modules. The interrupt handler that is critical to manual control is assigned the highest priority, so even if everything else were to crash and lock up, manual control would continue to operate.

2. Manual control is very simple.

3. We are very careful with the programming, particularly when manual control is involved.

4. We thoroughly test the firmware on the ground before even starting any test flights, and recommend the same approach for everyone else.

When I started out on this path 5 years ago, I did a lot of thinking about hardware versus software manual control. A significant portion of my work before I retired involved reliability calculations. It is my opinion that the software solution can be more reliable than a hardware solution, because, once you get the software debugged, it never "breaks" on its own. However, even with the best hardware design, a hardware component can just up and fail.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Marcus Fahlén on September 22, 2009 at 11:20am

Hi Bill.

I'm desperate to get my hands involved in this development now ;)
Any news about the board situation yet? Are SparkFun going to offer a "un-populated" board with regards to gyros? No chance whatsoever to locate any more "greenboards"?
Please let me know as soon as possible when there is an opportunity to obtain a working board, or a un-populated one with working components supplied as "kit" form.

Regards
/Marc

• ▶ Reply

Permalink Reply by William Premerlani on September 22, 2009 at 12:20pm

Marcus,

Sparkfun is not going to offer any "unpopulated" boards. I asked them, but they did not think it was a good idea. Perhaps if enough people called them and asked to buy an unpopulated board, they might reconsider it.

I have to believe there is a green board out there that someone would be willing to sell. In fact, I think there have already been one or two second-hand sales.

It would not hurt for you to start a discussion posting asking to buy a greenboard, there is nothing to lose.

Best regards,
Bill

• ▶ Reply

Permalink Reply by John_Mac on September 22, 2009 at 5:21pm

Justin

Still on the road, so sorry about delays....

You are correct that you need more than 6 channels to use the mode control. I am using a 7 channel system. I did do some development with a 6 channel Rx. In this case I had to hardwire the code to be either auto or manual. To change required recompiling and downloading to the board. This was OK for test stand dev, but would be a disaster for flying.

I haven't read all the threads yet, but if yu need the code for the hardwired mode control, let me know. Bill may have already done the mods for you. I see he has sent you the more recent versions...good.

Best,
John

• ▶ Reply

Permalink Reply by Justin on September 22, 2009 at 2:46pm

John/Bill,

I dug around in the code a little bit and saw the states.c file where control is passed between the 3 modes.

I hacked it up a bit so that it's looking for input on pwc2 (Ch. 3) instead of pwc1 (Ch. 4). I also re-connected everything so that it lines up with John's setup in the progress report.

This seemed to work pretty well. The green light stays on and pitch inputs from the transmitter are responded to mostly by the front servo and roll inputs mostly by the right and left rear servos.

However, the next problem is that the servos don't respond at all to the dev board deflections. Thinking this must mean it is in manual mode, I put some breakpoints in the states.c file as it was running. In the state_machine function it seems to reliably hit the 'else if' clause that is commented "Auto, stabilization mode".

Also, the interrupt handler in analog2digital.c seems to reliably run as well, which I believe is the handler for the gyro and accelerometer inputs, correct?

Is there something else that is causing it to ignore the gyros?

Getting closer....

Justin

• ▶ Reply

Permalink Reply by William Premerlani on September 22, 2009 at 3:09pm

Justin,

I have an idea to save some time.

First, I have attached the version of the heli firmware that I have, it is newer than what you have, and it is pretty close to what John has. I suggest that you use it as a starting point. So once we get you up and running, we will not have to go back and update what you have too much.

Then, I suggest that you revise it to reflect the changes that you have made, and send it back to me, I will take a look. It has only the source files, no project files, no linker script, and no library file. The ones that you have should be fine.

I think I know what is going on. In order to make a fast transition back to manual, there is more than one place that looks at channel 4. The states machine decides what state you are in, but it runs only once about every 1.5 seconds. In order to make a fast transition to manual, we also check channel 4 in the PWM computations. If channel 4 is not calling for automatic, there is an immediate override to manual. So, the controls can wind up in manual mode, even when the state machine is calling for automatic. Once we (John, you, and I) are done, we need someone like Ben Levitt to clean it up.

Best regards,
Bill

Attachments:

• Heliv6810WJP.zip, 25 KB

• ▶ Reply

• ‹ Previous
• 1
• …
• 6
• 7
• 8
• 9
• 10
• 11
• Next ›
• Page