rcpilot-devs — R/C Pilot Developers

Re: [rcpilot-devs] Test Map

[Michael J. P. <mi...@vi...>]

It's happening on the Montreal Map for me.
I double checked it with UI-View (an APRS app) and it works fine on it, 
but I don't get that same position on RCGS.

That's why I created the Test map.

I will make Test2 map tonight with proper longitude marks and give that 
a try.

I'll let you know.



> I just wanted to make sure we're talking about the
> same issue.  If you're having problems with home
> appearing in the wrong place, it is most likely a bug
> in my code, but I haven't seen this happening.  Is it
> happening to you?

Re: [rcpilot-devs] Test Map

[chris s. <chr...@ya...>]

Hi again Mike.  By the way, the ratios i'm talking
about are only being used to calculate the radius of
the rings on the map.  They're not being used for
positioning of home/the plane/etc.  For that i'm just
linearly interpolating from one edge of the map to the
other on each axis.

I just wanted to make sure we're talking about the
same issue.  If you're having problems with home
appearing in the wrong place, it is most likely a bug
in my code, but I haven't seen this happening.  Is it
happening to you?

chris





		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [rcpilot-devs] Test Map

[chris s. <chr...@ya...>]

Sounds good Mike.  The method I am using currently for
calculating the ratios is below.

arcseconds/mile for latitude
----------------------------
ratio = 51.86 asec/mile (constant)

arcseconds/mile for longitude
-----------------------------
ratio = Ca / (Cm * cos(Home Lat in radians)

where Ca = Earth circumference in arcseconds
      Cm = Earth circumference in miles

I found the longitude formula in a .pdf about GPS. 

Anyway, let me know what you find out.  It would
certainly be odd if the egg shapes are correct!

chris



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

[rcpilot-devs] Test Map

[Michael J. P. <mi...@vi...>]

I created a new map called Test for verifying positions etc.
It has long and lat coords that are equal distances from each other.

When I test things out like this everything works out fine.
Personally I thought that the longitude size difference would not make a 
big deal at this scale.
But I'm starting to think this is wrong. That we cannot simply divide up 
the longitude into equal values to determine where to place a point on 
an image.

I will make a new test map tonight or tomorrow with proper longitude 
marks for a distance of let's say about 10nm.

Surely if needed the algorythm to figure this out is published somewhere 
on the net.

Cheers,
Mike

Re: [rcpilot-devs] Rings on Map and Obeserver

[chris s. <chr...@ya...>]

> Great stuff Chris, the maps are really coming along.
Thx! :-)

> At that scale things should be pretty round, however
> the map itself might not be proportional.

Yes I was wondering that as well.  Have you heard of
this effect before (the arcseconds/mile ratio for
longitude increasing as you move north or south away
from the equator)?  I suppose it makes sense because
the lines of longitude around the globe are getting
shorter, but i'm not used to egg shaped rings.  The
aspect ratio of the map does have an effect as well
though.

> Also I was thinking the ring should be the "Alarm"
> distance as opposed 
> to arbitrary rings.
> What do you think?

Sure.  That would be very easy to modify.  Is the
alarm distance in the UserPreferences object?
 
> As for Observer class...  Was your idea to have
> every element be an 
> observer of a specific data type?

Not quite.  My idea was to just have the TelemetryData
object extend Observable, then have any views of the
telemetry implement Observer.  This is how i've seen
it done before.

This would basically replicate the behaviour the app
currently has through the TelemetryDataChangedEvent
objects, except with less overhead.  I think having
the individual data types extend Observable would
become far too messy, plus it would be "peeking inside
the black box" of the TelemetryData object, ruining
our information hiding, etc.

Chris




		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

[rcpilot-devs] Rings on Map and Obeserver

[Michael J. P. <mi...@vi...>]

Great stuff Chris, the maps are really coming along.
I will make another detailed map to see if we still get the rings as 
elipses.
At that scale things should be pretty round, however the map itself 
might not be proportional.
Also I was thinking the ring should be the "Alarm" distance as opposed 
to arbitrary rings.
What do you think?

As for Observer class...  Was your idea to have every element be an 
observer of a specific data type?
And then call  setChanged() and  notifyObservers() everytime that 
specific piece of data is changed as opposed to globally firing an event 
everytime we get new data in. Just want to make sure I understand well 
what you are trying to do.

I like the idea...  but that means some significant code changes. Are 
you comfortable in making those changes?

Re: [rcpilot-devs] ReadMe.txt

[Michael J. P. <mi...@vi...>]

