After batt monitor enabled you need to reboot or refresh parameters to get BATT_CURR_PIN parameters.
1 Like
I know that already done, I can’t set the current pin on batt2
I agree with @kalai1219. The BATTx_ parameters are a little special in that they don’t all appear until the autopilot is rebooted. Some appear after a simple parameter refresh but not all. Also the parameters that appear depend upon the BATTx_MONITOR that has been selected. So perhaps you didn’t set BATTx_MONITOR = 4 (Voltage and Current)?
To use it as liquid level PWM I need to set the BATT2_MONITOR to 12 and then the I don’t have the option to choose current pin
Perhaps I’m misunderstanding something but when I set BATT2_MONITOR to 12 I see the CURR_PIN
Ah, maybe you’re trying to use the Mission Planner’s Battery Monitor 2 page which may not provide the full list of possible pins. If this is the case, then I think you should stick with the full parameter list (shown above).
Hi all, two issues with this version 4.4.0 (I upgraded from a two year old FW so this may have happened in previous versions)
If I have to go back to previous version then fine but when did this change so I can go back?
BTW OA_type is set to 0
-
in survey grid the drone is now back to going to the waypoint, stopping turning then going to the next WP. This was not the behavior before where it would slow down and do a nice arc to the next waypoint. (without using spline) This was sweet. When did this change back to stopping? and how do it fix it?
-
When adjusting the landing position in RTL the drone can barely be moved with full stick movements. It would take about 10 seconds to move it 5 feet. This is dangerous as you pretty much can’t re-position the drone in any timely fashion. The drone banks quit well at first but then it re-levels on it’s own and just sits there barely moving even with full stick movements. In pos_hold it files as expected. This is only happening on repositioning during RTL that I can see.
Any help appreciated.
Hi @steve,
I suspect that the issue is the WPNAV_ACCEL parameter has been set very low. The default is 250 so perhaps try something closer to that.
If you have a log file then we can look into this further.
Thanks greatly for the reply.
WPNAV_ACCEL , 100
WPNAV_ACCEL_C, 0
WPNAV_ACCEL_Z, 100
WPNAV_JERK, 1
All were the same on FW 4.1.5 (except ACCEL_C did not exist)
Slower repositioning during landing in RTL (or Land mode) is a change in behaviour introduced in 4.3 and the top speed is 0.5 x WPNAV_ACCEL. So with WPNAV_ACCEL=100 it will be 50cm/s. So 5 feet is 1.5m so that should take about 3 or 4 seconds. We have thought of adding a parameter to allow users to directly change this but we got through 4.3 without anyone requesting it so I suspect there’s something else going on in the vehicle configuration that is making it especially slow.
… a log file would be great. As we say, it’s all guesswork without a log file (aka onboard log, aka .bin log).
Hi @rmackay9 Please see attached log. Everything was perfect until I did the upgrade.
When I tried to load my parameters it stated 62 were missing, I spent an entire day trying to get MP not to say it was missing all the params (yes I realize you have to load it twice etc.) finally I gave up and just worked with what it loaded fixing all the things manually as I went.
Also the static notch filter is now greyed out in MP, not sure why that is either.
Sounds like Scurve was introduced after 4.0.7
We have hundreds of flights as it was with no issue. It would be nice if major changes like this were optional 
My log is too large to upload here I will have to put it somewhere and link it.
Here is the link
5 feet in 4 seconds is waaaay too slow… can we get an adjustable param that we can put that back to 1.0x WPNAV or something to that effect? It should just act the same as if you are in POS hold mode.
The reasoning is you are used to flying around in Pos hold mode (as we do for the first flight of every day to ensure it holds position before sending it off on it’s mission) then all of a sudden in RTL it behaves completely differently. This is not good for the pilot.
I think I will go back to 4.2 and see if that at least gets the RTL behavior back (there is no way I can return the drone to my client with RTL movement so different than before). I am doubtful it will correct the waypoint navigation issue.
I would have stayed on my previous version forever but for some reason UAVCAN kept thinking my compass was missing randomly. Which is strange because all our drone are on the same FW and this was the only one which would get a messed up compass. I have 5 drones with about 200-300 hours on each. This is the first time I have had so much trouble.
You are not supposed to update old 4.1.5 parameters into an newer firmware like 4.4.0
Updating the firmware automatically updates the parameters from the old firmware and changes them if necessary to preserve old behaviour. Just like you want and need.
Overriding that automation, by manually uploading old parameters, does not preserve old behaviour. This is somewhat counter intuitive, but it is the way it works.
It makes it easier to update firmware. You only need to upload 4.1.5 parameter file if you downgrade to 4.1.5 firmware.
Again, when updating there is no need to manually load any parameters, no need for any parameter upload.
When downgrading firmware version you must manually load a parameter backup file created with that specific version that you are downgrading to.
3 Likes
One other thing, use loiter instead of poshold. It it better in every aspect.
2 Likes
Amilcarlucas,I never new that loiter was better than POS hold,will start using Loiter from now,and thank you for this little bit of excellent knowledge,your a star
yes I agree, but I assume there are times when using a param file is required
- a new drone build on a new FW should be able to use 90% of the old param file
- if you reflash back to arduplane then back to copter, you would need to load a param file
for clarity here I had to manually adjust things that changed like this
“GPIO pins configured by setting SERVOx_FUNCTION to -1 (also see SERVO_GPIO_MASK. BRD_PWM_COUNT removed)”
I have tried both, pos hold is better for my use case.
Looking at the release notes
Copter 4.1.0-beta1 14-Apr-2021
Changes from 4.0.7
h) SCurves for waypoint navigation
Scurve introduced in 4.0.7 and I was on 4.1.5 so I was flying with Scurve and I was happy with it…
I wonder why then when I went from 4.1.5 to most currnet 4.4.0 does it now stop at each waypoint and not use Scurve?
Does it have anything to do with using survey grid mode? I wonder if it would use Scurve on a standard waypoint mission.
Seems like we know why the drone is sluggish in RTL but the curves between WP behavior is still a mystery.
@amilcarlucas I have done the following for testing today
- downgraded the FW to 4.1.5
- loaded on my known working param set. for that FW version
- upgraded the FW to 4.4.0
- I did not load my old params from 4.1.5
- adjusted required settings such as
a)MOT_PWM min and max set to 1000 and 2000
b) Servo 13-15 function set to -1
Nav_acc is still set to 100 (I have never changed this value on a copter) I will try 250 today as well.
I can’t imagine this changing anything but it’s worth a shot.
After this I will go back to 4.1.5 and see if it still stops at the waypoints in survey. If it does not then I have to move forward in versions one at a time until the compass UAVCAN issues are resolved but does not to the stop and go at waypoints…
UPDATE
I rolled back to 4.1.5 and it flies as it should through the corners and RTL behaves properly now as expected.
My compass issues I had with that drone seem to have gone away magically…
The reason I updated was because every few times this drone was flown if you clicked “setup” then “manditory hardware / compass” it would say the compass changed and then it would toilet bowl, I assume it was using the internal compass. I tried delaying the boot so that the compass could be found etc but it did not help.
Now after many power offs and on (waiting 15 min between) it seems to have stopped losing it’s compass.
So in light of the new RTL sluggishness and not being able to get scurve working on 4.4.0 I will be sticking with 4.1.5 (unless the compass issue rears its head tomorrow)
Hi @rmackay9
Will there be a chapter dedicated to FC with ESP32 in the official wiki? It would be interesting to have “easy” documentation to do some experiments.
Thank you
1 Like
I’ve never used the ESP32 myself so I don’t think I could come up with the but I’ve created a wiki to-do item and perhaps someone who is more familiar with the setup will fill out this page.
FYI @DavidBuzz
1 Like