grandk / ardupilot-mega Goto Github PK

What steps will reproduce the problem?
1. Observe the code in navigation.pde
 // wrap values
        if (loiter_delta > 170) loiter_delta -= 360;
        if (loiter_delta < -170) loiter_delta += 360;
2. ALSO - noticed the same code in the navigation library - which are we using?
3.

What is the expected output? What do you see instead?
I would think either 179 or 180 would be used

What version of the product are you using? On what operating system?


Please provide any additional information below.

It's my understanding that the throttle should be connected to channel 3 in the 
default configuration.

However, the comments suggest this is an aileron/rudder channel:

#define CH3_MIN 1000                    // (Microseconds) Range of Ailerons/ 
Rudder
#define CH3_MAX 2000                    // (Microseconds)

Outputs status data on serial monitor to reassure first time users that all is 
well. In the format:

"Welcome to ArduPilotMega Version x.x
Calibrating gyros...............calibrated
Checking GPS..........no lock (either you don't have a GPS connected, or maybe 
you're inside)

Checking switch status:
Datalogging switch is in: Datalog mode
DIP switches 1: On, 2: Off, 3: Off, 4: Off

RC input detected

Data output:

Ch1 in, Ch2 in, Ch3 in, Ch4 in, X attitude, Y attitude, Z attitude, abs 
pressure alt, GPS lat, lon, alt
....[repeat]
"

Output telemetry data in the same format as ArduPilot, so we can use the 
existing LabVIEW GCS and ArduStation

The waypoint altitude print-out and calculation for return-to-launch is 
incorrect. I was testing failsafe conditions and whether it would RTL when on 
auto. That works, but I was getting concerned after reading the altitude for 
RTL. The altitude is initially calculated by taking wp0.alt + home.alt, which 
evaluates to 2x home altitude. This is printed on screen when current waypoints 
are printed.

The return_to_launch function however overrides the altitude later on:

    next_WP.alt = read_alt_to_hold();

But this calculation is incorrect, because it is not offset with the 
home altitude.

Evidence:

10:MSG: AUTO
46:MSG fetch found new cmd from list at index: 1
15:MSG cmd id: 22
33:MSG WP index is incremented to 1
35:MSG new command_must_id 22 index:1
29:MSG set_next_WP, wp_index: 1
54:MSG: command #: 1 id: 22 p1: 20 p2: 30000 p3: 0 p4: 0
36:MSG: CUR:    519521216,  44283680,   -370
24:MSG: NWP:1,  0,  0,  29630
46:MSG fetch found new cmd from list at index: 2
.....
67:MSG: command #: 0 id: 16 p1: 0 p2: -370 p3: 519521216 p4: 44283680
37:MSG: CUR:    519748384,  44604984,   31720
38:MSG: NWP:0,  519521216,  44283680,   -740


So 2 issues:

1. Can the printout be modified to print the real altitude?  ( maybe requires 
passing in a standard offset altitude or something).
2. The RTL calculated altitude is not offset with the home altitude.

Doug Wiebel reports:

 I saw several bugs in my flight today including a most interesting bug in Fly by Wire A that I have not had time to look at.  FBW-A worked great, except when I went to a high throttle (perhaps 90% of my stick travel) setting then for some reason I lost pitch and roll control and the AP just continued to hold the attitude of when I passed the critical throttle value.  As soon as I lowered the throttle I regained pitch and roll control.

Since 'int' is a bit ambiguous...

While tinkering on the bench, I noticed that if I start up with a mode other 
than Manual commanded the nav_pitch/nav_roll values start out at maximum, 
causing wild servo outputs.

Swapping back to Manual causes them to return to sane values, after which the 
other modes work more as expected.

In the EEPROM.pde in the waypoint writer, the ALT_TO_HOLD is multiplied by 100, 
but not cast to a uint32_t. #defines are assumed to be regular signed integers, 
so this needs a cast to uint32_t to support altitudes above 327.67.

eeprom_write_dword((uint32_t *) EE_ALT_HOLD_HOME, ALT_TO_HOLD * 100);

should become:

eeprom_write_dword((uint32_t *) EE_ALT_HOLD_HOME, (uint32_t)ALT_TO_HOLD * 100);

The command to control climb rate needs to be implemented. We currently have 
the 2.7 behavior implemented. I would like to keep that since most people don't 
care about climb rates. If this new command could override or build upon the 
current behavior, that would be fine. 

Using legasy GCS
I get speed sensor at rest is 26. when I blow into pidot speed rises.
Code problem ?

Would like to have a Goto command with a loop counter. If the counter is 0, the 
command is skipped.

ALH appears correct in all modes except AUTO mode in which case it is double 
the expected value.

I'm trying to get ArduPilot working with flightgear (own fgfs interface on 
Linux Ubuntu). In the sources, I noticed a possible bug at line 768 in 
ArduPilotMega_1_0.pde. It says