Well I did not go into the code to see what's happening, but simply by 
playing with the "Home" coordinates it seems that the Latitude 
calculations are ok, but the Longitude ones are not.

I think I will  create a map simply with lat and lon lines so we can 
test things out easier.

Cheers,
Mike



chris smith wrote:

> <> The warping due to the latitude of Montreal looks funny, but I
> think it is correct. Everywhere north/south of the equator should  
> display this warping as far as I can
> tell.

Re: [rcpilot-devs] ReadMe.txt

[chris s. <chr...@ya...>]

Hi Mike.  As you probably saw, I added range rings at
1,2, and 4 miles around home on the map.  The warping
due to the latitude of Montreal looks funny, but I
think it is correct.  Everywhere north/south of the
equator should display this warping as far as I can
tell.

I also added zoom buttons to the map, though they are
currently non-functional (top left corner).  Let me
know what you think.  You'll need to grab a new folder
I added to the cvs tree, /res/icons

chris




		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: [rcpilot-devs] ReadMe.txt

[Michael J. P. <mi...@vi...>]

>Does the procedure described in the readme produce a
>different data stream?
>  
>
I don't remember... I would have to look into the code. But chances are 
TelData is giving some more info.
The reason for going with AGWPE is that it is the way it is done when 
sending down data from the plane.
So I figured I might as well get closer to the real thing.

>BTW, thanks for CVS access.  :-)
>  
>

My pleasure... thanks for putting the time into the project.
If you get a chance, do you think you can add scroll bars to the maps.
It's just that I no longer get my flying field on the Montreal map. ;-)
I need to make some better maps for myself.

Also for the zooming in-out, I was thinking we should have the same 
action buttons used in the tracker view for zooming the map.
I do not like the controls that are currently there, perhaps just some 
better icons....  but it would be nice to have the same controls for 
both views to keep some consistency.

Cheers,
Mike - On my way to the field to go fly.

Re: [rcpilot-devs] ReadMe.txt

[chris s. <chr...@ya...>]

> Chris, have you tried this? Where you able to get it
> to work?
> Here's is the read me.
> 
> Mike
> 

Hi Mike.  I haven't tried the AGWPE procedure
described in the readme file.  I just ran TestServer,
then used connect within the application (after
setting remote vehicle to SKY001 -- I had to do some
poking around in the source to find that :-), and then
RCGS received a stream of data over the socket.  

Does the procedure described in the readme produce a
different data stream?

BTW, thanks for CVS access.  :-)

chris



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

[rcpilot-devs] ReadMe.txt

[Michael J. P. <mi...@vi...>]

For some reason I am unable to update the ReadMe.txt in CVS. I will try 
again later.
But I made some simple addition to mention what user prefs need to be 
set at for TelData to work.

Chris, have you tried this? Where you able to get it to work?
Here's is the read me.

Mike


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


Make sure AGWPE is up and running.

If you do not have AGWPE you may download it at:
http://www.raag.org/sv2agw/inst.htm

The TCPIP interface needs to be enabled.
Create a loopback device as the first port (port1)
(use the default listening port of 8000)

Start RCGS from a command prompt by typing:
C:> java -jar rcgs.jar

If you have .jar files associates with javaw you may simply double click 
on it as well.

In the User Preferences set the following items under the Connection tab.
Protocol: AUAVTP
Transport: AGWPE
AGWPEIP: 127.0.0.1
AGWPE Port: 8000
Remote Vehicle Call Sign: SKY001
Ground Station Call Sign: GROUND

and save.


Select "Connect" from the file menu.

To have demo telemtry data sent to RCGS, you may use TelData.jar.
Start TelData from a command prompt by typing:
C:> java -jar teldata.jar

If you have .jar files associates with javaw you may simply double click 
on it as well.

Select "Connect" from the file menu.
Select "Send Telemetry Data" from the file menu.

Demo data should now be sent to RCGS.
You may adjust the tx delay of the data in TelData.
However a value of at least 50 is recommended.


For more more info or support, join the Mailing list at: 
http://rcpilot.sourceforge.net/

Re: [rcpilot-devs] Proposal for minor architecture change

[Michael J. P. <mi...@vi...>]

Hi Chris,

Besides you and I the only other person that is still coding for this 
project is Ian.
He is taking a break but will get back at it if we write a better 
simulator!  ;-)
I was not really planning on it, but might take  a  whack at it to get 
him back on board.

Just to let you know who did what etc...

