HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Apr 28, 2009, 06:33 PM
Registered User
Redwood City, CA
Joined Mar 2009
58 Posts
Quote:
Originally Posted by Moa

Scenario 1
The plane is being flown manually and experiences a burst of interference or flies out of range. The receiver goes fail-safe (lets say it defaults all channels except MODE which AUTO2s). The paparazzi is in control.
Then the interference goes away or the plane comes back into range and the receiver comes out of fail-safe.
The setting of the MODE switch will likely be MANUAL still so you are given back control without knowing it. Paparazzi didn't care because it believes you were in control requesting AUTO2 at that time and now you want MANUAL. I can see instances where this would not be desirable especially if paparazzi has been in control for a while.

For this scenario I feel that there must be some logic to the MODE switching that acknowledges who has control.
Warren
Warren,

This scenario is scary. The returning of manual mode from Auto2 caused by fail-safe situation may indeed make many pilots unprepared and thus cause crashes. I wonder that the logic or intelligence may be implemented in Paparazzi's codes. At least in Paparazzi, it knows when the signal is lost and can use sound in GCS to alarm the pilot that it has entered Auto2 mode because of the Radio Signal was lost. Then it can prompt the pilot to confirm whether or not to regain
the manual mode once the signal is back again (with a default value as 'no').


Quote:
Originally Posted by Moa
Chris
I agree. I feel if you leave in the other option of "fail-safe to default values and go AUTO2" it will come back and bite someone! It will take a lot of writing in the manual to explain the danger I mentioned. So I vote for not making it available.
Warren
Warren
Warren and Chris,

I liked the option of being to go to Auto2 mode with the fail-safe values. If it is explained in the user manual, the users have the responsibilities if they choose that option. The current default mode is good for many users, but some users are more adventurous. With that Auto2 mode in the ppm encoder board, some users in the future will eventually be able to modify the Paparazzi codes to make it safe under these new scenarios.
SteveRoss is offline Find More Posts by SteveRoss
Last edited by SteveRoss; Apr 28, 2009 at 06:43 PM.
Reply With Quote
Sign up now
to remove ads between posts
Old Apr 28, 2009, 07:26 PM
Moa
Registered User
NewZealand
Joined Feb 2004
23 Posts
Quote:
Originally Posted by SteveRoss
Warren and Chris,

I liked the option of being to go to Auto2 mode with the fail-safe values. If it is explained in the user manual, the users have the responsibilities if they choose that option. The current default mode is good for many users, but some users are more adventurous. With that Auto2 mode in the ppm encoder board, some users in the future will eventually be able to modify the Paparazzi codes to make it safe under these new scenarios.
Steve
Unfortunately no modification to Paparazzi code can get around this issue if the ppm encoder is configured as the AUTO2 option. Without Chris (or others later) making the modification I suggested then it is not good practice to leave it available. The best approach going forward is to have the ppm encoder work in its default mode where it drops the ppm signal, just like Chris mentioned this replicates all simple ppm RX behaviours. All the effort recently has been to enable PCM receivers to attach to Paparazzi, that's the plus. In the future, assuming it cannot be done now is for Paparazzi to make the code change that provides the option of AUTO2 instead of going HOME. That's where the change should happen.

Anyone
Could someone explain to me why they want signal loss to induce AUTO2 and not bring the plane back in range with HOME? I can't think of a mission that could need this, other than the fun of giving it a go.
Warren
Moa is offline Find More Posts by Moa
Reply With Quote
Old Apr 28, 2009, 07:55 PM
Registered User
Redwood City, CA
Joined Mar 2009
58 Posts
Quote:
Originally Posted by Moa
Steve
Unfortunately no modification to Paparazzi code can get around this issue if the ppm encoder is configured as the AUTO2 option.

Warren
Warren,

I don't understand why you think that way. Could you please provide rationale and reasoning behind your statements? There are many problems which don't have solutions yet today in science or engineering, but that doesn't mean they will be unsolvable forever.
SteveRoss is offline Find More Posts by SteveRoss
Reply With Quote
Old Apr 28, 2009, 09:09 PM
Moa
Registered User
NewZealand
Joined Feb 2004
23 Posts
Quote:
Originally Posted by SteveRoss
Warren,