servo_out[CH_PITCH] = ((radio_in[CH_PITCH] - radio_trim[CH_PITCH]) * 45.0f  * 
reverse_roll) / 500;

Should that be reverse_pitch instead?

The lat and long altitude display on the GCS is off by a factor of 10.
The cure seams to eliminate the /10 in the print statement in GCS_Autopilot 
part of the code.
Using the MTK GPS unit.
            Serial.print("!!!");
            Serial.print("LAT:");
            Serial.print(current_loc.lat,DEC);
            Serial.print(",LON:");
            Serial.print(current_loc.lng,DEC); //wp_current_lat

Trying to compile the sensor debug subsystem will result in multiple 
compilation errors. The function calls:

read_z_sensor();
read_XY_sensors();
read_battery();

doesn't exist.

What steps will reproduce the problem?
1. Stock r627 download, UBLOX enabled in config
2. On ground startup
3.

What is the expected output? What do you see instead?

I expect the servos to do the normal twitch, and the ESC to enter an "OK" mode.

Instead, I have full left rudder, full down elevator, and ESC enters "full 
throttle" programming mode.


What version of the product are you using? On what operating system?

r627, windows

Please provide any additional information below.

When I isolate the throttle from the MUX, I get proper ESC startup, but still 
full rudder and elevator deflection.  To me this indicates something in how APM 
is controlling the servos.  I have tried the DIP switches on-board to no avail. 
 Will continue working on the config file.

Implement command to disable/enable telemetry

What steps will reproduce the problem?
1.DEBUG_SUBSYSTEM 2
2.increase throttle up/down 
3. rudder channel ( on channel 4) noise increase and rudder always twitching

What is the expected output? What do you see instead?
Rudder not moving when not touching the RC TX

What version of the product are you using? On what operating system?
1.0.2

Please provide any additional information below.
I updated the 328 with avr studio which fixed most of my previous twitching 
issues but not this one.
I attached Servo output debug. During the test I only moved the throttle 
channel (ch 3) but the rudder (ch 4) output changes wildly.

In function debug_subsystem() the last print should be a println.

Is:Serial.print("meters");

Should be: Serial.println("meters");



What version of the product are you using? On what operating system?
Revision 526

Please provide any additional information below.

This is a very minor bug, but i will continue to test from now on.

Regards Magnus

The latest changes are causing dangerous altitude issues. The waypoint writer 
still assumes altitudes in meters, but these are no longer multiplied by 100 as 
the code is read in commands.pde. The result is the plane eventually using 
altitudes specified in meters as centimeters, which can easily cause drone 
crashes if loaded from subversion directly.

Note also that the "EEPROM.pde" in the waypoint writer unnecessarily casts the 
alt value to an signed int, causing an overflow with altitudes > 32767 (this 
may have an impact on the method how this issue is resolved. If one opts to 
enter the waypoint alts as m * 100, then this would "only" allow the APM to fly 
up to 327.67 meters).

I've locally modified my code to fix this in 2 different ways. One in which the 
altitude is passed in as meters * 100 in the waypoint list (which worked 
instantly). The other, possibly preferred one, is that altitude is still 
supplied as meters, but multiplied by 100 in the set_next_WP function 
(next_WP.alt *= 100). The latter one avoids any checks on the type of command 
passed in (which previously was done with a tricky < 0x20 check, even though 
there are command types like 0x21 or 0x44 that use altitude too). Allowing the 
user to use meters for the waypoint list creates less confusion, because it 
uses the same units as the WP_RADIUS and ALT_TO_HOLD defines.

What steps will reproduce the problem?
1. Roll the aircraft in FBWA on the ground - very little movement on left roll
2. Provide full stick inputs to left and right - with right bank command at 
max(right wing down), aileron goes to zero as you then roll(by hand) to 
MAX_HEAD but continues left when setting left command to MAX.
3.

What is the expected output? What do you see instead?
See above

What version of the product are you using? On what operating system?
Latest as of Aug 26 afternoon
Latest as of Aug 26 (77x)
Please provide any additional information below.

Google map does not update.

What steps will reproduce the problem?
1. use GCS_PROTOCOL = 2
2. compile
3.print_waypoint(wp, wp_index) is not declared in GCS_Ardupilot.cpp so 
commands.cpp can not compile as it is called in