I wrote the first versions of each view and the event code.
Peter Wooster wrote all the TCP/IP stuff for communicating with AGWPE.
Ian cleaned up a lot of the main Interface code as well as implemented 
some cool suff like the full screen mode, all the prefs etc.

Ian would like to work on the Tracker view next.
This is why I asked you to work on the Map code.
I should create some more instruments such as voltage, receiver signal 
strength etc.

One major one that needs to be tackled is the HUD view.
I got really bogged down on that one trying to figure out what would be 
the best method to draw it.
Have some offscreen images in memory that are repositioned onto screen 
with every update.
Or simply redrawing the image each time since they are relatively simple 
images...  just a bunch of lines.

Val has designed a 9600 baud modem that was working but I haven't heard 
about it in a while.
I think people are going back to on screen  overlay from the plane at 
Mr. Cam site with his Attitude indicator project.

Although I think it is a great project that Mr. RC-Cam is creating, I 
believe the way to go is sending data to the ground and having and On 
Screen Display done on the ground. Especially when what I have in mind 
for the future is 2 way communication with the vehichle so waypoints can 
be added in flight etc.

And that is where we are at.

Now back to the Observer stuff.
I have not read anything about it, but it sounds good to me.
Give me until the end of the weekend so I can read up on it a bit and 
see how difficul it would be to make the changes.

Cheers,
Mike



chris smith wrote:

>Instead of firing TelemetryDataEvent objects in many
>different places, I propose using the
>Observer/Observable pairing built in to Java.
>
>If you guys have seen Observer/Observable before, what
>do you think?
>  
>

[rcpilot-devs] Proposal for minor architecture change

[chris s. <chr...@ya...>]

Hi everyone!  I've been communicating with Mike
regarding the project, and i've asked to come on board
and help out with the programming.  So far i've made
some changes to the RcgsMap class.

I would like to propose a minor architecture change in
object-object communication.

Instead of firing TelemetryDataEvent objects in many
different places, I propose using the
Observer/Observable pairing built in to Java.

If you guys have seen Observer/Observable before, what
do you think?

If you have not seen it, it would go something like
this:

public class TelemetryData extends Observable {...}

then any class wanting access to the telemetry data
implements the Observer interface and registers with
the TelemetryData class.

One advantage is you don't have to worry about
constructing/firing events yourself.  Whenever
TelemetryData changes, just call notifyObservers().

Another advantage is you eliminate the overhead
associated with creating/garbage collecting many many
TelemetryDataChangedEvent objects (the method we would
use in the Observer interface won't need to construct
an object for each notification call).  I'm assuming
it would be on the order of tens or even hundreds of
objects per second.

It may not sound like much, but it adds up, especially
if all those objects are doing is saying 'since I have
arrived, please query the TelemetryData class for new
data'.


chris




		
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo 

[rcpilot-devs] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

RE: [rcpilot-devs] RCGS Data Protocols

[Michael J. P. <mi...@vi...>]

I think we are pretty much on the same wavelength.

Everything gets converted to "TelemetryData".
For instance, a geo points (GPS waypoints) in RCGS are kept in 1/100 of a second.
See the note in GPS.java
N and E are positive values.
S and W are negative values.

As for projection...  absolutely Mercator as well.
The distance of the average map will probably only span several kilometers in RCGS.
So I'm not going to bother too much with corrections. At that scale it will not make any significant difference.

The one thing that is bothering me at the moment is keeping the time of the last data update for a specific data type.
I don't really want to have a timestamp object for every data type. However for somethings it is necessary.
Like calculating the vertical speed. I need to think about timestamps for a bit.

P.S. You might want to look at the following pages for your project.

http://mathworld.wolfram.com/topics/MapProjections.html
http://www.remotesensing.org/proj/

I have no idea what you are creating, but I used to use a great navigation package on my boat called Maptech Cruising Navigator.
I think it changed name to Marine Navigator now.

You can take a look at it at: http://www.maptech.com/water/MarineNavigator/index.cfm
Basically it had Charts, Aerial Photos, Contours, Cruising Guides, Weather Faxes etc. all in one packages.
As well it would connected into the NMEA bus and pick up all the sensors and allow you to control the Autopilot.
Maybe it will give you some ideas.


Cheers,
Mike









*********** REPLY SEPARATOR  ***********

On 14/03/2004 at 8:56 PM PK Wooster wrote:

