prasanpro / ardupilot-mega Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/ardupilot-mega
Automatically exported from code.google.com/p/ardupilot-mega
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.
Original issue reported on code.google.com by [email protected]
on 20 Aug 2010 at 2:14
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?
Original issue reported on code.google.com by [email protected]
on 19 Aug 2010 at 9:56
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.
Original issue reported on code.google.com by [email protected]
on 18 Aug 2010 at 8:30
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?
Original issue reported on code.google.com by [email protected]
on 19 Aug 2010 at 9:57
The broadcast feature only allows for one value to be broadcast. It would be
nice™ to be able to request more.
Original issue reported on code.google.com by [email protected]
on 9 Aug 2010 at 10:58
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.
Original issue reported on code.google.com by jasonshort
on 8 Aug 2010 at 5:30
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.
Original issue reported on code.google.com by [email protected]
on 5 Aug 2010 at 5:08
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);
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 8:09
Add callback to telemetry that sends down the variable.
Original issue reported on code.google.com by jasonshort
on 8 Aug 2010 at 6:27
Using legasy GCS
I get speed sensor at rest is 26. when I blow into pidot speed rises.
Code problem ?
Original issue reported on code.google.com by [email protected]
on 26 Aug 2010 at 7:58
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);
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 8:12
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.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 12:48
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2010 at 12:14
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 18 Aug 2010 at 10:10
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.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2010 at 4:07
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)
Original issue reported on code.google.com by [email protected]
on 3 Aug 2010 at 7:05
Output telemetry data in the same format as ArduPilot, so we can use the
existing LabVIEW GCS and ArduStation
Original issue reported on code.google.com by [email protected]
on 10 Aug 2010 at 7:19
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.
Original issue reported on code.google.com by [email protected]
on 22 Aug 2010 at 3:07
This was probably meant to be APM_Config.h.
Original issue reported on code.google.com by [email protected]
on 2 Aug 2010 at 7:43
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.
Original issue reported on code.google.com by [email protected]
on 11 Aug 2010 at 12:06
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.
Original issue reported on code.google.com by [email protected]
on 22 Aug 2010 at 6:13
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.
Original issue reported on code.google.com by [email protected]
on 19 Aug 2010 at 9:53
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 22 Aug 2010 at 6:18
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.
Original issue reported on code.google.com by jasonshort
on 8 Aug 2010 at 6:25
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.
Original issue reported on code.google.com by [email protected]
on 11 Aug 2010 at 2:14
Since 'int' is a bit ambiguous...
Original issue reported on code.google.com by [email protected]
on 10 Aug 2010 at 2:53
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.
Original issue reported on code.google.com by [email protected]
on 17 Aug 2010 at 10:43
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.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2010 at 4:57
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.
Original issue reported on code.google.com by [email protected]
on 6 Aug 2010 at 9:31
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
Original issue reported on code.google.com by [email protected]
on 8 Aug 2010 at 7:05
Google map does not update.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 8:14
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.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 12:53
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);
Original issue reported on code.google.com by [email protected]
on 22 Aug 2010 at 3:19
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?
Original issue reported on code.google.com by [email protected]
on 9 Aug 2010 at 10:54
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.
Original issue reported on code.google.com by [email protected]
on 5 Aug 2010 at 3:34
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);
Original issue reported on code.google.com by [email protected]
on 22 Aug 2010 at 9:27
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
Original issue reported on code.google.com by [email protected]
on 3 Aug 2010 at 7:06
Output attitude data in the same format as ArduIMU binary comms, so we can use
HappyKillmore's ArduIMU desktop display app.
Original issue reported on code.google.com by [email protected]
on 10 Aug 2010 at 7:23
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.
Original issue reported on code.google.com by [email protected]
on 18 Aug 2010 at 10:08
Implement command to disable/enable telemetry
Original issue reported on code.google.com by jasonshort
on 8 Aug 2010 at 6:28
Would like to have a Goto command with a loop counter. If the counter is 0, the
command is skipped.
Original issue reported on code.google.com by jasonshort
on 8 Aug 2010 at 6:26
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]
"
Original issue reported on code.google.com by [email protected]
on 10 Aug 2010 at 7:22
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.
Original issue reported on code.google.com by [email protected]
on 10 Aug 2010 at 7:54
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.
Original issue reported on code.google.com by jasonshort
on 17 Aug 2010 at 4:18
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?
Original issue reported on code.google.com by [email protected]
on 22 Aug 2010 at 9:53
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.
Original issue reported on code.google.com by [email protected]
on 22 Aug 2010 at 10:20
ALH appears correct in all modes except AUTO mode in which case it is double
the expected value.
Original issue reported on code.google.com by [email protected]
on 26 Aug 2010 at 9:17
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
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 8:05
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.
Original issue reported on code.google.com by [email protected]
on 3 Aug 2010 at 6:59
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.
Original issue reported on code.google.com by [email protected]
on 18 Aug 2010 at 7:43
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.