void set_next_WP(struct Location *wp)
{
    //send_message(SEVERITY_LOW,"load WP");
    Serial.print("MSG set_next_WP, wp_index: ");
    Serial.println(wp_index,DEC);
    print_waypoint(wp, wp_index);

What is the expected output? What do you see instead?
compile.
o: In function `set_next_WP(Location*)':
C:\PATH/ArduPilotMega_1_0.cpp:3608: undefined reference to 
`print_waypoint(Location*, unsigned char)'

What version of the product are you using? On what operating system?
last svn r622

Please provide any additional information below.

When trying to test to debug the air speed sensor i realized that 
read_airspeed() gets its input from one of the AD inputs on the AT Mega rather 
than from channel 7 on the external AD.

airpressure_raw = ((float)analogRead(AIRSPEED_PIN) * .25) + (airpressure_raw * 
.75);

The Airspeed sensor is connected to the Mega shield on channel 7 on the shields 
AD converter. 

I flew auto takeoff last week and didn't have the best results. The throttle 
bugged me the most. I made the throttle in the current version set by the 
throttle stick.

Output attitude data in the same format as ArduIMU binary comms, so we can use 
HappyKillmore's ArduIMU desktop display app.

Add callback to telemetry that sends down the variable.

Baro altitude was working well in early August but is no longer working.  May 
be related to EEPROM changes...

For a temporary workaround you can set ALTITUDE_MIX 0 until this issue is 
resolved.

i.e. in the header file, we see:

#define CH1_MIN 1000                    // (Microseconds) Range of Ailerons/ 
Rudder
...
#define CH8_MAX 2000                    // (Microseconds)

but the board is marked for channels 0-7

Attached is a basic system connection diagram for APM as per my reading of the 
1.0.1 alpha sources.

Please suggest corrections, or update the Graffle file to suit.

What steps will reproduce the problem?
1. Switch telemetry to output on SendSer as Serial3.print
2. Switch telemetry to output on SendSerln as Serial3.println
3. Telemetry data not outputted on Serial3

What is the expected output? What do you see instead?
GCS_* uses Serial.print and Serial.println instead of SendSer and SendSerln

What version of the product are you using? On what operating system?
1.0.2 - n/a

Please provide any additional information below.

This was probably meant to be APM_Config.h.

I'm trying to get ArduPilot working with flightgear (own fgfs interface on 
Linux Ubuntu). In the sources, I noticed a possible bug at line 768 in 
ArduPilotMega_1_0.pde. It says

servo_out[CH_PITCH] = ((radio_in[CH_PITCH] - radio_trim[CH_PITCH]) * 45.0f  * 
reverse_roll) / 500;

Should that be reverse_pitch instead?

A: Maybe show gyro saturation?
B: On if datalogging is on; off if dumping data over USB
C: Off if no gps messages are being received, will blink with each message 
received when we do not have lock, and will be solid if we do have lock.

Altitude hold is off by a factor of 2 using MTK GPS and standard GCS printout.
Cure seems to be this.

            Serial.print(",ALH:");
            Serial.print(next_WP.alt/200,DEC);

What steps will reproduce the problem?
1.keywords.txt in GPS_MTK lib 
2.Ground_Speed  KETWORD2
3.Typo KETWORD

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Loaded the demo, from

http://code.google.com/p/ardupilot-mega/wiki/Programming

There are two links, both show the same file. The "dancing demo" ist not 
available.

Upload goes ok.

APM with Oil pan => 

jitter of servos
servos at 0 and 1 (rudder/elevator) move together
esc does not work

Without oil pan:

not jitter
but servos run together

Versions:
Used lates versions. 

Do not know how to see the version of firmware.


See

http://www.youtube.com/watch?v=wJUgzQbHnoY

and

http://www.youtube.com/watch?v=HD0Dm0ObNSM


What steps will reproduce the problem?
1. Load demo file ArduPilotMega_demo.zip 
2. While running demo => jitter, values in the console do not change
3. Without oilpan not jitter, rest of errors the same

What is the expected output? What do you see instead?

Servos should either "dance" or go with the sticks.


What version of the product are you using? On what operating system?

Win Vista, Upload and comminication are ok.


Please provide any additional information below.

Do not know what the problem is. Dont know wich next steps to do.

What steps will reproduce the problem?
1. Reading
2.
3.gps_mtk library keywords.txt calls gps_ublox instead of gps_mtn


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. Include GCS_Xplane by selecting GCS_PROTOCOL 3
2. Compilation fails due to "redefinition of print_waypoint".


