HontaiTec Quadcopters (HT F801, HT F803,...)

Just tested a bunch of settings at Rudder packet (01-3F,00-40, 02-3F.....) Can't stop the yaw drift
Setting the rudder packet fixed at neutral value, doesn't drift at all, simply perfect.
Setting the rudder packet at stock value (00-3F), my yaw drift is not constant. Sometimes you can see totally locked and sometimes you can see very very slow drift, or very very small yaw "hits".
Could be related with the flag included in this byte? (video)
Is night here and can't continue my tests (too much loud and family is sleeping )

Durete wrote: @Greenfly. Please, test this build:
dl.dropboxusercontent.com/u/14941708/dev...rudder%20neutral.zip

With this build you will have all directional controls but rudder (fixed at perfect neutral stock value 0x20)

Please, if you have yaw drift with this build, could you try to calibrate the quadcopter's gyro/acc using stock tx? I explained to you by private some days ago.

I calibrated and the yaw was pretty stable... no drift.

hexfet wrote:

greenfly wrote: It seems slower.

As it should since only the trim is being changed.

greenfly wrote: Strangely, it has a yaw drift to the left. Not dramatic but noticeable.

Please try forcing the elevator byte to 0x20 also. Wondering if there's some interaction with yaw since we're sending 0x1f as center for elevator as well.

Well I forced the elevator byte to 0x20 also and there no longer seems to be any drift. Unfortunately, I am a bit lost as to what is going on so I can't tell if that is significant.

What should I be trying now?

I've pushed code that updates the channel scaling routine to match the center values expected by the stock tx (it now rounds away from zero). Hopefully this will fix the drift issue. Please test that when you get the chance.

Hexfet, now I get a definite left twist when I throttle the quad up.

- I tested with the stock TX to make sure the quad could fly
- I cloned your repo in a clean new space to make sure it was nothing I had changed.
- I built and loaded it twice just to make sure

Sorry.

Just to make you feel better, three of my motors went out this afternoon. Luckily I had a spare set I got free (long story), so I was soldering this evening. Now I'm up and flying/crashing again.

Interesting Let's see what result Durete has with this code. When we first looked at yaw drift both had it but in opposite directions. Would like to know if that's still true.

Is it a left twist as you accelerate upwards, and/or while hovering?
Does the channel monitor show the AER outputs all at zero when you throttle up?

Thanks Hexfet.
I didn't test yet your latest code. I wil try as soon I return home from work.
Accoding my tests, the only packet affecting the yaw drift seems to be the rudder packet (as expected).
I compiled a bunch of builds fixing every single channel, and trying different combinations.
I can't speak about any drift at aileron or pitch channels, because this small quadcopters always drift a little bit since they don't have GPS or other sensors, so maybe there were any aileron/pitch drift but is difficult to see.
With this packet at neutral value, didn't drift at all. Simply perfect.
Wil report in a few hours.

Thanks for your hard work guys

Yeeeeeaaaaahhhhhhh!!!!!! It's perfect now !!!!!
The drift has gone !

Test build with latest Hexfet's code:
dl.dropboxusercontent.com/u/14941708/dev...ease%20Cantidate.zip

I will test now adding the trim packets....

Just tested adding the trim packets. The yaw drift returns, and I think probably Aileron and Pitch also drifts.
I tested adding this code to latest Hexfet's code:

I only added -16,16 as limit for trims because according my previous tests seems to be the maximum value allowed by the receiver. Increasing this value the behaviour reaching sticks limit is weird.
Adding driving trims seems to increase slightly the rates, but not too noticeable. I don't know if worth to add this change . Not very sure.

Test video with latest Hexfet's code (with trim packets fixed at 0 ) uploading....



Last 10 20 seconds I didn't touch the rudder stick, As you can see the yaw is perfect Sorry for the out of focus recording

hexfet wrote: Interesting Let's see what result Durete has with this code. When we first looked at yaw drift both had it but in opposite directions. Would like to know if that's still true.

Is it a left twist as you accelerate upwards, and/or while hovering?
Does the channel monitor show the AER outputs all at zero when you throttle up?

Honestly, I can't seem to keep a good hover. It veers off to the left too quickly for me to fly it well.
Let me give Durete's builds a shot and report back after testing.

Thanks

Durete wrote: Just tested adding the trim packets. The yaw drift return, and I think probably Aileron and Pitch also drifts.
I tested adding this code to latest Hexfet's code:

