paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] coding problems with multilib


From: Chris
Subject: Re: [Paparazzi-devel] coding problems with multilib
Date: Tue, 23 Oct 2012 16:13:30 +0300
User-agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1

i know Felix as they are loaded from the makefile now.
Now that i had a second look i think i will agree with you and move all the relevant module
definition from the airframe file.
Thank you again for your time.
Chris


On 10/23/2012 06:11 AM, address@hidden wrote:
Send Paparazzi-devel mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Paparazzi-devel digest..."


Today's Topics:

    1. Re: coding problems with multilib (Chris)
    2. Re: coding problems with multilib (Felix Ruess)
    3. Re: 4-Dimensional Trajectories (4DT) (Bernard Davison)
    4. Re: 4-Dimensional Trajectories (4DT) (David Conger)


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

Message: 1
Date: Mon, 22 Oct 2012 20:46:29 +0300
From: Chris <address@hidden>
To: address@hidden
Subject: Re: [Paparazzi-devel] coding problems with multilib
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

If this means anything i solved the problem by moving the required
definitions from the airframe to the
module xml file.
I don't think this is normal  as it used to work like this but anyway......
Chris




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

Message: 2
Date: Mon, 22 Oct 2012 19:58:35 +0200
From: Felix Ruess <address@hidden>
To: address@hidden
Subject: Re: [Paparazzi-devel] coding problems with multilib
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

It is normal and intended that way: if you add defines in a <section> in
the airframe file, they will be added to the
var/airframe_name/generated/airframe.h file.
So these defines are only available in files that include
generated/airframe.h
If you add defines in the firmware node, or in the module node, they will
be passed to gcc on the commandline via -Dfoo=bar, so they are defined
globally...
IMHO, for modules it is nicer to define them in the appropriate load node,
so it's clear where they belong to...

On Mon, Oct 22, 2012 at 7:46 PM, Chris <address@hidden> wrote:

If this means anything i solved the problem by moving the required
definitions from the airframe to the
module xml file.
I don't think this is normal  as it used to work like this but anyway......
Chris


