Servers by jDrones

Almost following waypoints - not quite there yet - reaching out for help

(jeffg) #1

I am using a Pixhawk with Syren ESC driving a small trolling motor, Ardurover 3.2.1, Mission Planner. Steering is set to servo 1, Throttle set to 3. I have disabled all fail safe settings because I am using one of the radio switches to control the main power to the drone. I seem to have good GPS, Compass settings, basic calibration, and everything works great in Manual mode.

The Pixhawk is connected to a tablet computer via Bluetooth and the tablet is connected to long range WIFI. I use Team viewer to remote into the system. It works beautifully and has incredible range.

I’ve been doing testing in the Santa Cruz harbor for the past two months and working through lots of fixes/improvements to the basic system and have ironed out the mechanical/power mgmt/communications systems. The final thing to dial in is the navigation.

The problem is that the drone starts doing doughnuts when I move to Auto. I reversed the yaw setting on radio calibration and it seemed to work better. Then again, I tested the reversed setting while on the dock and the rudder moved the wrong direction if heading to the way point. So, I switched it back. I added a separate power system for the electronics that is isolated from the motor circuit which cleaned up a lot of the line noise.

I’ve started working through the logs (one is attached) and kinda getting lost in the numbers. I seem to have steady power, reasonably stable compass readings, stable GPS, but the darn drone won’t follow the mission.

I am missing something and reaching out for some help/wisdom. Attached is a link to the most recent log file and a picture of the drone.


Link to Log:


(Khancyr) #2


I look a little a your logs (not my speciality) here are my comments :

  • ARMING_CHECK : shouldn’t be at 0. You should keep those on, unless you had good reason to do so ! If the test pass, you are generally safe to go, without them … well you don’t know what is your boat status … There is not problem at disabling failsafe action, if you have a way to handle this manually, but arming_check should be keep !
  • ARMING_REQUIRE : it is better to keep at 1 to prevent unexpect motor move when not ready
  • EK2_GPS_CHECK = -97.000000 ??? I don’t know if you touch that but the value isn’t good
  • THR_MAX = 50.000000 = CRUISE_SPEED !! You should allow to pass more power by raising the throttle_max if you can reach faster speed in order to give to the controler more power range, this will make the speed change better.

Reanble the arming_check and resolve the problem if any. I suspect a compass trouble ! .
Otherwise, you can use STEERING mode. It is the same controler that auto, so you can check that you direction handling is correct !

Your version is 3.1.2 not 3.2.1 ^^

(jeffg) #3

Appreciate the input.

Will enable Arming_check. Have a manual switch for the motor and servo but it is always good to have both and to also have the basic checks before starting a mission.

I will also re-calibrate the GPS and try with just Steering mode to confirm steering direction.

I will also move the tablet away from the GPS and Pixhawk in case it is interfering with the compass.

Time for another round of testing…

(gmorph) #4

What a cool looking boat. Please keep us updated with how you go!

Thanks, Grant.

(jeffg) #5

Thx Grant.

I’ve spent the past week making changes and running tests.

(jeffg) #6
  1. I played the arming settings, and while those changes did make things a bit safer, they had no effect following way points.

  2. Went through the entire power grid and made sure that all connections were soldered and all wires bound and cleanly routed. If electronics are acting unpredictable, it is always a good idea to do a clean up of the wiring. I did find and fixed a bad battery wire. The whole wiring setup looks a lot better but the changes also had no effect on the drone following way points.

  3. I added simple RC filters on the power lines to ESC, servo’s and LED circuits and moved the ESC further away from the Pixhawk. I also isolated the motor power circuit from the accessory circuit (12v) and the microprocessor circuits. (5v)
    Wow, that made a huge difference in the line noise and servo jitter but no effect on the drone following way points.

At this point, I am confident that the power systems are in great shape, that there are no shorts or loose wires, and that the electronics are wired properly. The next step is to move the Pixhawk up and away from the rest of the electronics and mount the Compass up and away from the Pixhawk. In addition, I will remove all metal from the upper area of the drone that may interfere with the compass signal.

(Alex Alexs) #7

Rc Filters should be between GND and Signal. You can add rc filter between + - for the BEC out , not neccessary for IN 12v. Also twist ALL 12v ± cables. Have a look on my last post where i uploaded a schematic. I was experiencing almost same issue.

(Alex Alexs) #8

Also to fix circles i switched manual mode to steering and discovered that rudder was moving different in steering mode. I played with/changed steering2servo parameters (don’t understand at the moment their functions) until I made the rudder to work same as manual mode,checked reverse box for roll and all is good know. Thx to TCIII Grant and Khancyr.

(jeffg) #9

Thanks Alex. I did change the rudder direction in MP in hope that that would fix things, but the drone just drove in circles inthe opposite direction. Yep, did put the filters between GND and signal for the servo, a battery and backup for the connections to the Pixhawk and other electronics (circuit isolated from the motor circuit). Will take a look at your schematic. thx for posting.

The result of all the clean-up and filtering is much smoother movement through the water and better overall response to the radio commands. Good thing but now fixing way-point issues.

Will dig into logs and head out again. Really appreciate the input.

I know the fix is going to be something stupid and I will kick myself for not figuring it out sooner.

(gmorph) #10

Jeff is using a Pixhawk original so no filters should be required.

