@Stamatis wrote:

Hello! i have an Apm 2.6 ac 3.1.5 and neo 6m gps and when hit RTL and comes abone the landing point instead to land, fly upward oposite. What is the problem do you think?

Posts: 1

Participants: 1

Read full topic

@Julien wrote:

Hi guys,

I would be please to get support on object avoidance and range finders.
I tested with one SF11 straight forward and it works, the drone stops. I’m just wondering if it could work by installing two of them looking forward but with an angle of 45deg. (to get more surface samples)
The drone on which it should be installed, i can not use 360 rangefinders, so if someone already experimented this i would be please to know if and how it worked & performed

Thanks !

Posts: 2

Participants: 2

Read full topic

@endym wrote:

Hi all,

I finished a new build of a quadrocopter with RPi and Navio2. Everyting is working in Stabilized mode. I get 8 to 11 satalites and hdop shows values between 1.5 and below.

Then I wanted to test Loiter mode.
Started the motors in Stabilized mode, then switched to Loiter mode…and motors stop spinning. I repeated this several times, but it is always the same result, the motors stop spinning.

I found different topics that suggested interferences with the gps antenna. So I “shielded” the cabel of the gps antenna with aluminium foil, but it is still the same result.

The gps antenna was delivered with the Navio2, so I assume this as a “working bundle”!?

Attached is a .bin file where the copter sits on ground, Loiter mode alredy on and then I arm the vehicle two times. Each time the motors start spinning and after a short while they stop. Within the log file I found the “motors_interlock_enabled” label and hope it is the right hint.

Does anybody have a hint or suggestion what I can try to keep motors spinning in Loiter mode?

00000005.BIN (229.0 KB)

Posts: 2

Participants: 2

Read full topic

@Redfish wrote:

