81

Vehicles - Helicopters / Re: Convert racing controller PIDs to CC3D

« Last post by TheOtherCliff on July 17, 2022, 01:41:40 pm »

Hmm...

By the time the sensor data gets into a UAV where you can see it, it is already converted into standard units and floating point.  For instance GyroSensor is in degrees per second.  The PID comes later than that.

The raw gyro sensor data is scaled to be float degrees per second in flight/modules/Sensors/sensors.c and put in GyroSensor with GyroSensorSet().  It goes into GyroState from there and every time that changes, innerloop.c gets the values and puts them into gyro_filtered and that is what the PID acts on.

There seems to be a hold over from the days of integers though.  The PID code multiplies the inputs by 1000 at the beginning and divides by 1000 at the end.  This kind of looks like scaling to avoid integer overflow / underflow and tastes like the old days of direct hardware access, but it might be some reasonable required scaling.  Maybe just to match the values used in the integer days.  I cringe when I think about it, but it is only 500 x 2 x ?6? = 6000 FLOPS so it isn't really worth a special version to take it out.

82

Vehicles - Helicopters / Re: Convert racing controller PIDs to CC3D

« Last post by jcg1541 on July 17, 2022, 09:09:16 am »

Just some general musings:

OP/LP tries to create settings that are based on measurement units (e.g. degrees per second, seconds, meters, meters per second per second) and use floating point to allow some of it (e.g. very small numbers).  Even within OP/LP there are simplifications to make e.g. tunings into "unitless" numbers 00-99 (Stabilization -> Use Basic Configuration View).

Good point. I looked at both CC3D code and racing clean flight code, and I couldn't easily tell whether degree or radian was the unit from the gyro sensor. I could tell for sure though that both CC3D and clean flight treat the gyro sensor input as-is in the core PIDs code. Neither CC3D nor clean flight try to do unit conversion leading to the core PIDs loops.

83

Applications - FPV / Re: MinimOSD - where are they?

« Last post by trust on July 05, 2022, 06:21:14 pm »

I did some more searching for schematics and looked on Hobbyking, and found two different versions of this OSD - seems to use the same two main chips.
Anyone use these versions?

84

Applications - FPV / Re: MinimOSD - where are they?

« Last post by trust on July 05, 2022, 05:59:46 pm »

Thanks for the reply.
As I pointed out in my note, I did try Amazon, and they canceled the order after two weeks when the vendor didn't actually ship anything and I complained. There is only one vendor showing this product. They STILL advertise it, BTW.
For the time being I'm moving units from planes I'm not flying much to new test planes - the data I get is valuable for diagnosing flight characteristics.
But I'm still interested in building some.

85

Applications - FPV / Re: MinimOSD - where are they?

« Last post by TheOtherCliff on July 05, 2022, 12:06:42 pm »

I would just try a different seller, just don't bother trying eBay for that, they are $40 each there for some reason.

Amazon wants $9.  I would probably try there.

86

Applications - FPV / MinimOSD - where are they?

« Last post by trust on July 04, 2022, 07:10:23 pm »

I've used a lot of these over the last 2 years and like the programmable aspects of them.
But recently I tried to purchase 3 more and the shipment first "appeared" to ship to a site in NJ, then "magically" appeared in my mailbox the same day (3000 miles away). Which it didn't. Still fighting with Aliexpress on that one.
Tried Amazon. Two weeks later, say they shipped, but no tracking number - Amazon got wise and refunded my $.
  Looked on the PCBs - there's two main chips, AT7456E (the OSD chip, MAX7456E?) and an Atmega328P processor. The first appears to be obsolete, although I did find what appears to be a copy made by Zhongkewei available. The 328P can be had if I want to wait till July.
  Are there any of these PCBs out there from a reliable source?
I'm considering making a bunch (like 25 or so) if I can really get the parts. Is there a PCB schematic or layout available?
Any decent alternatives?

87

Vehicles - MultiRotors / Re: GPS modes oscillations

« Last post by vgwit on June 25, 2022, 07:33:13 pm »

Thank you for the info.

There is no more slow oscillations.
I don't use OPlink (use MinOPOSD via MSP). The quad does not shift in VR or PH mode after 180 deg yaw.
In Attitude mode it also does not shift in windless situation and there is no oscillation.
Only in GPS modes.