I don't understand why you think that way. Could you please provide rationale and reasoning behind your statements? There are many problems which don't have solutions yet today in science or engineering, but that doesn't mean they will be unsolvable forever.
Steve
Using the option where upon fail-safe all servo outputs default to compile time values and the MODE channel goes to an AUTO2 value.

As Paparazzi sees it, it cannot tell if you commanded the AUTO2 or it was induced by loss of signal. Only if it can tell the difference can Paparazzi code react differently. The two different triggers are hidden by the presence of the ppm encoder and the Paparazzi only sees one type of condition so can only be programmed to act one way. It sees the MODE channel change and does not know about a loss of signal. The servo pulses are all legitimate so all it can do is run code that does one fixed action, in this case set the mode. PPM encoder knows that the signal was lost but not Paparazzi so the safety requirements that we deduce are needed if signal loss occurs, need to be applied where signal loss can be monitored and that is at the ppm encoder. I hope that clarifies my thinking.
Warren
Moa is offline Find More Posts by Moa
Reply With Quote
Old Apr 28, 2009, 11:35 PM
Registered User
Redwood City, CA
Joined Mar 2009
58 Posts
Quote:
Originally Posted by Moa
Steve
As Paparazzi sees it, it cannot tell if you commanded the AUTO2 or it was induced by loss of signal.
Warren
Warren and Chris,

I now understand Warren's points. I wonder if it is possible for the ppm encoder to do something as follows when the transmitter signal is lost to make the Paparazzi known that it is a slightly different Auto2 mode. When the Tx signal is lost, the ppm encoder shuts off the ppm output or transmits certain patterns (e.g. minimum pulse widths for all channels) for a very short time period . After that, ppm encoder will transmit the fail-safe values to enter the Auto2 mode. In Paparazzi's codes, it will detect such short period of silence or short period of special patterns (with proper codes modification), then make the decision which condition the Auto2 is entered.

In this way, the Paparazzi will know the Auto2 is entered in which condition, and the later unintended returning to Manual mode can be handled safely.

The default mode of the newest version (4.0) of firmware from Chris will hide the more complex setup procedure from most users thus will not bring inconvenience or any harms to the existing system. If the bootloader code is well performed, the updates of the firmware will be easy for most users using FTDI cable.
SteveRoss is offline Find More Posts by SteveRoss
Last edited by SteveRoss; May 01, 2009 at 11:41 PM.
Reply With Quote
Old Apr 29, 2009, 01:35 AM
Registered User
Greece, Attica, Piraeus
Joined Jun 2004
1,133 Posts
Quote:
(Chris, I tested the FTDI cable and cutecom after updated the firmware to Ver 3.9, still have problems on the bootloader though, I cannot even see (ATH for Help)> prompt after power cycle).
Did you flashed the servo2ppm+bootloader.hex of the posted 3.9 version?
Do not flash the servo2ppm_v3_9.hex but the servo2ppm+bootloader.hex file.
The servo2ppm_v3_9.hex file contains only the ppm encoder code but not the bootloader.
If you find some time try it and let me know.
It is better if an independent source tests it.
Chris
hendrix is offline Find More Posts by hendrix
Reply With Quote
Old Apr 29, 2009, 03:18 AM
Registered User
Redwood City, CA
Joined Mar 2009
58 Posts
Quote:
Originally Posted by hendrix
Did you flashed the servo2ppm+bootloader.hex of the posted 3.9 version?
Do not flash the servo2ppm_v3_9.hex but the servo2ppm+bootloader.hex file.
The servo2ppm_v3_9.hex file contains only the ppm encoder code but not the bootloader.
If you find some time try it and let me know.
It is better if an independent source tests it.
Chris

Chris,