>I suggest that we not rely on the identifiers and formats of the sources ,
>but rather convert each into an internal object protocol that uses Java
>friendly formats and that hides the external protocol specifics such as
>nmea's strange dddmm.ffff format which mixes base 60 and base 10. This way
>if we want to add new sources and protocols we won't be restricted by the
>existing ones.  All the parsing would be done at the time of reception.
>
>Eg.
> The sentence
> $GPGGA,192524,4328.8539,N,07938.4150,W,1,06,2.3,93.2,M,-35.3,M,,*41
>Coming from the gps would be forwarded as an object containing
>  String source = NMEA0183 GPS
>  Date time = 2004-03-14 19:25:24
>  double latitude = 43.48
>  double longitude = -79.64
>  double altitude = 93.2
>
>What projections are you planning to use for maps.  I've been investigating
>the Mercator and Gnomonic. Both of these present advantages for navigation
>but show serious distortions when used on maps of large areas. For our
>sailing application we will use Mercator as we want straight rhumb lines.
>Gnomonic produces straight great circle routes.
>
>-----Original Message-----
>From: rcp...@li...
>[mailto:rcp...@li...] On Behalf Of Michael J.
>Pawlowsky
>Sent: Sunday, March 14, 2004 10:14 AM
>To: R/C Pilot Developers List
>Subject: [rcpilot-devs] RCGS Data Protocols
>
>
>
>I added the user preference DataProtocol.
>
>The options are AUAVTP, NMEA0183 and APRS.
>
>AUAVTP is the Amateur UAV Telemetry Protocol.
>It is the preffered protocol.
>
>NMEA0183 - Data that comes from a GPS.
>
>APRS is Automatic Position Reporting System - Also comes from a GPS but is
>encoded into tighter frames.
>
>
>Why do I want to add APRS as well? Simply because it is even a simpler way
>to have RCGS adopted by others, There's is an APRS beacon called the
>TinyTrack ( http://www.byonics.com/tinytrak/index.html ) that is widely
>used
>in Amateur UAVs already.
>
>Most people use it with software like Xastir (http://www.xastir.org/),
>WinAPRS (http://www.winaprs.org/) or UI-View (http://www.ui-view.com/).
>These application were designed for ground based positioning, similar to
>the
>Map View in RCGS.
>
>So basically it will allow people to adopt RCGS without making any hardware
>modifications to their current setup.
>I think this can help a lot in getting people to use RCGS.
>
>
>
>So now the main thing to figure out is the data flow.
>
>	Data can be aquired in 2 ways.
>
>            1) From AGWPE over TCP/IP
>            2) Through a serial port.
>
>            Which one is used is decided by the user prefs.
>
>           So when a frame comes in (using either transport) we need to
>take
>a look at the protocol and then send the data to that protocol handler.
>           The protocol handler parses the data and then calls the
>setTelemetryData methods to update whatever info it received.
>
>
>
>This leaves me with a few issues.
>
>APRS does have an identifier in the data.
>GPS will also since all data will start with a "$"
>AUAVTP does not have any identifier in the first byte. I think one should
>be
>adopted so we can simply flush the frame in case we have a protocol
>mis-match.
>              It can also be used as a delimeter if we receive the data in
>a
>serial connection to mark the begining of a frame.
>
>APRS will always be used with AGWPE. So the CRC routines in AX.25 take care
>of verifying the integraty of the frame.
>GPS has a Checksum for each sentence that will do the same.
>AUAVTP when used with AX25 will have the CRC but it will not have any way
>to
>verify it's data through a serial connection.
>              So some sort of data integrity needs to be incorporated into
>the frame. Personally I prefer working with checksums.
>
>
>Any comments?
>
>I will wait a coule of days and then update the specs on the web site. I
>will try and find a unique identifier for AUAVTP.
>
>
>MikeP
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial
>presented by Daniel Robbins, President and CEO of GenToo technologies.
>Learn
>everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>rcpilot-devs mailing list
>rcp...@li...
>https://lists.sourceforge.net/lists/listinfo/rcpilot-devs
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>rcpilot-devs mailing list
>rcp...@li...
>https://lists.sourceforge.net/lists/listinfo/rcpilot-devs

Re: [rcpilot-devs] RCGS TODO

[Michael J. P. <mi...@vi...>]

>Huh? I don't see *anything* in the "Table" tab now, just the fields on
>the right hand side that are displayed for the Map and Tracker too.

And that's basically all there will be. You do understand that whatever is blue (or VidColor) is the video coming in from the remote vehicle.
So basically this is a view that will give you mostly only the video image.

Something that would be pretty neat would be to allow the user to place the data wherever they want to on that screen.
But I think we will leave that for another version.

>What screens are affected by changing the font size? Is this strictly a
>HUD issue?

No...  All views but the instrument view.
Especially the Telemetry table. As it is now, with a pair of VR Glasses it is illegible.


>Any idea when the TestServer and simulator will be up and running? (so I
>can steer the plan out of bounds, and test GUI behavior...)

TelData does send out data, so does testserver. But the plane does not move very far.
I suppose I could add some controls to allow you to manipulate the data somewhat.
I will try and add that soon. This is becoming more like a simulator!  ;-)