Hi folks, hope your all staying health and able to get out and fly.
I have a problem streaming video from any of my sky viper v2450 GPS drones to QGC on my Android tablet. I had the video working fine streaming RTSP but somehow QGC got auto updated along with half dozen other apps from the app store. After resetting all the global setting that were deleted I noticed that the RTSP info was gone as well. I added the RTSP info like I had setup before (thanks to all the info from several of you) and went to fly then discovered that the video window was black with msg “Video Disabled” . After a couple of hours searching I found the screen to “Enable Video” over in the Telemetry window setup screens, (why there instead of the video window itself). After enabling streaming there’s still a blank video window but it just says “Waiting for Video” . There’s video showing up fine in the SkyViper App and the Sonic board WEB interface but nothing in QGC. I double checked the RTSP setup info I entered and it looks correct ( RTSP://192.168.99.1:554/media/stream2 ).
I’ve tried restart QGC and the drones several times but nothing is showing in the video window. I’ve gone over the DOC’s a couple of times (the Video Streaming docs need some serious spell check and the item about More Video info on GitHub is a bad link 404) and see there’s several new items for different streams, I tried a couple of them but still no video using RTSP.
Have any of you tried streaming from SkyViper GPS to the QGC 4.0.6 and have video working? I’ve been over on GitHub and see there’s several issues with RTSP and UDP to Android QGC but nothing specific about SkyViper GPS.
I’m having to fly with the SkyViper App video on a small cell phone that I can’t see too well and sure would like to have QGC w video on my Lenovo 8" tablet (Android 7.0), was starting to get setup to fly multiple vipers but can’t do it with SkyViper app.
dp

Posts: 1

Participants: 1

Read full topic

@Greg_Wood wrote:

Maybe this isn’t the right place, but I’d like to discuss some ideas to get more uart connectivity on pixhawk platforms. Presently I’m working on system where I would like to have the following uart usage.

GPS
Serial radio (i.e. RFD900x)
Mavlink gimbal (i.e. alexmos)
Mavlink camera (i.e. flir, micasense, etc)
companion computer
ADSB
Leddar one rangefinder
FrSky telemetry
Blheli_32 telemetry

Thats 5 more than available on the pixhawk. Here are some of the ideas I’ve had to deal with this:

Use the companion computer to route mavlink messages. Gimbal, camera, ADSB, serial radio, and leddar one could all live behind the companion computer. This brings up a couple potential problems though. First of all the messages will need to make extra hops to get to their final destination, so adding latency and increasing the chance of losing one. Not a major problem, but worth mentioning. More significantly, managing the various data streams and rates per device becomes a headache. It would be a bad idea to just send everything everywhere since low throughput links (i.e. serial radio) could easily become saturated with meaningless traffic (i.e. gimbal messages). Telemetry would need to be requested from the pixhawk at the lowest common multiple of all the various requests and sent out accordingly. Maybe such software already exists to manage this?

Run frsky telemetry from the companion computer. This would require porting the telemetry code to the companion computer and modifying it to grab appropriate values from the mavlink stream. Doable, but still a pain.

Blheli_32 telemetry from companion computer. I don’t know how this would be synchronized with the telemetry requests going to the ESCs.

UAVCAN GPS. This seems like a good option to free up a port. Is it possible to do rtk/ppk with the present uavcan GPS stuff?

Add “virtual” serial ports to ardupilot. The companion computer could send/receive bytes on one of it’s physical uarts and encapsulate them inside mavlink frame for delivery to the “virtual” uarts in ardupilot. SERIAL_CONTROL seems to already implement this, but in reverse. Likely would be problems on timing sensitive protocols. Could this work to delivery blheli_32 telemetry? Requires ardupilot mods to support, I might do this.

UAVCAN virtual serial ports?

Those are my ideas so far. I was just hoping to get a discussion started, and maybe hear about some other solutions that have been developed.

Posts: 2

Participants: 2

Read full topic

@wcfung1 wrote:

My quad is running Revo board flashed with Copter 4.0.3.
My wing is also running Revo board flashed with Arduplane 4.0.5.

Both got error message when downloading Auto analysis. Screen shots attached.
“Review a log” in both cases is working fine.

ArduCopter

Arduplane

Any help is greatly appreciated. Thank you.

Posts: 2

Participants: 2

Read full topic

@LeegOfLejnds wrote:

Hi,

I have modified px4’s local_planner avoidance node to run with arducopter. Using a depth sensor attached to the iris_with_arducopter gazebo model, I’m publishing a pointcloud2 topic. The node converts this pointcloud data into a laser scan message and publishes it to /mavros/obstacle/send. I was wondering if there was a simple way for arducopter to receive this laser scan message in the form of OBSTACLE_DISTANCE

Screenshot from 2020-05-17 15-04-423776×2139 1010 KB

When mavros starts up it shows that the obstacle distance plugin is loaded and the planner node is constantly posting messages like this to /mavros/obstacle/send

header: 
  seq: 1886
  stamp: 
    secs: 736
    nsecs: 890000000
  frame_id: "map"
angle_min: 0.0
angle_max: 0.0
angle_increment: 0.104719758034
time_increment: 0.0
scan_time: 0.0
range_min: 0.20000000298
range_max: 15.0
ranges: [2.345651865005493, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 15.010000228881836, 2.429025411605835, 2.3743903636932373, 2.3546435832977295, 2.3510959148406982]

but i dont see it on the arducopter side. The following is from mavproxy:

LOITER> status
LOITER> Counters: Slave:5954 MasterIn:[73523] FGearOut:0 FGearIn:0 MasterOut:643
MAV Errors: 280
None
2504: AHRS {omegaIx : -0.0020479937084, omegaIy : -0.00200670282356, omegaIz : -0.00229100580327, accel_weight : 0.0, renorm_val : 0.0, error_rp : 0.00674330536276, error_yaw : 0.0139547735453}
2497: AHRS2 {roll : 0.013744388707, pitch : -0.00169652188197, yaw : 0.0215266048908, altitude : 0.0, lat : 0, lng : 0}
2499: AHRS3 {roll : 0.00734772719443, pitch : -0.00905097275972, yaw : 0.0214533731341, altitude : 594.609985352, lat : -353632601, lng : 1491652319, v1 : 0.0, v2 : 0.0, v3 : 0.0, v4 : 0.0}
2504: ATTITUDE {time_boot_ms : 604918, roll : 0.00734772719443, pitch : -0.00905097275972, yaw : 0.0214533731341, rollspeed : 0.12227319181, pitchspeed : 0.00014108675532, yawspeed : 0.00210963538848}
1: AUTOPILOT_VERSION {capabilities : 15311, flight_sw_version : 50728191, middleware_sw_version : 0, os_sw_version : 0, board_version : 0, flight_custom_version : [99, 98, 53, 55, 48, 99, 48, 0], middleware_custom_version : [0, 0, 0, 0, 0, 0, 0, 0], os_custom_version : [0, 0, 0, 0, 0, 0, 0, 0], vendor_id : 0, product_id : 0, uid : 0, uid2 : [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]}
280: BAD_DATA {Bad prefix, data:['20']}
2504: BATTERY_STATUS {id : 0, battery_function : 0, type : 0, temperature : 32767, voltages : [65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535], current_battery : 2949, current_consumed : 106, energy_consumed : 46, battery_remaining : 96, time_remaining : 0, charge_state : 0}
4: COMMAND_ACK {command : 400, result : 0}
2503: DISTANCE_SENSOR {time_boot_ms : 604918, min_distance : 20, max_distance : 5000, current_distance : 1026, type : 4, id : 0, orientation : 25, covariance : 0, horizontal_fov : 0.0, vertical_fov : 0.0, quaternion : [0.0, 0.0, 0.0, 0.0]}
2499: EKF_STATUS_REPORT {flags : 895, velocity_variance : 0.0301504377276, pos_horiz_variance : 0.0170443598181, pos_vert_variance : 0.00241008261219, compass_variance : 0.0301219541579, terrain_alt_variance : 0.0, airspeed_variance : 0.0}
2504: GLOBAL_POSITION_INT {time_boot_ms : 604918, lat : -353632601, lon : 1491652319, alt : 594610, relative_alt : 10715, vx : 15, vy : 0, vz : 0, hdg : 122}
3: GPS_GLOBAL_ORIGIN {latitude : -353632608, longitude : 1491652351, altitude : 583920, time_usec : 588571573}
2504: GPS_RAW_INT {time_usec : 604818000, fix_type : 6, lat : -353632613, lon : 1491652320, alt : 594150, eph : 121, epv : 200, vel : 4, cog : 27674, satellites_visible : 10, alt_ellipsoid : 0, h_acc : 200, v_acc : 200, vel_acc : 40, hdg_acc : 0, yaw : 0}
604: HEARTBEAT {type : 2, autopilot : 3, base_mode : 217, custom_mode : 5, system_status : 4, mavlink_version : 3}
3: HOME_POSITION {latitude : -353632596, longitude : 1491652334, altitude : 583900, x : 0.0, y : 0.0, z : 0.0, q : [1.0, 0.0, 0.0, 0.0], approach_x : 0.0, approach_y : 0.0, approach_z : 0.0, time_usec : 588571573}
2504: HWSTATUS {Vcc : 5000, I2Cerr : 0}
2349: LOCAL_POSITION_NED {time_boot_ms : 604918, x : -0.0452577769756, y : -0.139647156, z : -10.7157745361, vx : 0.150410622358, vy : 0.00105662841816, vz : -0.00598604604602}
2504: MEMINFO {brkval : 0, freemem : 65535, freemem32 : 131072}
1: MISSION_COUNT {target_system : 1, target_component : 240, count : 0, mission_type : 0}
2504: MISSION_CURRENT {seq : 0}
2504: NAV_CONTROLLER_OUTPUT {nav_roll : 0.337485611439, nav_pitch : -0.53586524725, nav_bearing : 1, target_bearing : 8, wp_dist : 0, alt_error : 0.016173094511, aspd_error : 0.0, xtrack_error : 0.0}
2380: PARAM_VALUE {param_id : STAT_RUNTIME, param_value : 8250.0, param_type : 6, param_count : 931, param_index : 65535}
2504: POWER_STATUS {Vcc : 5000, Vservo : 0, flags : 0}
2504: RANGEFINDER {distance : 10.2600002289, voltage : 1.02600002289}
2504: RAW_IMU {time_usec : 604918616, xacc : 0, yacc : -3, zacc : -1010, xgyro : 124, ygyro : 2, zgyro : 4, xmag : 223, ymag : 38, zmag : -539, id : 0, temperature : 0}
2504: RC_CHANNELS {time_boot_ms : 604918, chancount : 16, chan1_raw : 1500, chan2_raw : 1500, chan3_raw : 1500, chan4_raw : 1500, chan5_raw : 1800, chan6_raw : 1000, chan7_raw : 1000, chan8_raw : 1800, chan9_raw : 0, chan10_raw : 0, chan11_raw : 0, chan12_raw : 0, chan13_raw : 0, chan14_raw : 0, chan15_raw : 0, chan16_raw : 0, chan17_raw : 0, chan18_raw : 0, rssi : 0}
2504: SCALED_IMU2 {time_boot_ms : 604918, xacc : 0, yacc : -3, zacc : -1008, xgyro : 135, ygyro : 2, zgyro : 4, xmag : 223, ymag : 38, zmag : -539, temperature : 0}
2504: SCALED_IMU3 {time_boot_ms : 604918, xacc : 0, yacc : 0, zacc : 0, xgyro : 0, ygyro : 0, zgyro : 0, xmag : 223, ymag : 38, zmag : -539, temperature : 0}
2504: SCALED_PRESSURE {time_boot_ms : 604918, press_abs : 943.88671875, press_diff : 0.0, temperature : 3500}
227: SENSOR_OFFSETS {mag_ofs_x : 5, mag_ofs_y : 13, mag_ofs_z : -18, mag_declination : 0.20736888051, raw_press : 94388, raw_temp : 3500, gyro_cal_x : -1.99827190954e-05, gyro_cal_y : 1.63406966749e-05, gyro_cal_z : 3.15265824611e-05, accel_cal_x : 0.0010000000475, accel_cal_y : 0.0010000000475, accel_cal_z : 0.0010000000475}
2504: SERVO_OUTPUT_RAW {time_usec : 604918616, port : 0, servo1_raw : 1608, servo2_raw : 1529, servo3_raw : 1528, servo4_raw : 1608, servo5_raw : 0, servo6_raw : 0, servo7_raw : 0, servo8_raw : 0, servo9_raw : 0, servo10_raw : 0, servo11_raw : 0, servo12_raw : 0, servo13_raw : 0, servo14_raw : 0, servo15_raw : 0, servo16_raw : 0}
2504: SIMSTATE {roll : 0.0063869128935, pitch : -0.000106758692709, yaw : 0.0256327688694, xacc : -0.00157096842304, yacc : 0.0220022741705, zacc : -9.88020801544, xgyro : 0.302790105343, ygyro : -0.00146722164936, zgyro : 0.00715992366895, lat : -353632611, lng : 1491652318}
22: STATUSTEXT {severity : 6, text : EKF2 IMU1 in-flight yaw alignment complete, id : 0, chunk_seq : 0}
2504: SYSTEM_TIME {time_unix_usec : 1589752763879769, time_boot_ms : 604918}
2504: SYS_STATUS {onboard_control_sensors_present : 56753583, onboard_control_sensors_enabled : 56753583, onboard_control_sensors_health : 56753583, load : 0, voltage_battery : 12193, current_battery : 2949, battery_remaining : 96, drop_rate_comm : 0, errors_comm : 0, errors_count1 : 0, errors_count2 : 0, errors_count3 : 0, errors_count4 : 0}
2503: TERRAIN_REPORT {lat : -353632601, lon : 1491652319, spacing : 100, terrain_height : 583.884643555, current_height : 10.7098169327, pending : 0, loaded : 504}
60: TIMESYNC {tc1 : 0, ts1 : 600136406001}
2504: VFR_HUD {airspeed : 0.0460000038147, groundspeed : 0.150414332747, heading : 1, throttle : 35, alt : 594.609985352, climb : 0.00598604604602}
2504: VIBRATION {time_usec : 604918616, vibration_x : 0.00687937019393, vibration_y : 0.0425000488758, vibration_z : 0.157216966152, clipping_0 : 0, clipping_1 : 0, clipping_2 : 0}

These are my parameters:

LOITER> param show *AVOID*
LOITER> AVOID_ANGLE_MAX  1000.000000
AVOID_BEHAVE     0.000000
AVOID_DIST_MAX   5.000000
AVOID_ENABLE     3.000000
AVOID_MARGIN     2.000000

Posts: 2

Participants: 1

Read full topic

@aerodyno wrote:

Hi gang, I’m selling an Iris+ full kit – I upgraded it to ArduCopter 4.0.3 and calibrated everything, and it flies well. Check out the listing here:

Please check it out. And thanks for reading! I hope someone finds this useful!

Posts: 1

Participants: 1

Read full topic

@DanWA wrote:

Hi all, I have been wanting to build an antenna tracker mostly for video feed as I use 900mhz RFD900x for control link and need something to extend the 5.8ghz video link a little further.

Everything I have seen uses a secondary flight controller and GPS on the tracker unit, couldn’t I just use the Microsoft tablet I use for live telemetry (which has it’s own gps) and connect a maestro servo controller to USB and just control the tracker that way ? or am I missing an important step.

Posts: 3

Participants: 2

Read full topic

@clev0910 wrote:

I’ve tried to setup SITL by following the instructions from this link: https://ardupilot.org/dev/docs/sitl-native-on-windows.html

However, when I run the following command:
cd ~/ardupilot/ArduCopter
…/Tools/autotest/sim_vehicle.py --map --console

I get the following error:

2020-05-181920×1080 173 KB

Is there a change I have to make to one of the files?

Posts: 2

Participants: 2

Read full topic

@Andrew_Rabbitt wrote:

With the speed scaler (scalar…?) in Attitude.cpp, it is limited to a calculated max and min threshold with the following code:

    // ensure we have scaling over the full configured airspeed
    float scale_min = MIN(0.5, (0.5 * aparm.airspeed_min) / g.scaling_speed);
    float scale_max = MAX(2.0, (1.5 * aparm.airspeed_max) / g.scaling_speed);
    speed_scaler = constrain_float(speed_scaler, scale_min, scale_max);

Given that speed scaler/ar is calculated by:

        speed_scaler = g.scaling_speed / aspeed;

should not the max and min values be calculated the same way? i.e.:

    float scale_min = MIN(0.5, (g.scaling_speed / (1.5 * aparm.airspeed_max)));
    float scale_max = MAX(2.0, (g.scaling_speed / (0.5 * aparm.airspeed_min)));

Also, given that one can fly a quadplane in hover mode in FBWA mode (for example), shouldn’t we also have an assisted_flight test for this code along side the vtol mode test?:

    if (quadplane.in_vtol_mode() && hal.util->get_soft_armed()) {
        // when in VTOL modes limit surface movement at low speed to prevent instability

Just asking for a friend…

Posts: 1

Participants: 1

Read full topic

@Andre-K wrote:

After running all “433” antennas we had through a spectrum analyzer, I am very disappointed.

95% of all “stock antennennas” with SiK radios are just 2.4Ghz antennas, that show about 8db loss (emission) around 433Mhz

Tested five 433 antennas from Farnell , which were really about 500Mhz.

This is very disappointing.
Does anyone here have a known good source for 433-435Mhz , small, light , omnidirectional (rubber duckies or dipoles?) - anything with a donut radioation shape?

Posts: 1

Participants: 1

Read full topic

@ksharshit wrote:

1131×1600

An Unhealthy EKF standing at the Fork of Lanes in the Jungle of Bad Estimates

What is the EKF

The Extended Kalman Filter (EKF) is ArduPilot’s sophisticated attitude and position estimation system which takes in sensor input from, but not limited to, accelerometer, gyroscope, magnetometer, barometer, GPS, etc. and provides a 24-state estimate of the vehicle. State estimation is how we localize a vehicle in the environment and also keep track of biases of the sensors. The EKF algorithm is an ‘extended’ version of the linear Kalman Filter for non-linear models. Even though being a suboptimal estimator due to the linearization of the state transition and observation model, it is still used as the de-facto standard in Inertial Navigation Systems.

EKF lanes

Modern day vehicles have multiple sensors among which redundant IMUs are extremely common, in some cases built into the autopilot hardware. This practice has several benefits such as, backup in unexpected hardware failure, tolerance for different frequencies of vibration, to name a few. For each available IMU, a unique EKF instance is created by the autopilot. One important thing to note is that not all lanes provide state estimates at the same time step due to CPU job scheduling for load levelling. The amount of CPU time available for EKF updates is controlled so other critical components of the autopilot system do not suffer.

Switching between lanes

Sensors, as empowering as they are in measuring processes and landmarks, are inherently noisy and susceptible to disturbances from the environment. Errors in IMUs can accumulate quickly making the EKF output erroneous beyond safe flight. Now before we trigger a failsafe and decide to land the vehicle, we can look for an alternative healthy EKF lane with lower error to switch to. This is important in mission critical situations where aborting can be detrimental. The key challenge for such efficient lane switching is getting the right balance between being too aggressive and switching fast for the slightest of errors and being too slow to not switch which can compromise the safety of the available. Some situations which would invoke a lane switch decision are -

• Large change in IMU bias, common in long flights with low-grade sensors

• Two different barometers, significant drift in one due to high temperature

• High magnetic interference, different rates of coping in magnetometers

• Two GPS modules, one drifting badly in height

Current ArduPilot Switching Logic

The lane switching mechanism is a part of the subroutine which updates the EKF filter states and is called based on the SCHED_LOOP_RATE parameter which sets the main vehicle loop rate (there is also an explicit way to invoke a lane switch which we will address later). The core selection mechanism is ready to use after the primary lane has stabilised after initialization. This avoids triggering the switching mechanism due to alignment fluctuations and race conditions as the vehicle boots. The actual lane switching mechanism executes in 2 steps -

Looking for an alternative lane - This is executed when either the current lane’s error scores are too high or if its status is unhealthy. Then we check for other lanes which are considered available for selection if and only if their status is healthy and their state estimate has been updated on the current time step.

Switching to a lane - If we have found an eligible alternate core, then we can switch if the current primary is unhealthy or despite being healthy an alternate lane’s error-score is significantly lower (specifically, less than 67%) than the current primary’s error-score.

One clear issue with the above logic is the formation of a blind spot when an alternative lane exists, but has an error score that is just above (or below, as you see it) the required threshold to consider it for switching to, hence the switch not made. As exaggerated it may sound, but this can actually crash a vehicle if the following failsafe does not work correctly, or landing may not be feasible. A lane switch could have saved the day.

Smarter Lane Switching

Well, you know what they say, some man’s problem is another man’s GSoC Project. This summer we aim to robustify the lane switching mechanism by moving beyond fixed thresholds and incorporate more factors like Integrated Errors (accumulated error scores with time, providing more context to switch), state variances (errors in state estimates), sensor innovations (differences between predicted and observed state values), state difference between lanes (to know there is a problem), to name a few.

On a second line of thought, instead of switching the entire lane, it would be more efficient to identify and swap out the particular sensor that is corrupting the active lane. This would be useful when there are sensors of mixed performance classes installed in the vehicle and multiple available EKF lanes (consider a vehicle which has only 1 high-performance GPS and is attached to the primary lane whose barometer has gone bad, hence it would be ideal to switch the barometer rather than the entire EKF lane, so you don’t lose your best GPS). This extends the idea of lanes from IMU to non-IMU sensors and we call it sensor affinity.

During the course of my project, I will also create additional blogs to decode the intricacies of the EKF mechanism built in ArduPilot. This will assist readers in understanding this project better and spike interest in the practical design of an AutoPilot State Estimation system to invite more contributors (cries for help, cryptically).

Stay tuned as I will keep posting logs, results and different simulation setups used in this project and I open this blog to your valuable feedback, suggestions and crash stories.

Resources to Learn About the EKF

1. https://en.wikipedia.org/wiki/Extended_Kalman_filter

2. https://ardupilot.org/dev/docs/ekf.html

3. https://docs.px4.io/v1.9.0/en/advanced_config/tuning_the_ecl_ekf.html

4. https://github.com/PX4/ecl/tree/master/EKF/documentation

Posts: 2

Participants: 2

Read full topic

@Espen_Trydal wrote:

Hello,

Can anybody tell me if the position logged in the telemetry logs are is only from the GPS, or is it an estimate of the position based on the GPS and the IMU?

We are getting wrong position during flight, and then GPS glitch, but unsure if the error is because of the GPS, or if it could also be with the IMU. We do get this problem even if we put some distance between the GPS antenna and the rest of the electronics.

Posts: 1

Participants: 1

Read full topic

@Hyungsukoh wrote:

Hello developers!

I’m trying to build object avoidance in SITL.
So,
For the first,
I followed the gazebo instruction (https://ardupilot.org/dev/docs/using-gazebo-simulator-with-sitl.html),

And now, I’m trying to add rangefinder on the iris quad copter.
I followed the document, linked below, but I cannot set parameters “RNGFND1_~”
https://ardupilot.org/dev/docs/using-sitl-for-ardupilot-testing.html#adding-a-virtual-rangefinder

My ArduCopter version is 3.6.0 (cause of some reason),
and I only can find “RNGFND_~” or “RNGFND2_~”.

I changed “RNGFND_MAX_CM” and “RNGFND2_MAX_CM” to 3000 (30m),
but, the rangefinder indicate up to 5000(50m).

How can I solve this problem???

Posts: 1

Participants: 1

Read full topic

@Flipped03 wrote:

I’m trying rover4.0. But I found the main pwm output in pixhawk only has 1000 1200 1400 1600 1800 2000us. Even when I slowly pull up throttle the pwm output only change among these values. How can I get the linear PWM output？ Can I change parameter in mission planner to solve it?

Posts: 1

Participants: 1

Read full topic

@mitrucs wrote:

Hello,

I recorded files from ublox and ADIS16465 while moving with my car. I was wondering if/how it is possible to use AP to get a better position by combining the two sensors.

For now, I have two data files : ubx for ublox and text file for ADIS containing the accl and gyro.

I saw the libraries named AP_NavEKF that could be used for my interest here but I don’t see how to get it to work.

Any hints to get started ?

Thanks !
Mi

Posts: 1

Participants: 1

Read full topic

@maguet11020 wrote:

hi,

in manual mode, the roll is too sensitive. the pitch is ok .
i’m unable to change anything in the transmitter because it’s a herelink system.
i tried to change the paramters : MIXING_GAIN : the minimum is 0.5 .
MIXING_OFFSET : the problem is that when i lower the roll , the pitch
increase…

there must be a solution but i’m unable to find it !
Thanks.
Pascal

Posts: 1

Participants: 1

Read full topic

@meetgandhi123 wrote:

I cloned the ** -b Copter3.5.5** version from github and tried to run following command:

meet@meet-Inspiron-15-3567:~/Desktop/apm/ardupilot/ArduCopter$ /home/meet/Desktop/apm/ardupilot/Tools/autotest/sim_vehicle.py --map --console

ERROR:
‘build’ finished successfully (1.541s)
SIM_VEHICLE: Using defaults from (/home/meet/Desktop/apm/ardupilot/Tools/autotest/default_params/copter.parm)
SIM_VEHICLE: Run ArduCopter
SIM_VEHICLE: “/home/meet/Desktop/apm/ardupilot/Tools/autotest/run_in_terminal_window.sh” “ArduCopter” “/home/meet/Desktop/apm/ardupilot/build/sitl/bin/arducopter” “-S” “-I0” “–home” “-35.363261,149.165230,584,353” “–model” “+” “–speedup” “1” “–defaults” “/home/meet/Desktop/apm/ardupilot/Tools/autotest/default_params/copter.parm”
SIM_VEHICLE: Run MavProxy
SIM_VEHICLE: “mavproxy.py” “–master” “tcp:127.0.0.1:5760” “–sitl” “127.0.0.1:5501” “–out” “127.0.0.1:14550” “–out” “127.0.0.1:14551” “–map” “–console”
RiTW: Starting ArduCopter : /home/meet/Desktop/apm/ardupilot/build/sitl/bin/arducopter -S -I0 --home -35.363261,149.165230,584,353 --model + --speedup 1 --defaults /home/meet/Desktop/apm/ardupilot/Tools/autotest/default_params/copter.parm
Traceback (most recent call last):
File “/home/meet/Desktop/apm/ardupilot/Tools/autotest/sim_vehicle.py”, line 1017, in
start_mavproxy(cmd_opts, frame_infos)
File “/home/meet/Desktop/apm/ardupilot/Tools/autotest/sim_vehicle.py”, line 812, in start_mavproxy
run_cmd_blocking(“Run MavProxy”, cmd, env=env)
File “/home/meet/Desktop/apm/ardupilot/Tools/autotest/sim_vehicle.py”, line 655, in run_cmd_blocking
p = subprocess.Popen(cmd, **kw)
File “/usr/lib/python2.7/subprocess.py”, line 394, in init
errread, errwrite)
File “/usr/lib/python2.7/subprocess.py”, line 1047, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
SIM_VEHICLE: Killing tasks

But got this errors, please help.!

Error1366×741 165 KB

ArduCopter830×537 62 KB

Posts: 2

Participants: 2

Read full topic

@CraigElder wrote:

Issues & Pull requests

Plane

Copter

Rover

Posts: 1

Participants: 1

Read full topic