Gluonpilot

Do you see anything if you uncheck "Hide parsed lines"?
Do you see the boot messages when the module starts up?

In the "cockpit" panel of GluonCS, I see that the connection icon is not enabled?

Do you see anything if you uncheck "Hide parsed lines"? No
Do you see the boot messages when the module starts up? No

In the "cockpit" panel of GluonCS, I see that the connection icon is not enabled? Yes, (before pressing the "Ok" button).

Are you using the FTDI connector of the extension board or directly on the main board?

I have tried both, but after the problem started I have mainly been working directly on the main board, (also with and without the GPS connected).

Tom, this could be similar problem I had couple of weeks ago with 0.8 Beta version.

Jorn, can you try to connect using gluonconfig tool instead off GCS?

Yes Maybe. I've uploaded BETA 4 to the download section. Could you try this one?

Still can't do anything else then reboot the module. So far I have tried:
- New and previous GCS -> will not connect
- Config tool -> will not connect, but able to reboot
- ds30 bootloader GUI -> the module reboots, then searching for bl (bootloader) which results in a timeout warning, and then the process ends.
- ds30 bootloader console:

ds30LoaderConsole.exe -k=COM12 -f="rtos_pilot.X.production.hex" -p -d=dsPIC33FJ256MC710 -r=115200 -q=0a;5a;5a;3b;31;31;32;33;0a -u=57600 -b=1200 -o

-> Basically the same result as with the GUI. Messages:

ds30 Loader console free edition 1.0.7
ds30 Loader engine 2.2.2
Copyright 2011-2012 MG Digital Solutions
http://www.ds30loader.com

Initializing the ds30 Loader engine...
Loading port plugin clsds30LoaderPortSerial: found 1 port
Parsing hexfile...
File timestamp: 11.06.2012 13:34:14
Opening hexfile...okok
Validating hexfile...ok
Hex file successfully parsed

File: rtos_pilot.X.production.hex
Device: dsPIC33FJ256MC710
Port: COM12
Baudrate: 115200



Initiating write...
Resetting device...ok
Searching for bl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . timed out
Tx 48 bytes / Rx 0 bytes / 11,7s
Write failed

Hi Jorn,

I don't really have any clue what could be wrong here.

Feel free to send it back to me for inspection.

Hi,

I am now ready to maiden the Skywalker. Before I do, I have a few questions and comments:
1. I got about 400m range from my xbee 900mHz modules on ground at 57600 b. I guess this is about as to be expected, (and will be improved at least some when in the air). Or, could it be increased by making changes to the settings, e.g by lowering the baudrate?
2. Is it ok to start with the default pid P values; pitch 0.7, roll 0.5, heading 0.7, attitude 0.03?
3. Is it possible to start an autometic mission without bringing the laptop? (just by switching to auto on the tx). If so, how do I program if?
4. As I understand it, most safety settings (except those in the "Control" tab in the config prog) are to be set by mission planning commands, (e.g max altitude, min altitude, max range from home, return altitude, what if wifi is lost, whatif radio is lost, what if gps is lost, which channel/switch on the tx to initiate returen to launch, etc. If this is correct, I would wish for a separate tab in the config menu where such settings could have been placed.
5. I would very much appreciate to have a distance based (3-5V digital) camera trigger output channel. Is this possible as is? -or, where in the firmware should I start to look if I wanted to hook up some custom code?
6. Tom, thanks for creating Gluonpilot! So for it appears to surpass every other ap I have looked at, by far.

Jorn

Hi Jorn,

1. The baudrate over the air is lower than the 57600 baud the gluonpilot uses. Make sure to do an RC-range test too. My 868MHz XBee interferes with my 35MHz receiver. I lowered the XBee's output to 25mW to overcome this. Still about 1.5km range (in the air). IMO, antenna positioning is the most critical factor here.

2. Yes I recommend to start with the default settings.

3. You should program the route at home & burn it to flash. There is not much more too it. A year and a half ago, there wasn't even a groundstation

4. For the moment this is not possible. The only way to do this for the moment is using the battery alert command or specific IF-commands in the navigation script. In the future this will probably stay in the mission planning commands, because this way it is easy to refer to other blocks (e.g. on GCS link failure, go to standby block). Which safety settings look the most important one to you?

5. Yes, this should be easy to implement in the trigger.c file. The hardest part (most work) is to make sure it is easy configurable from the GCS.

6. Thanks for giving it a try