Send a log through and we will have a look. Channel reverse settings are always the first place to look.

Thanks, Grant.

(Alex Alexs) #11

Pixhawk requires rc filter aswell.

(Alex Alexs) #12

as you can see… he said after adding everything work smooth

(jeffg) #13

I had to completely isolate the Pixhawk electronics anyway. Had a blue smoke incident last year that fried my APM and assorted other sensitive electronics. Now, the main;battery pack is at 24v and I added a 17 volt regulator that drives a battery/charger that feeds the Pixhawk, Phidgets, and tablet computer.

This eliminate a whole lot of noise and voltage fluctuations due to the brushed motor. It also made it possible to have the electronics running 8 hours after the main batteries are dead.

The good news is that all of the clean-up work has led to a much more stable boat and responsive boat.

The bad news is that I am still doing doughnuts in the harbor when I switch to Auto or used Guided control.

Log attached: what stupid thing am I missing? I accept that I am still learning how to read these logs. Lots of great data and still trying to link graphs to correctable issues.

(jeffg) #14

.bin file from 10-18.

(jeffg) #15

Checked Compass interference (followed log analysis instructions) and it looks good at around 15% after moving the GPS further away from the electronics.

(jeffg) #16

Next test is for GPS Glitches. Graphed GPS_Raw_IT vs “satellites_visible” . If GPS_Raw_IT < 150, then good. If “satellites_visible” > 9, then good.

Gps_Raw_IT is 59 to 75 which is good.
“satellites_visible” is between 15 and 20 which is also good.

(jeffg) #17

Next step: Checking relationship between board voltage and throttle settings. Plotting Vcc hwstatus_t and vfr_hud_t. In this case, we are looking for big drops in voltage related to motor speed and wide variations in board voltage (±2 v) during the mission that may not be related to the motor.

The result = Passed this test.

Throttle is between 0 and 103 and the corresponding effect to the board voltage is between 4577 and 4814 (12.09 v to 12.3 v) and there are no big drops in voltage during the course of the mission.

(jeffg) #18

Another round of testing. Log attached.

(jeffg) #19

Still baffled so I documented my parameter settings, reset the Pixhawk, and uninstalled/reinstalled Mission Planner on a computer with a fresh windows 7 image. Basically, started over from the beginning and walked through the entire setup and rechecked every setting and configuration.

I ran another test run and drone did a circle. I reversed the rudder radio and it went straight to the first way point- Wohooo!

Unfortunately, it then lost its mind and went wandering around the harbor. Beginning to wonder if the problem is related to the other boats in the harbor and magnetic interference, but I didn’t see anything in the logs. Can someone take a look at the logs to confirm. Logs attached. Will try again in the lower harbor and again out in the Monterey Bay to confirm.

(gmorph) #20

Hi Jeff. I am analysing the last log you sent - 10-3.

I can see you have RC1 reversed - steering. You just have 1 rudder on this boat right? When in Manual mode do you have the steering stick (whichever is mapped to channel 1) reversed? If so your setting is correct. If not your setting isn’t correct and needs to be changed. Think of it like this - when your in Manual mode ArduPilot isn’t involved. Every input you make simply goes straight through to the motor and rudder. When you steer left if you notice the rudder goes the wrong way then you reverse it on your transmitter right. Now, when your in AUTO mode your transmitter isn’t involved. But ArduPilot also needs to know that the rudder is reversed so you need to make the channel reverse setting in ArduPilot. Make sense?

Your RC3_DZ is 0. This isn’t a good idea - best to leave it at 30. The ardupilot uses this value to know when the throttle is “neutral”. Without it ardupilot might continually move the throttle to try and hit that 0 number.

Your RC3_TRIM is 1556 - that’s a little high but no biggie.

LOG_BITMASK is 3950. That’s not a log of logging and is going to affect our ability to diagnose the issue. Any reason you don’t leave it at the default of 65535 so we get everything logged?

Your FS_THR_VALUE is 1100 whilst your RC3_MIN is 1106. That’s a little too close I reckon. You should be able to drop FS_THR_VALUE down to 1000. Note you don’t have the FS_THR_ENABLE set so its not being used - just thought I should mention it whilst I saw it.

CRUISE_THROTTLE is 52% and CRUISE_SPEED is 1. This is telling ArduPilot that you need 50% throttle to do 1m/s. Is that correct? Try out in manual mode and see how much throttle you need to do 1m/s and then set CRUISE_THROTTLE accordingly. This setting helps ArduPIlot do the math better. Not it won’t affect navigation.

Your BATT_CAPACITY is 33020000. That is a very big number. Is it correct?

Your ARMING_CHECK is checking for GPS_configuration, LoggingAvailable, RC Failsafe, GPS Lock and Compass.
And your ARMING_REQUIRE is set to 0 meaning it will boot and ARM (you have no safety button I see) regardless of what the checks say.

Your AHRS_ORIENTATION is set for 180 degress. So the pixhawk is point backwards. Your compass is external which way is it pointing? Currently you have it set for pointing backwards as well. Remember compass orientation is relative to the autopilot orientation so if your autopilot is pointing backwards and your compass is pointing forward you need to set 180 degree orientation on BOTH.

I’ll keep looking and let you know of anything else I find.

Thanks, Grant