Mike

Re: [rcpilot-devs] RCGS TODO

[Ian D. <occ...@ia...>]

Michael J. Pawlowsky wrote:
> The table view is pretty much what you see.

Huh? I don't see *anything* in the "Table" tab now, just the fields on 
the right hand side that are displayed for the Map and Tracker too.

> As for font type. It is not neccessary at all for them to choose. Perhaps in another version.
> Font size is necessary however.

What screens are affected by changing the font size? Is this strictly a 
HUD issue?

> ------  Tracker.
> 
> As for the alam, what would be cool would be to have a red circle appear at that distance.
> Start it flaching when the distance alarm is triggered is we are in that view.
> 
> Same for the map. It would be nice to have the option to place a distance circle on top of it.

Any idea when the TestServer and simulator will be up and running? (so I 
can steer the plan out of bounds, and test GUI behavior...)

--ian

RE: [rcpilot-devs] RCGS Data Protocols

[PK W. <pe...@wo...>]

I suggest that we not rely on the identifiers and formats of the sources ,
but rather convert each into an internal object protocol that uses Java
friendly formats and that hides the external protocol specifics such as
nmea's strange dddmm.ffff format which mixes base 60 and base 10. This way
if we want to add new sources and protocols we won't be restricted by the
existing ones.  All the parsing would be done at the time of reception.

Eg. 
 The sentence
 $GPGGA,192524,4328.8539,N,07938.4150,W,1,06,2.3,93.2,M,-35.3,M,,*41
Coming from the gps would be forwarded as an object containing 
  String source = NMEA0183 GPS
  Date time = 2004-03-14 19:25:24
  double latitude = 43.48
  double longitude = -79.64
  double altitude = 93.2

What projections are you planning to use for maps.  I've been investigating
the Mercator and Gnomonic. Both of these present advantages for navigation
but show serious distortions when used on maps of large areas. For our
sailing application we will use Mercator as we want straight rhumb lines.
Gnomonic produces straight great circle routes.  

-----Original Message-----
From: rcp...@li...
[mailto:rcp...@li...] On Behalf Of Michael J.
Pawlowsky
Sent: Sunday, March 14, 2004 10:14 AM
To: R/C Pilot Developers List
Subject: [rcpilot-devs] RCGS Data Protocols



I added the user preference DataProtocol.

The options are AUAVTP, NMEA0183 and APRS.

AUAVTP is the Amateur UAV Telemetry Protocol.
It is the preffered protocol.

NMEA0183 - Data that comes from a GPS.

APRS is Automatic Position Reporting System - Also comes from a GPS but is
encoded into tighter frames.


Why do I want to add APRS as well? Simply because it is even a simpler way
to have RCGS adopted by others, There's is an APRS beacon called the
TinyTrack ( http://www.byonics.com/tinytrak/index.html ) that is widely used
in Amateur UAVs already.

Most people use it with software like Xastir (http://www.xastir.org/),
WinAPRS (http://www.winaprs.org/) or UI-View (http://www.ui-view.com/).
These application were designed for ground based positioning, similar to the
Map View in RCGS.

So basically it will allow people to adopt RCGS without making any hardware
modifications to their current setup.
I think this can help a lot in getting people to use RCGS.



So now the main thing to figure out is the data flow.

	Data can be aquired in 2 ways.

            1) From AGWPE over TCP/IP
            2) Through a serial port.

            Which one is used is decided by the user prefs.

           So when a frame comes in (using either transport) we need to take
a look at the protocol and then send the data to that protocol handler.
           The protocol handler parses the data and then calls the
setTelemetryData methods to update whatever info it received.



This leaves me with a few issues.

APRS does have an identifier in the data.
GPS will also since all data will start with a "$"
AUAVTP does not have any identifier in the first byte. I think one should be
adopted so we can simply flush the frame in case we have a protocol
mis-match.
              It can also be used as a delimeter if we receive the data in a
serial connection to mark the begining of a frame.

APRS will always be used with AGWPE. So the CRC routines in AX.25 take care
of verifying the integraty of the frame.
GPS has a Checksum for each sentence that will do the same.
AUAVTP when used with AX25 will have the CRC but it will not have any way to
verify it's data through a serial connection.
              So some sort of data integrity needs to be incorporated into
the frame. Personally I prefer working with checksums.


Any comments?

I will wait a coule of days and then update the specs on the web site. I
will try and find a unique identifier for AUAVTP.


MikeP





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial
presented by Daniel Robbins, President and CEO of GenToo technologies. Learn
everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
rcpilot-devs mailing list
rcp...@li...
https://lists.sourceforge.net/lists/listinfo/rcpilot-devs

[rcpilot-devs] NMEA support

[Michael J. P. <mi...@vi...>]

Peter:

I created an empty class called DataNMEA
This is where the NMEA parsing should go.

If you have any comments on the flow, let me know.

I will try and add some NMEA and APRS data to TelData in the next couple of days.

Mike

[rcpilot-devs] RCGS Data Protocols

[Michael J. P. <mi...@vi...>]

I added the user preference DataProtocol.

The options are AUAVTP, NMEA0183 and APRS.

AUAVTP is the Amateur UAV Telemetry Protocol.
It is the preffered protocol.

NMEA0183 - Data that comes from a GPS.

APRS is Automatic Position Reporting System - Also comes from a GPS but is encoded into tighter frames.


Why do I want to add APRS as well? Simply because it is even a simpler way to have RCGS adopted by others,
There's is an APRS beacon called the TinyTrack ( http://www.byonics.com/tinytrak/index.html ) that is widely used in Amateur UAVs already.

Most people use it with software like Xastir (http://www.xastir.org/), WinAPRS (http://www.winaprs.org/) or UI-View (http://www.ui-view.com/).
These application were designed for ground based positioning, similar to the Map View in RCGS.

So basically it will allow people to adopt RCGS without making any hardware modifications to their current setup.
I think this can help a lot in getting people to use RCGS.



So now the main thing to figure out is the data flow.

	Data can be aquired in 2 ways.

            1) From AGWPE over TCP/IP
            2) Through a serial port.

            Which one is used is decided by the user prefs.

           So when a frame comes in (using either transport) we need to take a look at the protocol and then send the data to that protocol handler.
           The protocol handler parses the data and then calls the setTelemetryData methods to update whatever info it received.



This leaves me with a few issues.

APRS does have an identifier in the data.
GPS will also since all data will start with a "$"
AUAVTP does not have any identifier in the first byte. I think one should be adopted so we can simply flush the frame in case we have a protocol mis-match.
              It can also be used as a delimeter if we receive the data in a serial connection to mark the begining of a frame.

APRS will always be used with AGWPE. So the CRC routines in AX.25 take care of verifying the integraty of the frame.
GPS has a Checksum for each sentence that will do the same.
AUAVTP when used with AX25 will have the CRC but it will not have any way to verify it's data through a serial connection.
              So some sort of data integrity needs to be incorporated into the frame. Personally I prefer working with checksums.


Any comments?

I will wait a coule of days and then update the specs on the web site. I will try and find a unique identifier for AUAVTP.


MikeP

Re: [rcpilot-devs] RCGS TODO

[Michael J. P. <mi...@vi...>]

Well let's start with the easiest and work our way to the rest.

The table view is pretty much what you see.

What needs to change in it, will be in TelemteryTable.
Basically the user needs to be able to decide what they see there.
Which means...  yup you guessed it...   more prefs.

I nice UI for that would simply be two scroll list. You have a list with all the possible values on one side and the ones you want displayed on the other.
If you could moved them up and down in the "Active" list that would be cool since it would allow the user to view them in the order that they want.

As for font type. It is not neccessary at all for them to choose. Perhaps in another version.
Font size is necessary however.


-------


Alarms:

This is how I see it displayed.
Text in () are my comments

Alarms [x]     (Turns on/off all allarms)

Distance: [x] (Turns on/off only the distance alarm)
_____________  Km


Altitude: [x]   (Turns on/off only the altitude alarm)
Min.: ___________ m
Max.: ___________m


So you can enable and disable all alarms. Or simply enable one of them.
I starting looking into Audio as well. Basically I found a pretty simple way to have audio playing.
I also went through the Sun tutorial which seems to add many more steps then what I have found.
I will post it somewhere.

What I was thinking for sounds are the traditional soft female voice saying "Altitude, altitude" etc.
I'm guessing the psychology behind that is to keep the pilot calm.  ;-)

As for visuals. In each view it will be different. But basically I simply see some "red" word of the alarm flashing slowly somewhere.



-----  Map.

