On Thu Oct 23 2014 at 5:05:25 AM Chris Gough <
address@hidden> wrote:
The flight plan is built into the firmware, you need to upload new
firmware to change it. However, this is not the limitation it might at
first seem to be. It definitely does not mean you need to upload new
firmware for each mission!
What we call the flight plan is actually just the top layer of
software, it defines the behavior that the UAV is capable of.
Actually, the flight plan is a turing complete language, it has loops
and conditional execution and variables ("settings"), in theory you
could do just about any computation with it. I think of the flight
plan as the language I use to describe my missions (actual flights).
Put another way, the flight plan is like a class (not an object), each
mission you fly is an instance of the flight plan. Or, you might
prefer to think of the flight plan as the definition of all the
robot's standard procedures.
If your flight plan defines all the behavior you are ever going to
need, then you will never have to change it. This is actually quite
likely if your UAV is designed for a specific purpose. I view changing
the flight plan as a development activity, not an operational
activity.
A flight plan has a fixed number of waypoints, and it's easy to
misconstrue that as a limitation as well. But you can change the
location of waypoints an infinite number of times, so waypoints can
also used like classes rather than objects. Do you really need more
than 256 different kinds of waypoint?
It's fairly typical to start your flight plan with some blocks like this:
<block name="Wait GPS">
<set value="1" var="kill_throttle"/>
<while cond="!GpsFixValid()"/>
</block>
<block name="Geo init">
<while cond="LessThan(NavBlockTime(), 10)"/>
<call fun="NavSetGroundReferenceHere()"/>
</block>
<block name="Holding point">
<set value="1" var="kill_throttle"/>
<attitude roll="0" throttle="0" vmode="throttle"/>
</block>
What this does is wait for the GPS to get a valid fix, then reorient
the relative waypoints around the current location, then wait
patiently with the motor switched off. No need for you to do that
yourself every time you change the location you are launching from,
with Paparazzi you can deal with those things at a higher level of
abstraction.
Chris Gough
On Thu, Oct 23, 2014 at 1:42 PM, MikeK <address@hidden> wrote:
> Thank you for you reply!
>
> I've read through the links you've provided me and it answers most of my
> questions. I would like a clarification though - from what I read it seems
> that you have to build the flight plans into the firmware, upload firmware
> to start flying, and the flight plans in the firmware are static unless
> changed by "misson control"? Or can you upload flight plans after the
> firmware has been loaded?
>
> I suppose what I'm asking is if I need to upload firmware for each flight
> plan, or can I send a message from an event on the GCS computer to trigger a
> particular flight path after firmware is loaded? I essentially want to
> receive a GPS coordinate(s) and send the drone there and back without
> needing to build the firmware, if that's possible.
>
> I know there's two different paparazzi modes for the AR Drone 2.0
> http://wiki.paparazziuav.org/wiki/AR_Drone_2/getting_started_advanced#Inroduction
> - this only really deals with the control loop and nothing to do with the
> flight plans and the like, correct?
>
> Thanks again
> -Mike
>
>
>
> --
> View this message in context: http://lists.paparazziuav.org/Command-line-autonomous-flights-with-Parrot-AR-Drone-2-0-tp16259p16285.html
> Sent from the paparazzi-devel mailing list archive at Nabble.com.
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
--
.
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel