Replying to myself.
Even position hold, loiter and alt, hold are keeping perfectly the altitude (with or without wind) going forward in a mission altitude in between way-points is very far from perfect.
Adding a delay of few seconds at each way-points shows that the aircraft is regaining lost altitude from the last way-point.
Just for reference the aircraft is:
Aircraft is:
Very small quad (550mm {21.65 inches} ) motor to motor.
Total weight including graphene batteries 4S 8A: 2.7 kg
18 x 5.5 Quanum CF props
Turnigy dlux 80A ESC driven at 400Hz (not 490 which is the default I think)
Turnigy Multistar 4830-480Kv 22 Pole motors.
Separate 2S5A battery and linear 5V regulator for FrSky Rx, Pixhawk, GPS and external compass.
Telemetry to and from laptop link is RFDESIGN 900+ driven at -30 dBm.
Telemetry for batteries (cell by cell measurement) not total value which has no meaning: Quanum 2.4GHz
In response to the question: (why you are running the escs at 400hz?)
Tests ran on this specific speed controller showed better response time in large difference of speed with:
18 x 5.5 Quanum or 18 x 6 T-Motor props
Turnigy Multistar 4830-480Kv 22 Pole motors.
Tests I made were done (on the bench) with optos to measure rpm of props in relation to PWM values in microseconds to stable rpm. (including speed overshoot and undershoot).
I can’t say why it is much better at 400 instead of 490 Hz repeat rate (Empirical but works a treat).
What I can say is that with this particular configuration (motor / prop mentionned above) is that I never had large slipping (speed wise) or any other misbehaving.
Photo of the rig would probably scare a lot of people It did crash so many times that the weight of two parts epoxy glue is probably larger than the weight of the four wooden arms! LOL
Henrik,
Thanks for testing, great to hear that it’s going well. If it’s a pixhawk I wouldn’t expect 400hz to be better than 490hz, I think that internally the maximum rate that the pixhawk is capable of is 400hz so even if RC_SPEED is set to 490hz I think it will only do 400hz. I haven’t checked this but it’s my understanding.
In any case, thanks very much for testing and reporting back!
rmackay9
Interestingly I didn’t measure the repeat frequency out of the pixhawk. I just look at the number (mission planner) and set the value in my pwm <–> rpm tester.
So thank you for the information. I’ll place a scope on the Pixhawk output to “have a look”
I do realize that the little test I conducted is only valid for the ESC / Prop size mentioned. It could be very different with other setups.
So far, only strange behavior is on a mission (loosing a bit of altitude while going forward to the next way-point) and recovering lost altitude if a 3 to 5 second delay is added at each way-point.
Pixhawk is completely enclosed in a box so no propellers wind or other external on air pressure sensor can be involved. Hence I don;t know what to look for.
We also see no issues at this time with RC5. It currently is loaded on one of our Centurion Mark III test beds and is performing well in all flight modes at the default configuration.
Taranis Tx just used to arm and switch to the “Auto mode”.
Auto take off to specified altitude: Perfect
Numerous way-points at various altitude and different speeds in between way-points: Very good.
Last three way-points in decreasing altitude to a 30 cm/S descent for the last two way-points: Excellent.
Last order in the mission was RTL:
Landed 14 centimetres from take off point! (good enough for me
Landing detector is really perfect now.
Motors stops worked without any glitch!
FYI: As I refuse to join the Power side {motors esc} and sensitive electronics grounds, I’m using this: Batteries stand alone telemetry which survey cells individually. (Not total voltage which has no meaning). Alarms are visually and audibly available on the small telemetry Rx
@LuisVale:
If the FrSky measurement box do not link the 0V (GND) of the battery and the 0V (GND) of the receiver then it could be a good solution. I do not know if the two grounds are linked or not.
Perhaps you could let us know (using an ohmmeter)?
Thank you in advance
Henri
I have a copter with 2 of these flvss sensors installed. I think that your suggestion is correct, that they don’t have the battery monitoring ground connected to the rx ground, but to be sure, I will check and report back. To be honest it would have to be disconnected to be able to have 2 of these things monitoring cells of 2 batteries connected in series, and I believe that this is a suggested configuration using these devices. I’ll double check in any case and let you know today.
I have tested and the LiPo monitoring pins (where you would connect your balance connector) is completely independent of the smartport ground (which connects ultimately to your rx). So no common ground as expected.
It did crash so many times that the weight of two parts epoxy glue is probably larger than the weight of the four wooden arms! LOL