I think in Ver 3.9, I've flashed in the servo2ppm+bootloader.hex. I can see that the LED blink in a much higher frequency after it is on, but did not even see the (ATH for Help)> prompt after I power cycling it on J1 when I used cutecom. I like your 4.0 which will be comprehensive and will be useful to all kind of the users. Will it be possible that you can compile it under Linux to make the code more robust? Also it will be great if you can release the boot loader's source code so that the whole firmware come be compiled every time from the scratch.
SteveRoss is offline Find More Posts by SteveRoss
Last edited by SteveRoss; Apr 29, 2009 at 03:29 AM.
Reply With Quote
Old Apr 29, 2009, 07:39 AM
Registered User
Greece, Attica, Piraeus
Joined Jun 2004
1,133 Posts
I just tested it and it works but i will test it some more.
The code is written, compiled and flashed using Linux only.
The bootloader source code is in the 3.9 zip i posted.
UPDATE:
The bootloader is working fine.
I suspect something is wrong because when you enter the bootloader the led flashes very slowly (on for about 8 seconds and off for about 8 seconds)
Check that you uploaded the servo2ppm+bootloader.hex file and that
the BOOTRST fuse is checked.
Also the BOOTSZ0 and the BOOTSZ1 must be checked.
Avr studio instead of showing you the last two fuses it has a box where you select the bootloader size.
Select the largest size of 1024 WORDS (not bytes) = 2048 Bytes.
(do not mess with any other fuse.
Chris
hendrix is offline Find More Posts by hendrix
Last edited by hendrix; Apr 29, 2009 at 09:08 AM.
Reply With Quote
Old Apr 29, 2009, 12:48 PM
David1
bmw330i's Avatar
USA
Joined Mar 2007
1,478 Posts
Programming with an AVR programmer

Here's a quick set of screenshots of the steps I do for programming the "servo2ppm_v3_9.hex" files into the boards.

1) Open AVR Studio and go to the "Main" tab.
2) Read the value from the board
3) Go to the Program tab and locate, open the file to be programmed. Click the program button
4) Go to the Fuses tab and set the fuses like this and click Program

That's it. Takes a few seconds. I do it by pressing the 2x3 pin connector into the holes on the board so I don't have to solder them forever on the board to program.