______________________________**_________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/**mailman/listinfo/paparazzi-**devel<https://lists.nongnu.org/mailman/listinfo/paparazzi-devel>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.nongnu.org/archive/html/paparazzi-devel/attachments/20121022/b4fed6b2/attachment.html>

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

Message: 3
Date: Tue, 23 Oct 2012 08:06:02 +1100
From: Bernard Davison <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Paparazzi-devel] 4-Dimensional Trajectories (4DT)
Message-ID: <address@hidden>
Content-Type: text/plain;       charset=utf-8

Guys don't forget about the obvious...
Usually Commercial aircraft fly to schedules. They take off at a time and 
arrive at their destination at a time. (We hope. How annoyed are we when our 
flight is late)

Cheers,
Bernie.

Sent from my iPad mini.

On 22/10/2012, at 11:16 PM, Reto B?ttner <address@hidden> wrote:

Hi Chris

The ATC will work from prior knowledge. The draft rules say on page 7:

"Prior to each mission, competitors must declare several details about
their aircraft and how they intend to operate it. Chief among these is
their preferred cruise speed for their aircraft."

Regards, Reto

2012/10/22 Chris Gough <address@hidden>:
Im only just starting to learn about  ADS-B. When my budget SDR kit arrives 
(hacked tv tuner dongle) I'll start sniffing the ADS-B and TCAS traffic with a 
copy the protocol specs, to try to get my head around them.

With regard to commanding 4D trajectories, obviously the ATC should only 
command trajectories that the aircraft is capable off, and where possible, 
minimize disruption to it's mission. Do you imagine there would be an naive 
exchange of messages to discover the vehicle's characteristics (speed limits, 
remaining range, altitude ceiling etc), environment (wind, temp, humidity etc) 
and objectives? Or do you think that the ATC should work from prior knowledge 
about aircraft characteristics and telemetry logs?

Chris Gough

On 22/10/2012, at 8:33 PM, Reto B?ttner <address@hidden> wrote:

Hi Chris

The telemetry message you are imagining does exist. It is the ADS-B
message. It is part of the collision avoidance (separation, TCAS)
functionality.

The 4DT part is a simpler and is therefore the starting point of the
contest (L1C). That basic functionality can and should be added to
paparazzi straight forward. Once that is mastered, the a lot harder
collision avoidance functionality can be addressed (L2C).

Regards, Reto

2012/10/22 Chris Gough <address@hidden>:
I read the draft rules quickly, and needed to google quite a few terms that 
went familiar to me. 4D trajectory was one of then, and it didn't throw up 
anything that looked like a conventional meaning. I had Imagined (probably 
wrongly) that it was a telemetry message that other planes (and ATC) could use 
as a basis for smart avoiding (or directing) behavior. If it's a telecommand as 
you suggest, in some ways that's a lot simpler (it's just an extension or 
adaption of existing flight-planning constructs).

Either way, the harder part of the rules seems to be robustness to spoofing (both GPS and 
"ghost planes"). Has anybody got experience integrating paparazzi with light 
weight affordable radar? :) I've started reading up on gnuradio, and passive (SDR) radar 
solution looks to me like Mount Everest. Maybe _just_ possible for ground/terrain 
sensing, but other air traffic?

Has anyone used the paparazzi TCAS code recently? Is it up to date with all the 
code changes from the last year or so?

Chris Gough

On 22/10/2012, at 4:56 PM, Reto B?ttner <address@hidden> wrote:

Here are the draft rules:

http://prod.nais.nasa.gov/eps/eps_data/154025-OTHER-001-001.pdf

They say:

Page 3: "Competition missions will be defined by Four-Dimensional
Trajectories (4DTs), which will be comprised of a series of
three-dimensional waypoints in space and a specific time of arrival
for each waypoint."

Page 7: "The five distinct segments of a mission are: aircraft launch,
pre-4DT loiter, 4DT flight, post-4DT loiter, and aircraft recovery."

There will be an air traffic control ("central puppent master"), as
they want to be able to create specific scenarios for the competitors
with surrounding air traffic using a combination of real and virtual
aircraft working synchronously.

Managing air traffic might be the next step in development of
paparazzi. I would start out with 4DT. That would be a great new
feature!

Regards, Reto

2012/10/21 Chris Gough <address@hidden>:
I had imagined the 4d trajectories would be chirped about between vehicles
to enhance 'autonomous sense and avoid' with vehicles at potentially very
different speeds. I need to read the rules more carefully, but I didn't get
the impression that a central puppet master was involved. That wouldn't
scale well.

Chris Gough

On 21/10/2012, at 9:50 PM, Gerard Toonstra <address@hidden> wrote:


I'd expect this to be interpreted as a starting time when a uav is *allowed*
to be in some location, not so much when
it *must* be in some location. My implication is that it's more about
devising a strategy where the uav can be kept
safely in waiting until it's time to move on. The use case here is that this
allows atc to keep an area void of
other traffic until the landing of special craft X has taken place or other
use cases alike, or that a specific mission
may only commence at time Z.

There may also be an additional requirement where a NoFlyZone has a
particular time range. You may cross the zone
prior or after, but not during, otherwise you have to go around. These NFZ's
may pop up at any time during a trajectory
and may require substantial replanning of the flight itself.

Replanning flights isn't necessarily bad, as long as it's clear to the
operator why it is necessary and what will happen in the
new plan. It should also be clear what will happen if the new plan is not
accepted, because sometimes the old plan becomes
totally incompatible with the new situation.


Anyway... I'm speculating  :).  The actual rules will define how this should
be interpreted. I do think that here's an excellent opportunity to
impress the judges by thinking ahead of the requirements and demonstrating
that beyond a technical implementation, some
thinking has been undertaken why 4D is a necessity and how operators
'interact" with uav's to enable this in the best way
possible (maintaining overview of the situation, reducing interaction
complexity, etc.)

G>


On Sun, Oct 21, 2012 at 7:12 AM, Reto B?ttner <address@hidden>
wrote:
I do not think that the calculation of an ETA in flight will be enough for
NASA.

I expect rules similar to the following:

- Before flight you file a flight plan including 4D waypoints
(position, altitude and time). This calculation must include the
expected wind.

- In flight the autopilot must control position, altitude and speed to
hit the filed 4D waypoints.

- Perhaps in flight you are allowed to request a change of the filed
flight plan, e.g. if a delay in departure has occured or wind is
completely different than expected. I am sure Air Traffic Control will
allow only a few changes and only for good reasons.

Therefore Paparazzi should accept 4D waypoints (position, altitude and
time) and the flight control should be enhanced to hit the time. Has
anybody done that in Paparazzi?

Regards, Reto

2012/10/21 Steffen Spies <address@hidden>:
I think it means, that the flightplan has position and the time. Like
"be at home at 6pm" while the plane always tells if it will be in time or
not.

Am 21.10.2012 um 11:21 schrieb Chris Gough
<address@hidden>:

I noticed that too, and don't really understand what it means. Is does
it mean the telemetry messages that say "I am here now, and expect to be at
that place in two minutes"?

Chris Gough

On 21/10/2012, at 6:43 PM, Reto B?ttner <address@hidden>
wrote:

Hi guys

The newest UAS competition of NASA requests 4-Dimensional Trajectories
(4DT):

"The Level 1 Competition (L1C) would focus on a competitors ability to
fly 4-Dimensional Trajectories (4DT) to provide a reasonable
expectation that they will be where they are supposed to be, when they
are scheduled to be there."

See:
https://www.fbo.gov/?s=opportunity&mode=form&id=426438809b8348c157fa5b7120c18a45&tab=core&_cview=1

Has anyone in Paparazzi realized 4-Dimensional Trajectories, in other
words has included the time dimension in flight control?

Regards
Reto

_______________________________________________
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
_______________________________________________
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



--
Gerard Toonstra
-----------------------
http://www.radialmind.org

_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


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

Message: 4
Date: Mon, 22 Oct 2012 20:10:26 -0700
From: David Conger <address@hidden>
To: address@hidden
Subject: Re: [Paparazzi-devel] 4-Dimensional Trajectories (4DT)
Message-ID: <address@hidden>
Content-Type: text/plain; charset=iso-8859-1

All,

As a new pilot I'm becoming more familiar with FAA rules and pilotage. 
Commercial planes fly IFR with filed and closely controlled flight plans. The 
flights are not point to point. That is changing with GPS and WAAS. Airspaces 
are a consideration when making a flight plan. Also before a plane is released 
for takeoff there needs to be a place and gate for it to land at. If planes are 
not leaving San Francisco due to weather planes leaving for that destination 
are going to be held up. Fuel is another consideration with a flight plan path 
and altitude.
Commercial air traffic is pretty complex but highly controlled and monitored.
Given all those planes are on pre-determined paths and staying on them with little 
variance (maybe due to turbulence) it's really the VFR pilots that pose the big 
challenge. When I fly cross country I call ATC And fly "flight following". So 
they give me a transponder code and follow my flight. They tell me of traffic warnings 
etc. I am under their control for the flight but I retain the responsibility for flying 
safely and following the VFR flight rules.

I'm curious if there are other pilots out there with Paparazzi? This will make 
more sense to them but it's fairly easy to understand. Given all commercial 
traffic is IFR let's start there. Make the UAV fly IFR. The reason is a pilot 
flying IFR maybe in zero visibility for all but take off and landing. So they 
are no better off than a UAV without eyes. What sets them apart is that they 
copy the instructions carefully and follow them. Speech recognition is good 
enough now. If the UAV (even for now the ground station) could file IFR flight 
plans and follow directions from ATC there is most of the problem solved there. 
Even better if the UAV can use speech recognition to turn ATC commands into 
flight commands. Example maybe ATC says change to heading 090, descend to four 
thousand feet (MSL) and say the barometer at a nearby airport is 29.92 inches 
of mercury. That is important as a pilot must keep setting their barometer 
value to that so every pilot in that area is using the same value. IFR flight 
would be far and above the easiest and I'd imagine the preferred method for UAV 
flight. No need for Radar, no need for optical recognition and target (visual, 
IR, radar) detection. I can see now why all UAV pilots are IFR rated. I hope to 
get my IFR rating next.

Anyone trying to make a UAV fly VFR in the NAS is really going to have nearly 
an impossible challenge.

-David Conger

On Oct 22, 2012, at 2:06 PM, Bernard Davison wrote:

Guys don't forget about the obvious...
Usually Commercial aircraft fly to schedules. They take off at a time and 
arrive at their destination at a time. (We hope. How annoyed are we when our 
flight is late)

Cheers,
Bernie.

Sent from my iPad mini.

On 22/10/2012, at 11:16 PM, Reto B?ttner <address@hidden> wrote:

Hi Chris

The ATC will work from prior knowledge. The draft rules say on page 7:

"Prior to each mission, competitors must declare several details about
their aircraft and how they intend to operate it. Chief among these is
their preferred cruise speed for their aircraft."

Regards, Reto

2012/10/22 Chris Gough <address@hidden>:
Im only just starting to learn about  ADS-B. When my budget SDR kit arrives 
(hacked tv tuner dongle) I'll start sniffing the ADS-B and TCAS traffic with a 
copy the protocol specs, to try to get my head around them.

With regard to commanding 4D trajectories, obviously the ATC should only 
command trajectories that the aircraft is capable off, and where possible, 
minimize disruption to it's mission. Do you imagine there would be an naive 
exchange of messages to discover the vehicle's characteristics (speed limits, 
remaining range, altitude ceiling etc), environment (wind, temp, humidity etc) 
and objectives? Or do you think that the ATC should work from prior knowledge 
about aircraft characteristics and telemetry logs?

Chris Gough

On 22/10/2012, at 8:33 PM, Reto B?ttner <address@hidden> wrote:

Hi Chris

The telemetry message you are imagining does exist. It is the ADS-B
message. It is part of the collision avoidance (separation, TCAS)
functionality.

The 4DT part is a simpler and is therefore the starting point of the
contest (L1C). That basic functionality can and should be added to
paparazzi straight forward. Once that is mastered, the a lot harder
collision avoidance functionality can be addressed (L2C).

Regards, Reto

2012/10/22 Chris Gough <address@hidden>:
I read the draft rules quickly, and needed to google quite a few terms that 
went familiar to me. 4D trajectory was one of then, and it didn't throw up 
anything that looked like a conventional meaning. I had Imagined (probably 
wrongly) that it was a telemetry message that other planes (and ATC) could use 
as a basis for smart avoiding (or directing) behavior. If it's a telecommand as 
you suggest, in some ways that's a lot simpler (it's just an extension or 
adaption of existing flight-planning constructs).

Either way, the harder part of the rules seems to be robustness to spoofing (both GPS and 
"ghost planes"). Has anybody got experience integrating paparazzi with light 
weight affordable radar? :) I've started reading up on gnuradio, and passive (SDR) radar 
solution looks to me like Mount Everest. Maybe _just_ possible for ground/terrain 
sensing, but other air traffic?

Has anyone used the paparazzi TCAS code recently? Is it up to date with all the 
code changes from the last year or so?

Chris Gough

On 22/10/2012, at 4:56 PM, Reto B?ttner <address@hidden> wrote:

Here are the draft rules:

http://prod.nais.nasa.gov/eps/eps_data/154025-OTHER-001-001.pdf

They say:

Page 3: "Competition missions will be defined by Four-Dimensional
Trajectories (4DTs), which will be comprised of a series of
three-dimensional waypoints in space and a specific time of arrival
for each waypoint."

Page 7: "The five distinct segments of a mission are: aircraft launch,
pre-4DT loiter, 4DT flight, post-4DT loiter, and aircraft recovery."

There will be an air traffic control ("central puppent master"), as
they want to be able to create specific scenarios for the competitors
with surrounding air traffic using a combination of real and virtual
aircraft working synchronously.

Managing air traffic might be the next step in development of
paparazzi. I would start out with 4DT. That would be a great new
feature!

Regards, Reto

2012/10/21 Chris Gough <address@hidden>:
I had imagined the 4d trajectories would be chirped about between vehicles
to enhance 'autonomous sense and avoid' with vehicles at potentially very
different speeds. I need to read the rules more carefully, but I didn't get
the impression that a central puppet master was involved. That wouldn't
scale well.

Chris Gough

On 21/10/2012, at 9:50 PM, Gerard Toonstra <address@hidden> wrote:


I'd expect this to be interpreted as a starting time when a uav is *allowed*
to be in some location, not so much when
it *must* be in some location. My implication is that it's more about
devising a strategy where the uav can be kept
safely in waiting until it's time to move on. The use case here is that this
allows atc to keep an area void of
other traffic until the landing of special craft X has taken place or other
use cases alike, or that a specific mission
may only commence at time Z.

There may also be an additional requirement where a NoFlyZone has a
particular time range. You may cross the zone
prior or after, but not during, otherwise you have to go around. These NFZ's
may pop up at any time during a trajectory
and may require substantial replanning of the flight itself.

Replanning flights isn't necessarily bad, as long as it's clear to the
operator why it is necessary and what will happen in the
new plan. It should also be clear what will happen if the new plan is not
accepted, because sometimes the old plan becomes
totally incompatible with the new situation.


Anyway... I'm speculating  :).  The actual rules will define how this should
be interpreted. I do think that here's an excellent opportunity to
impress the judges by thinking ahead of the requirements and demonstrating
that beyond a technical implementation, some
thinking has been undertaken why 4D is a necessity and how operators
'interact" with uav's to enable this in the best way
possible (maintaining overview of the situation, reducing interaction
complexity, etc.)

G>


On Sun, Oct 21, 2012 at 7:12 AM, Reto B?ttner <address@hidden>
wrote:
I do not think that the calculation of an ETA in flight will be enough for
NASA.

I expect rules similar to the following:

- Before flight you file a flight plan including 4D waypoints
(position, altitude and time). This calculation must include the
expected wind.

- In flight the autopilot must control position, altitude and speed to
hit the filed 4D waypoints.

- Perhaps in flight you are allowed to request a change of the filed
flight plan, e.g. if a delay in departure has occured or wind is
completely different than expected. I am sure Air Traffic Control will
allow only a few changes and only for good reasons.

Therefore Paparazzi should accept 4D waypoints (position, altitude and
time) and the flight control should be enhanced to hit the time. Has
anybody done that in Paparazzi?

Regards, Reto

2012/10/21 Steffen Spies <address@hidden>:
I think it means, that the flightplan has position and the time. Like
"be at home at 6pm" while the plane always tells if it will be in time or
not.

Am 21.10.2012 um 11:21 schrieb Chris Gough
<address@hidden>:

I noticed that too, and don't really understand what it means. Is does
it mean the telemetry messages that say "I am here now, and expect to be at
that place in two minutes"?

Chris Gough

On 21/10/2012, at 6:43 PM, Reto B?ttner <address@hidden>
wrote:

Hi guys

The newest UAS competition of NASA requests 4-Dimensional Trajectories
(4DT):

"The Level 1 Competition (L1C) would focus on a competitors ability to
fly 4-Dimensional Trajectories (4DT) to provide a reasonable
expectation that they will be where they are supposed to be, when they
are scheduled to be there."

See:
https://www.fbo.gov/?s=opportunity&mode=form&id=426438809b8348c157fa5b7120c18a45&tab=core&_cview=1

Has anyone in Paparazzi realized 4-Dimensional Trajectories, in other
words has included the time dimension in flight control?

Regards
Reto

_______________________________________________
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
_______________________________________________
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



--
Gerard Toonstra
-----------------------
http://www.radialmind.org

_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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



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

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


End of Paparazzi-devel Digest, Vol 103, Issue 56
************************************************






reply via email to

[Prev in Thread] Current Thread [Next in Thread]