packet[7] = scale_channel(CHANNEL1, -16, 16); // aileron trim (range -16, 16)
      packet[8] = scale_channel(CHANNEL4, -16, 16); // rudder trim
      packet[9] = scale_channel(CHANNEL2, -16, 16); // elevator trim

I tested this change in the emulator and at center sticks we are sending exactly the same data as the stock tx. The quad should behave the same as when the channels are forced to 0x20 and the trims forced to 0. Does the channel monitor show zero for AER and the subtrims are at zero? Can't think of what else might cause an non-center value to be sent.

hexfet wrote:

Durete wrote: Just tested adding the trim packets. The yaw drift return, and I think probably Aileron and Pitch also drifts.
I tested adding this code to latest Hexfet's code:

packet[7] = scale_channel(CHANNEL1, -16, 16); // aileron trim (range -16, 16)
      packet[8] = scale_channel(CHANNEL4, -16, 16); // rudder trim
      packet[9] = scale_channel(CHANNEL2, -16, 16); // elevator trim

I tested this change in the emulator and at center sticks we are sending exactly the same data as the stock tx. The quad should behave the same as when the channels are forced to 0x20 and the trims forced to 0. Does the channel monitor show zero for AER and the subtrims are at zero? Can't think of what else might cause an non-center value to be sent.

Yes. All channels at Zero, without any trim. I neither understand it

Durete wrote: Yeeeeeaaaaahhhhhhh!!!!!! It's perfect now !!!!!
The drift has gone !

Test build with latest Hexfet's code:
dl.dropboxusercontent.com/u/14941708/dev...ease%20Cantidate.zip

I will test now adding the trim packets....

I tested the release candidate version and it does fly smoothly. I'm not sure if I am building it wrong or there was some other change... but I will wait until it stabilizes before I try it on my own again. Great job guys!

Just return home from some flights outside using latest Hexfet's code (with trim packets at zero). Super funny using my Devo instead the stock TX .
I only observed a weird behaviour changing the power setting after bind the quadcopter. When you change the power setting, the quadcopter loose bind, and you need to reset everything (quad and TX) to recover connection. In fact, I think the power setting is not working since I tried some range test and I could walk for about 70 meters at 100uw without loose bind

@Greenfly, in case you want to test latest code using trim packets, here is my compiled version:
www.dropbox.com/s/i0w7m25qwvqxfn6/deviat...ith%20Trims.zip?dl=0
Only to confirm you have drift using this build.

Great team job guys!

Thanks for testing We could stop here if we fix the trims to zero. If y'all are up for more investigation here's what I'm thinking. I'm fine with either choice.

Summarizing:
1) Setting channel and trim data in packet to fixed values sends "20 20 20 00 00 00" to receiver and results in no drift.
2) Setting channel data based on centered sticks and fixing trim values to zero sends "20 20 20 00 00 00" to receiver and results in no drift.
3) Setting channel and trim data based on centered sticks to "20 20 20 00 00 00" results in yaw drift.

If there's a problem it seems likely to be in the trim values being sent. Not sure what I'm missing because the trims look correct, at least with my emulator build. Durete, can you build the emulator (with the driven trims) and verify that #3 is true for your build? Greenfly you might want to try the same and make sure the result is the same. The emulator will print the packet data.
Next step would be back to a receiver capture to verify the correct data at the receiver.

I will try the emulator, but maybe I will need some help using it since I never user before
I will compile the emulator using this command under MinGw:I'm right?

@Hexfet
I am I'm trying to understand how the *scale_channel* function

is supposed to work when you do something like...

In this case, wouldn't the <range> be incorrect?
It seems like all the aileron stuff is reversed. so I am guessing it needs to be ranged like that.
IDK... I'm just not sure it works the way you want it to with a reversed range (destMax is NOT greater than destMin)

I'm just guessing. I do not know enough about the whole module yet to really know for sure.

Just tested the emulator (very interesting thing )
I can't see any strange behaviour. According the emulator is sending the right packet always, but in real world is not right

@Greenfly and Hexfet.
The right order, and maximum values at Trim packets according my tests should be:

greenfly wrote: @Hexfet
I am I'm trying to understand how the *scale_channel* function
IDK... I'm just not sure it works the way you want it to with a reversed range (destMax is NOT greater than destMin)
I'm just guessing. I do not know enough about the whole module yet to really know for sure.

It does produce the correct result for both low-to-high and high-to-low ranges, including negative values (thank goebish!). Should probably rename those parameters (and clean up the round line). It's scaling the deviation mixer output range (-10,000 to 10,000) to the ranges used by the quad. Makes it easy to scale the channels to different ranges.