-David
bmw330i is offline Find More Posts by bmw330i
Reply With Quote
Old Apr 29, 2009, 01:42 PM
Registered User
Redwood City, CA
Joined Mar 2009
58 Posts
Quote:
Originally Posted by hendrix
I just tested it and it works but i will test it some more.
The code is written, compiled and flashed using Linux only.
The bootloader source code is in the 3.9 zip i posted.
UPDATE:
The bootloader is working fine.
I suspect something is wrong because when you enter the bootloader the led flashes very slowly (on for about 8 seconds and off for about 8 seconds)
Check that you uploaded the servo2ppm+bootloader.hex file and that
the BOOTRST fuse is checked.
Also the BOOTSZ0 and the BOOTSZ1 must be checked.
Avr studio instead of showing you the last two fuses it has a box where you select the bootloader size.
Select the largest size of 1024 WORDS (not bytes) = 2048 Bytes.
(do not mess with any other fuse.
Chris
Chris,

I tried to download all avr related packages from Synaptic and compile the ver 3.9 in Linux but still got compilation errors.

For the bootloader the error messages looked like as follows.

make
avr-gcc -c -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-ahlms=x_modem_bootloader_v3_1.lst -mmcu=atmega168 -DF_CPU=8000000UL -DBOOTLOADER_MEM_START=0x3800 -I. x_modem_bootloader_v3_1.c -o x_modem_bootloader_v3_1.o
x_modem_bootloader_v3_1.c:380: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__fuse’
x_modem_bootloader_v3_1.c:646: warning: return type of ‘main’ is not ‘int’
make: *** [x_modem_bootloader_v3_1.o] Error 1



For the main package, the compilation errors were as follows.

make
avr-gcc -c -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-ahlms=ppm_encoder_ver_3_9.lst -mmcu=atmega168 -DF_CPU=8000000UL -I. ppm_encoder_ver_3_9.c -o ppm_encoder_ver_3_9.o
ppm_encoder_ver_3_9.c:136:2: warning: #warning TIMER0 PRESCALER SET TO 8
ppm_encoder_ver_3_9.c:156:2: warning: #warning TIMER1 PRESCALER SET TO 8
ppm_encoder_ver_3_9.c:276: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__fuse’
ppm_encoder_ver_3_9.c:324:2: warning: #warning PPM output type set to FUTABA
ppm_encoder_ver_3_9.c:890:35: error: macro "ISR" passed 2 arguments, but takes just 1
ppm_encoder_ver_3_9.c:891: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
make: *** [ppm_encoder_ver_3_9.o] Error 1



This time I checked the fuse BOOTRST, and programmed it using AVR studio, and can see the new prompt "ATWF=Flash ...". The cutecom failed several times, but then I found out the message in the terminal where I invoked cutecom. It said "sx exited". It turned out that /usr/bin/sx did not exist. I then installed all xmodem related package from Synaptic, and do a cutecom again, this time, the FTDI cable (with no external 4.8 Receiver battery) finally can transfer the .bin file using Xmodem.
SteveRoss is offline Find More Posts by SteveRoss
Last edited by SteveRoss; Apr 29, 2009 at 01:50 PM.
Reply With Quote
Old Apr 29, 2009, 02:51 PM
Registered User
Greece, Attica, Piraeus
Joined Jun 2004
1,133 Posts
Go to post 1498 and re download it.
All source code is in there i just checked.
Chris
hendrix is offline Find More Posts by hendrix
Last edited by hendrix; Apr 29, 2009 at 04:37 PM.
Reply With Quote
Old Apr 29, 2009, 03:57 PM
Registered User
Redwood City, CA
Joined Mar 2009
58 Posts
Deleted.
SteveRoss is offline Find More Posts by SteveRoss
Last edited by SteveRoss; Apr 29, 2009 at 04:27 PM.
Reply With Quote
Old Apr 29, 2009, 09:48 PM
Registered User
Panama', RP
Joined Aug 2004
65 Posts
Quote:
Originally Posted by hendrix
Hi. David
...
When they got the board it was mentioned that you will need to be able to setup failsafe values at least on the "MODE" channel and it still is.
...
Chris
Hi Chris,
I believe that the discussion of failsafe and methods needed to use the PPM encoder with "failsafe receivers" that can not be set on all channels has overshadowed the fact that the board can be used with almost any receiver/transmitter combination that is capable of flying Paparazzi!
This is what I understand to be the state of the firmware to date:
1. A receiver with no failsafe of any type - use v3.8 - PPM will be cut off on signal lose - Paparazzi goes to Home mode on lose of signal.
2. A receiver with failsafe on all channels. - use v3.8 and set failsafe on "Mode" channel to go to AUTO2 - Paparazzi goes to AUTO2 on signal lose.
3. A "failsafe receiver" that can not set failsafe on "Mode" channel - use v3.9 and setup procedures - Paparazzi goes to AUTO2 on signal lose.
4. A receiver that only holds last good pulse on lose of signal - not compatible with PPM encoder because Paparazzi will never see a lose of signal or a mode change.
Please correct me if I am wrong.

Joe
joekadet is offline Find More Posts by joekadet
Last edited by joekadet; Apr 29, 2009 at 10:22 PM. Reason: clarify post
Reply With Quote
Old Apr 29, 2009, 10:34 PM
David1
bmw330i's Avatar
USA
Joined Mar 2007
1,478 Posts
Quote:
Originally Posted by joekadet
Hi Chris,
I believe that the discussion of failsafe and methods needed to use the PPM encoder with "failsafe receivers" that can not be set on all channels has overshadowed the fact that the board can be used with almost any receiver/transmitter combination that is capable of flying Paparazzi!
This is what I understand to be the state of the firmware to date:
1. A receiver with no failsafe of any type - use v3.8 - PPM will be cut off on signal lose - Paparazzi goes to Home mode on lose of signal.
2. A receiver with failsafe on all channels. - use v3.8 and set failsafe on "Mode" channel to go to AUTO2 - Paparazzi goes to AUTO2 on signal lose.
3. A "failsafe receiver" that can not set failsafe on "Mode" channel - use v3.9 and setup procedures - Paparazzi goes to AUTO2 on signal lose.
4. A receiver that only holds last good pulse on lose of signal - not compatible with PPM encoder because Paparazzi will never see a lose of signal or a mode change.
Please correct me if I am wrong.

Joe
Wow, thank you Joe for summing up what I was scratching my head about. I was wondering what all the use cases were and there you pretty much put them out there.

Basically I just programmed every remaining board with 3.9 the version with the boot loader. If someone requests a different version I can re-flash it before shipping.

-David
bmw330i is offline Find More Posts by bmw330i
Reply With Quote
Old Apr 29, 2009, 11:17 PM
Registered User
Panama', RP
Joined Aug 2004
65 Posts
AVR Programmer

Hi David,

Thanks. Those are my assumptions based on loads of reading. I finally got my AVRISPmkll programmer working with AVR Studio 4 so now I can do some testing. Today I made up cables and tomorrow I hope to try it out on my TWOG and a Hitec Supreme 8 channel. That will test out # 1.

What AVR programmer are you using?

Joe
joekadet is offline Find More Posts by joekadet
Reply With Quote
Reply


Thread Tools