What version of the product are you using? On what operating system?
Current trunk @ 6-aug-2010.

Please provide any additional information below.
Moving #endif to the end of the file fixes the problem.

I defined a waypoint at 400 meters, but this showed up as negative in the 
waypoint list later. Turns out the waypoint writer casts altitude to a signed 
integer, multiplies them by 100 and then stores them in EEPROM. This means that 
altitudes > 327.67 cannot be supported:

loc.alt = (int)mission[i][2] * 100;

I locally modified this to be:

loc.alt = (long)mission[i][2] * 100;

since the altitude in both APM and WPW are defined as longs. Reloading this 
made things work again.

I had an issue that the plane wasn't reaching my waypoints any longer. Turns 
out that the WP_RADIUS is written correctly by the waypoint writer, but the 
ardupilot mega overwrites the WP_RADIUS with an extra byte from the WP_INDEX 
save function. The WaypointWriter writes both as a byte, but Ardupilot Mega 
code (EEPROM) writes and reads WP_INDEX as a word, thus 2 bytes:

void save_command_index(void)
{
    eeprom_busy_wait();
    eeprom_write_word((uint16_t *) EE_WP_INDEX, command_must_index);
}

void read_command_index(void)
{
    eeprom_busy_wait();
    wp_index = command_must_index   = eeprom_read_word((uint16_t *) EE_WP_INDEX);
}

This should become eeprom_read_byte and write_byte?

The altitude derived in get_LOITER_home_wp() may be incorrect if the requested 
height exceeds 327.67 meters. The EE_ALT_HOLD_HOME should be read in as follows:

int32_t hold = eeprom_read_dword((uint32_t *)   EE_ALT_HOLD_HOME);

but the APM function reads it in as:

struct Location get_LOITER_home_wp()
{
    // read home position 
    struct Location temp = get_wp_with_index(0);    
    temp.id = CMD_LOITER;

    eeprom_busy_wait();
    int hold = eeprom_read_word((uint16_t *)    EE_ALT_HOLD_HOME);

What steps will reproduce the problem?
1.Compile code with 
  #define GCS_PROTOCOL 2, 
  #define GPS_PROTOCOL 4
  #define AIRSPEED_SENSOR 0 
  #include <GPS_MTK.h>
2.run ArduPilot GCS.exe 
3.

What is the expected output? What do you see instead?
Expected:
uva Latitude 27.6xxx 152.2xxx

Actual Output 2.76xxx 15.2xxx
*************
WorkAround   

In GCS_Ardupilot.pde change:

Serial.print(current_loc.lng/10,DEC); //wp_current_lat
to
Serial.print(current_loc.lng,DEC); //wp_current_lat

change
Serial.print(current_loc.lat/10,DEC);
to
Serial.print(current_loc.lat,DEC);
*******************
I dont know if this is a fix or kludge that hides a deeper problem.... I am a 
complete noob to C

What version of the product are you using? On what operating system?

v227
Please provide any additional information below.

CRS number is way off in GCS display. Using MTK GPS unit.
Here is my solution.

            Serial.print(",CRS:");
            Serial.print(ground_course/1000000,DEC);

The page at http://code.google.com/p/ardupilot-mega/wiki/Voltage explains how 
to select your voltage divider, but not where to connect the battery.

e.g. does this sniff voltage from the battery connector on the APM board (and 
if not, how do you do that)?  Does it depend on one of the analog connectors 
scattered around the IMU board?

What steps will reproduce the problem?
1. Upload WP file using Ardupilot 1.0.1a MEGA Waypoint writer
2. Reboot
3. Erratic Servo behavior until ArduPilotMega Version 1.0.2 is re-loaded

What is the expected output? What do you see instead?

I would expect the APM to accept WP uploads without having to re-load the base 
code stack.

What version of the product are you using? On what operating system?

r659


Please provide any additional information below.

Fly in FBW B, Restart APM, Plane will fly hard right. Flip to Manual, plane 
will spin. Flip back to FBW and plane is re-trimmed and flie perfect.

What steps will reproduce the problem?
1.Download code ardupilot-mega - Revision 622: /Trunk/ArduPilotMega_1_0

2.Change #include <GPS_IMU.h> to include <GPS_MTK.h> ( select MTK )

3.output on compile is:  In function 'void fast_loop()':
error: 'class GPS_MTK_Class' has no member named 'airspeed'

What is the expected output? What do you see instead?

Compile complete

What version of the product are you using? On what operating system?
Revision 622 on windows 7 /64 

Please provide any additional information below.

The broadcast feature only allows for one value to be broadcast.  It would be 
nice™ to be able to request more.