Replies to This Discussion

Permalink Reply by Daniel Gru on November 6, 2011 at 4:09pm

I think "actual height" is a good thing for RTL.
So you are flying at a special height, it keeps that height and heads home.

If something goes wrong and you are behind trees etc, you hit full throttle to get it up, then enable RTL.

I wouldn't want to control height, after the RTL Switch has been hit.

And i don't like the thought of having set a RTL-Height 5 days beforehand at the computer, when i didn't know how the flight-field would be... so i prefer the actual height.

Only thing you could do, is for "Failsafe-RTL" Make a predefined height in the Mission planner, so it firstly always goes to say 100m and then heads home, when it looses signal, so it will clear any obstacles in its way!

Daniel

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on November 6, 2011 at 4:22pm

 

Actually there is no specific failsafe mode available for Arducopter.

 

So the best is to program the receiver to trig RTL mode as the failsafe mode. But it will be the same RTL as a manually trigered one.

 

 

• ▶ Reply

Permalink Reply by Gordon on November 9, 2011 at 2:50pm

First up, thanks for all the great work.

 

Now on the RTL issue. Would it be possible to either;

a) make a dedicated copter ppm code for the 328; or

b) a dual purpose ppm code.

 

This could then allow the main copter code to use the ch8 input to be able to distinguish between switched RTL or failsafe RTL. Either way, the ppm code should check to see if plane or copter main code is loaded on boot to either detect a mismatch or select the correct mode for the ppm processor.

 

Ch8 could then be used in the following fashion. Have ch8 on a 2 pos switch. Set the ch 8 receiver failsafe to the lowest possible value including trim. Then for normal use have trim re-centered, so no accidental failsafe in normal use.

Read ch 8 before arming and store value.

a) If ch8 high, use scripted RTL.

b) If ch8 low, use standard RTL.

 

Then if the failsafe position of ch8 is detected, the copter comes home in the way selected. Also include the choice as an option in the planner for those who don't have a spare switch.

 

Just throwing it out there.

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on November 9, 2011 at 3:23pm

 

I think that would not be possible because Ch8 is dedicated to Arduplane radio passthrough mode. For simplicity, ppm encoder code needs to stay the same for Arducopter and Arduplane.

 

It would be simpler to use throttle failsafe, on Ch3 like in Arduplane. Throttle failsafe does use a low value on this channel to indicate for a failsafe position.

 

This is not implemented actually for Arducopter.

 

http://code.google.com/p/ardupilot/wiki/RadioSetup

 

 

• ▶ Reply

Permalink Reply by Gordon on November 9, 2011 at 3:53pm

That's exactly why I suggest the dual purpose ppm encoder that can check the main code to see which mode of operation it should use, because ch8 is currently a wasted channel for copter users.

 

It would be great to free up ch8 for copter users but maintain it's function in ArduPlane.

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on November 9, 2011 at 4:10pm

 

The link between the ppm encoder and main AVR chip is actually a unidirectionnal link. There is only one wire between them. It would be a bit complicated to design a reliable bidirectionnal link (bit banging).

 

We discussed about this in the ppm encoder team and we decided to leave it like this in the newer ArduPPM firmware for two reasons : reliability and code testing.

Implementing this in the PPM firmware would have asked a long test period to be sure that no glitch could cause user trouble.

 

A better solution is to use a receiver with a PPM sum output, so you can have from 8 to 16 channels with only one wire.

Actually this is implemented in the ArduPPM firmware, compatible with APM and PhoneDrone boards. I'm not sure for 16 channels PPM sum, but 8 channels is working without trouble. 16 channels support is only dependant from the RC library for the main AVR.

 

• ▶ Reply

Permalink Reply by I.S. on November 9, 2011 at 4:14pm

Could you explain how to do this further please?

• ▶ Reply

Permalink Reply by Gordon on November 9, 2011 at 5:08pm

Olivier - Ok, thanks for the explanation on the hardware limitation. So the ppm encoder can't talk to the 1280, just check if it has crashed. Maybe on a future hardware design. It's still impressive what the team has been able to achieve.

So throttle failsafe would need to be implemented in arducopter as you suggested, in order to distinguish RTL and failsafe RTL.

Would still be good to have the choice via planner to have fixed/last height RTL and scripted RTL.

It's a pity most of the brand name manufacturers don't provide ppm out yet without moving to one of the LRS modules.

• ▶ Reply

DeveloperPermalink Reply by jasonshort on November 9, 2011 at 5:10pm

PPM output is easy for a futaba radio.

http://pixhawk.ethz.ch/wiki/tutorials/receiver_sum_signal

DeveloperPermalink Reply by Olivier ADLER on November 9, 2011 at 6:11pm

 

Some manufacturers, like Jeti in Europe, do have a very light and unexpensive PPM output receiver. This is very nice for our use.

 

A lot of older FM receivers do have the PPM signal available internaly, this is often a simple modification. Google on it.

 

So you don't need expensive LRS to get PPM outputs.

 

DeveloperPermalink Reply by Olivier ADLER on November 9, 2011 at 5:35pm

 

The simpler is to replace the ppm encoder firmware by the ArduPPM version, and put it in PPM passthrough mode (read the manual to know how to do this).

 

You'll need an ISP programming cable to do this and some basic knowledge to use it.

If you are not sure, don't try it, there are some risks to brick your ppm encoder chip.

 

After firmware update you'll connect your receiver PPM ouput on the ppm encoder Ch1.

 

I tested it with a Jeti PPM receiver set in 8 CH output mode.

 

The ArduPPM firmware manual :

 

http://code.google.com/p/ardupilot-mega/source/browse/Tools/ArduPPM...

 

The other solution, is to cut the ppm encoder output track, and connect your receiver directly to the main AVR chip ppm input.

 

• ▶ Reply

Permalink Reply by Alex on November 8, 2011 at 9:18am

Another day, another problem. I've added a sonar (Maxbotix LV EZ0- http://www.maxbotix.com/documents/MB1000_Datasheet.pdf) to my hexa and i connected it like this :

 

The problem is that when i activate Loiter mode under 10m aprox the copter is slowly descending. If i activate Loiter mode above 10m it is holding the altitude. The sonar is activated in MP. I've made some tests indoor (play with my hand in front of the sonar) and it seems that is is working. What could be the cause ?  Also i've loaded the log file in MP, it seems that the baro and sonar values are reversed....?!?! I did not find the throttle out value to put it on the log graph?!!? Here is the log file http://dl.transfer.ro/transfer_ro-08nov-be1343d4c1c.zip  . Any kind of help is appreciated.

• ▶ Reply

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