Great idea yes...  an icon of our "Home" would be a very good idea.
That and the icon of the plane would seem sufficient for v1.

However later what would be nice to add is the ability to place waypoints.
Being able to measure the distance between two point with the mouse.
Zoom In/ Zoom out.



------  Tracker.

The text I see simply as text similar to what in the lower left side now.
I would use the "Large" font for it.

As for what it looks like. Unfotunately I sold my Radar with my boat.

I found an image here: http://marine-engine-parts.com/Rayrl70plus.jpg
But you can't see much.
Naturally we will not be displaying terrain or other vehicles.

But it's pretty much the way it is. I don't see adding much else.


As for the alam, what would be cool would be to have a red circle appear at that distance.
Start it flaching when the distance alarm is triggered is we are in that view.

Same for the map. It would be nice to have the option to place a distance circle on top of it.



I think I covered most of it...  If I forgot something let me know!

Let me know what you will be working on if you can.
Also frequent commits are very much appreciated.


We appreciate your contribution.

Thanks,
Mike





*********** REPLY SEPARATOR  ***********

On 13/03/2004 at 2:36 PM Ian Dallas wrote:

>Michael J. Pawlowsky wrote:
>> Tracker View
>>    - Distance Label
>>    - Bearing Label
>>    - Visual Alarm
>>    - Zoom button background same color as video
>>
>> Map View
>>    - Have icon placed at proper position
>>
>> User Preferences
>>    - Fonts
>>    - Protocol (NMEA , Amateur UAV Data Protocol)
>>    - Altitude Alarm
>>    - Individual Check Boxes per Alarm.
>>    - Table Selection (which data to show or not)
>
>I'd be happy to do all the Tracker, Map, and User Preferences stuff --
>but I'll need a bit more detail about what all the bullet items mean.
>
>Tracker View
>----------------------------
>Where do the labels go, and how do you want them to read? Can users turn
>them on and off? Do you have any examples from displays for life-sized
>planes?
>
>What does the visual alarm look like? What sets off alarms?
>
>
>Map View
>----------------------------
>Are we just placing an icon for the plan? What about the user's
>position? Should the icon be customizable? Should there be a label
>anywhere?
>
>
>User Preferences
>----------------------------
>
>For fonts, do you just want a selector for small, medium, and large?
>What about the typeface, is there any reason to make that configurable?
>Why do people need to change fonts, anyway? Which fonts in the interface
>are affected by this? Would it make more sense just to give them a a
>point size selector? (ie, 10 pt., 12 pt, etc.) What happens if the font
>wouldn't fit in the existing layout, what steps should we take to warn
>the user or compensate?
>
>Is the altitude alarm just a check box? Is there a test field to provide
>a specific height? How is the warning displayed to the user? Do we play
>a sound? If so, can they choose which sound? Will the warning be
>different depending on which screen they're looking at? If they're using
>VR glasses, pop up dialog boxes are pretty useless, right?
>
>Which alarms have "Individual Check Boxes"? And how are all these alarms
>displayed when they go off?
>
>Can you describe the table selection, and what should be configurable,
>in greater detail?
>
>--ian
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>rcpilot-devs mailing list
>rcp...@li...
>https://lists.sourceforge.net/lists/listinfo/rcpilot-devs

Re: [rcpilot-devs] RCGS TODO

[Ian D. <occ...@ia...>]

Michael J. Pawlowsky wrote:
> Tracker View
>    - Distance Label
>    - Bearing Label
>    - Visual Alarm
>    - Zoom button background same color as video
> 
> Map View
>    - Have icon placed at proper position
> 
> User Preferences
>    - Fonts
>    - Protocol (NMEA , Amateur UAV Data Protocol)
>    - Altitude Alarm
>    - Individual Check Boxes per Alarm.
>    - Table Selection (which data to show or not)

I'd be happy to do all the Tracker, Map, and User Preferences stuff -- 
but I'll need a bit more detail about what all the bullet items mean.

Tracker View
----------------------------
Where do the labels go, and how do you want them to read? Can users turn 
them on and off? Do you have any examples from displays for life-sized 
planes?

What does the visual alarm look like? What sets off alarms?


Map View
----------------------------
Are we just placing an icon for the plan? What about the user's 
position? Should the icon be customizable? Should there be a label anywhere?


User Preferences
----------------------------

For fonts, do you just want a selector for small, medium, and large? 
What about the typeface, is there any reason to make that configurable? 
Why do people need to change fonts, anyway? Which fonts in the interface 
are affected by this? Would it make more sense just to give them a a 
point size selector? (ie, 10 pt., 12 pt, etc.) What happens if the font 
wouldn't fit in the existing layout, what steps should we take to warn 
the user or compensate?

