Replies: 4 comments 12 replies
-
INAV ready provides most of the infrastructure to do this:
INAV (and EdgeTX) also provide / facilitate MSP over CRSF and S.port, so no infrastructure should be necessary, either on the FC or TX. There are open source examples of doing all these things. Implementation requires doing some research and some LUA programming on the TX. |
Beta Was this translation helpful? Give feedback.
-
Reasons for Required Changes:Whilst it is appreciated that the infrastucture might be partially there, currently this is something that is only somewhat possible when connected to a Ground Control Station and there is no LUA script currently avalaible. MSP over CRSF and S.Port are part of the solution, but not the whole story. The reasons why some changes to the infrastrucutre are required are:
Additional Context:There may be a case where the transmitter stops sending the required information for The configurator on the other hand would have to allow for failsafe behaviour to be a choise between I hope this makes it a bit clearer in terms of how the feature should be implemented to cover all angles. |
Beta Was this translation helpful? Give feedback.
-
I honestly don't think this is a good idea. DJI have all the collision detection sensors to try and stop their drones from hitting objects or people. INAV doesn't have that. So I would not want to see transmitter based follow me on safety grounds. If people really want it, Stronnag has a solution higher up. |
Beta Was this translation helpful? Give feedback.
-
Responses:@b14ckyy in response to your comments and questions:
Possible solutions:
Of course you would also make sure that you can lock all input, so that you don't do something unintentionally. Regarding the following:
You do hear announcmenets from the radio such as: "Telemetry Lost" or "RSSI Critical", and with the Bluetooth mod, you could even hear it in your bluetooth earbuds. There are hunders of solutions to this problem. I agree with you on this one completely:
Essentially, this is all I was saying from the beginning. If we could distinguish between three different locations, it would make life a lot easier. In the mean time, I'll work on the MSP over CRSF, as suggested by @stronnag and maybe I'll manage to cobble something together. The only thing I would add is just a I menrtioned this previously here:
@MrD-RC in response to your safety concerns: Safety is a function of many varibales, some of which we can control and other we can not. That's a fact of this hobby that none of us would be able to change. There are general safety concerns about any automated flight, not just Any power loss situations, such as failure of an ESC, a prop getting loose, etc. may result in a crash. Otherwise, that safety concern you have should be equal for all automated flight modes and in this case I would like to ask you: Are you indirectly proposing for all automated flight modes to be removed in future versions of INAV? - Kind of defeates the purpose of INAV, doesn't it. If not, then the safety aspect of this debate is settled. If yes, then please explain how Summary:Adding Safety concerns voiced by @MrD-RC and @b14ckyy over additional flight modes such as |
Beta Was this translation helpful? Give feedback.
-
Current Behavior
At the moment, the HOME location used by INAV for each flight is defined as the location where the aircraft takes off.
Desired Behavior
The user should have the option between two RTH modes:
RTH
(return to home), where "home" is defined as the takeoff location of the drone / planeRTO
(return to operator). where the "operator" or defined by the GPS coordinates of the transmitter used by the operatorRadios like the popular Radiomaster TX16S allow adding a GPS receiver to one of the two available USART ports using cheap GPS recivers like the Beitian BN-220. My suggestion is to have two additional telemetry items called "
GPSt
" (GPS of Transmitter) and "ALTt
" (Altitude of Transmitter) which would report the GPS location and the altitide of the transmitter back to the drone / plane.This would allow for the addition of two or more functional navigation modes such as:
RTO
, i.e. return to operator, as described above.Follow-me with fixed altitude
: The drone / plane returns to the operator's location but does not land. Drones would then hover at that location, whilst planes would step into a temprary loiter mode until the location of the operator changes by either the specified loiter radius, or an independently defined variable. The height would be defined as a distance above the operator, the calculated RTH altitude after take-off or an independently defined variable.Follow-me with adaptive altitude
: This would be similar to the simple "follow-me" mode, with the crucial difference that an altitude offset between the drone / plane and the transmitter would be defined by an offset value, rather than a static value.Suggested Solution
The solution is to liaise with the EdgeTX and ELRS development teams, to add Trasmitter Telemetry for bi-directional telemetry between to accomodate for those two additional values, i.e. "GPSt" and "ALTt", to be transmitted to the drone / plane.
Who does this impact? Who is this for?
I think that this would be a great feature to have for anyone who is looking to fly autonomously whilst being on the move. This "follow-me" fature is used a lot by DJI pilots who fly drones with vision based "follow-me". It would open up a whole new set of possibilities for INAV and the usega of it and it would make a great feature that other RTF drones have.
Additional context
RTH
andFAILSAFE
behaviour would remain the same as now and no changes are required to those two modes.Something similar has already been implemented by @rotorman (Risto) for the Yaapu Telemetry script here, but it only happens on the transmitter side, not the drone side.
Beta Was this translation helpful? Give feedback.
All reactions