88

Vehicles - MultiRotors / Re: GPS modes oscillations

« Last post by TheOtherCliff on June 24, 2022, 01:14:15 pm »

(see threads linked at bottom for details)

At least one of these is related to running OSD / telemetry.  Are you running one of these?  For a test, you could get it back to happening again and then try disabling OSD / telemetry.

Another is related to bad sensor (accels) calibration with an explanation that makes sense.  If you do a slow pirouette in VelocityRoam mode does it move away (say a meter or more) during the first 180 of the pirouette and come back as you approach completing the 360?

At least one of these (for me) only happens if the drone is facing south.  For you it may be a different direction.  For me that explains why it happens some times and not others.

If you turn off OSD and it goes away.  It appears that the way the high priority telemetry protocol (1ms-2ms window for reply) is coded, that it interferes with the high priority stabilization task, or that there is am OSD buffer full issue and it waits for room in the buffer.  There is a forum thread that discusses this.  It is just possible that it is caused by running too slow of a data rate for the amount of OSD / telemetry data that is being sent and increasing the data rate (just for a test if that makes your OSD / telemetry unusable).  I would have to refer to the thread for details; its been a while.

The slow one that happens with DJI Naza GPSs can be helped with a DJI GPS code patch (there is a forum thread that has code and binaries) that artificially removes the data smoothing that happens in the GPS.  Same issue can be seen with a Ublox GPS if you set the UbxDynamicModel to Pedestrian or the like, which does a lot more smoothing than Airborne 1-2-4G.  Maybe setting the GPS baud rate or report rate (UbxRate) too low might cause it too.

I have seen that the slow oscillation occurs in steps and that the steps are at the speed of the fast oscillation.

----------------------------------------

so it seems the fast oscillation is caused by bad accel calibration (test in Attitude mode with neutral tx trims or just recalibrate accels)
and the slow one is caused by telemetry/OSD (low baud rate / buffer full ?) conflicting with stabilization (disable telemetry/OSD for a test)

----------------------------------------

https://forum.librepilot.org/index.php?topic=4923.msg33063#msg33063
https://forum.librepilot.org/index.php?topic=4941.msg33301#msg33301

89

Vehicles - MultiRotors / GPS modes oscillations

« Last post by vgwit on June 24, 2022, 09:54:18 am »

It looks like attention to the progect is fading but have decided to post my experience nevertheless.

Have solved the problem with slow quad oscillation (toilet bowl) in GPS modes. It was caused by an interference/noise from Runcam2 camera to GPS module GN-801 that was sitting upon it. After moving the GPS by 5 cm back the problem has gone.

Now I'm focused on minimizing/removing fast oscillations in GPS modes. Its frequency is 5Hz and looks like it is the same as UbxRate setting in GCS. As these oscillations present in both PH and VR modes settings like ...VelPID hardly can help. Have tried to decrease HorizontalPosP but without obvious result. I'd try to decrease D part of  PID PH algorithm but can not find it. Only P part available.

Magnrtomeret calibration was repeated many times. No change.
Thanks for attention.

90

Applications - Autonomous Flight / Re: Voltage / Current Sensor Ground Issues

« Last post by TheOtherCliff on June 22, 2022, 02:41:28 pm »

Some ESC's BECs have two LM7805 5v regulators in parallel.  It has been my assumption that paralleling ESC's BECs would be similar to what is already going on inside a single ESC.  I know that this will put more load on one than another, due to manufacturing tolerances.  I leave my 4 ESC BECs connected in parallel and I can tell that one gets warmer than the others because it is the one actually being used (highest voltage) leaving the others basically switched off.

I have heard though, that it is not good to parallel switching BECs...

About: Current Sensor Ground Issues
Setting up a proper single point ground is one of the solutions I thought about and the correct way to do it.  Problem is that cheap sensors are leaving the BEC unpopulated now days, and that basically means a single ground is difficult to do (or requires adding a BEC at the current sensor for sake of the FC ADC).

If it was a simple matter of power wires with varying ground potential along the length; with sensor in one place and ADC ground in another, then a fix of having a current to voltage tweak seemed a simple fix.  I coded it up and it seems to work.  I will flight test it next flying session.