Is the altitude alarm just a check box? Is there a test field to provide 
a specific height? How is the warning displayed to the user? Do we play 
a sound? If so, can they choose which sound? Will the warning be 
different depending on which screen they're looking at? If they're using 
VR glasses, pop up dialog boxes are pretty useless, right?

Which alarms have "Individual Check Boxes"? And how are all these alarms 
displayed when they go off?

Can you describe the table selection, and what should be configurable, 
in greater detail?

--ian

[rcpilot-devs] RCGS TODO

[Michael J. P. <mi...@vi...>]

I went through RCGS and quickly put together a TODO list to complete Version 1.
This is what I came up with.


Instrument View
   - Electrical Instrument (VDC AMP)
   - Fuel Instrument
   - RSSI Instrument
   - GPS Instrument/Tracker (toggle between both)
   - Eng Temp
   - Visual Alarm
   - Fix mask on attitude indicator

HUD View
   (All)

Tracker View
   - Distance Label
   - Bearing Label
   - Visual Alarm
   - Zoom button background same color as video

Map View
   - Have icon placed at proper position

User Preferences
   - Fonts
   - Protocol (NMEA , Amateur UAV Data Protocol)
   - Altitude Alarm
   - Individual Check Boxes per Alarm.
   - Table Selection (which data to show or not)

Back End
   - Support for NMEA
   - Use Font/Size Selection
   - Alarm support

Re: [rcpilot-devs] Downloading AGWPE and "Demo" mode

[Michael J. P. <mi...@vi...>]

The file is AGWPE.zip

As for setting it up.
Go into properties.
You need to create a new port
In the TNC type select "Loopback Port"
Close it and restart it.

The rest of the info is in the CVS README.txt if you need it.
But basically just connect on both machines.

The one oddity is when you set a port it needs to be -1 of the port that comes back when you ask for port info in TelData.

So if you only have one port, it will be port 1  and you need to set it for port 0. Which is the default so you should not have to do anything.
That's something I will create a better interface for at one point.

As for the demo mode. Not sure. I was thinking of creating a priorities list somewhere.
More stuff on my TODO list.  ;-)

I think the main focus or now will be finshing the HUD display, adding some more instruments and getting NMEA to work through AGWPE.
This will allow people to actually use the software.

I also need to work on the data modem. But that should not take long for the 1200 baud.

>Which file are we supposed to download from raag.org? And how do we set
>it up so RCGS can use it?
>
>Any idea when the "Demo" mode will be ready?

RE: [rcpilot-devs] HUD design???

[Michael J. P. <mi...@vi...>]

Well I wasn't thinking comm stuff right away. But that is coming soon!  ;-)

I would have to go through the sentences to see which ones are apropriate.
But this is how I see it.

There is a preference that the user sets to choose between NMEA1083 and Amateur UAV Data Protocol.

The data itself will still come in through AGWPE as a datakind "K".
I created a new class called AGWAX25.java. This is were the parsing is done for Raw AX25 frames.
It contains all the info inside of them. But all we really care about for now if the "info" field.
Basically depending on the user setting, we either parse it one way or the other.

Perhaps we need to re-think the flow a little though from Awgpe.java

The final options as I see it will be:

Serial or AGWPE
and
Amateur UAV Data Protocol ot NMEA1083.

Well I shouldn't say final. Since we might want to add more protocols later on.
Basically I would like the ground station to be able to be used by as many people as possible.

For the GPS we should simply look at the string.
And depending on which one we get, we send it to a method to parse it that will set Telemetry Data.

One of the cool parts of the GPS is we will get all the waypoint info as well.
This could be drawn on the map and even the Tracker as an option.
I know for the autopilot stuff I relied on GRPMB and GPRMC for the waypoints.
But it should be coded in such a way that it's easy to add sentences.

Mike

P.S. I can also send you a few sets of GPS outputs.
I have a couple of them.







*********** REPLY SEPARATOR  ***********

On 12/03/2004 at 7:41 PM Peter Wooster wrote:

>Sure, I have a Garmin eTrex GPS to play with for a few days, the data is
>pretty straight forward for the NMEA version 2 stuff.  I suspect for your
>purposes that the GPGGA sentence that contains time,longitude, latitude and
>altitude is the most interesting.  So far I've installed the javax.comm
>package and written a little program that reads the GPS output and puts it
>on the screen.
>
>What are your requirements?
>>