Recent Posts

Pages: 1 ... 6 7 [8] 9 10
71
It would help to know exactly how you want to use this:
- in this run only, or come back to that place some other run or day?
- just station keeping there or a waypoint on a multi waypoint course?
- would it be OK to use the GCS before or after the run, just not during the run?

Are you aware that GPS readings for a single location can easily be different by several meters some time (hour+) later?  GPS is only accurate to about 5 meters.  Modern drones enhance this with visual recognition to land where they took off.

There is also a capability of running a python script.  That is associated with waypoints.  With writing a python script you have access to everything, including HomeLocation PoiLocation and the currently loaded waypoints.  Writing a script is a programmer thing though.  Script could be just "add a waypoint here then do X (say position hold till flight mode changes)"?  That would still require you to save the waypoints (using GCS) after the run if you wanted to use them another day.  To make it save/load to settings memory and not need the GCS at all would be a task for a developer who could work with the LP source code.

I don't think there is anything you can do to set a waypoint from a transmitter switch, but there is a thing called Point Of Interest POI in the flight modes.  I have never used it and am not sure what it does.  It may not be helpful in that it only keeps the vehicle (VTOL intended?) pointed at the POI?

There are also transmitter scripts that can be written and some already written on the internet.  That, combined with transmitter telemetry and a possible GPS addon for the Rx could do something, but that seems like a hack if you are using an FC already.
72
Hi!

I’m planning to make a bait boat using an FC with GPS, and I see a bunch of ready to use boats are using the transmitter to trigger a waypoint set. Is it possible to do the same with librepilot, or I’ll have to use Librepilot2Go with bluetooth?

Thanks in advance!
73
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.
74
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.
75
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?
76
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.
77
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.
78
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?
79
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.
80
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
Pages: 1 ... 6 7 [8] 9 10