rcpilot-devs Mailing List for R/C Pilot Project (Page 7)
Status: Beta
Brought to you by:
mjpawlowsky
Menu
▾
▴
rcpilot-devs — R/C Pilot Developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(24) |
Mar
(117) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael J. P. <mi...@vi...> - 2004-03-01 01:37:33
|
>I noticed the question of multiple planes, does this also mean multiple >TCP/IP network connetions? I'm working on the assumption that multiple >connections may be needed. It would still be only one connection. We would simply receive twice the amount of data from AGWPE. I don't even want to think about more than one plane for now. This will not be a feature that will happend soon. >I didn't get a chance to do much on this today as we took our puppy (Jet, >a 5 month old black standard poodle) to visit my parents today. We also had family over all weekend. So things have been slow.... Cheers, Mike |
|
From: Michael J. P. <mi...@vi...> - 2004-03-01 01:27:49
|
>1. Do way points show up on the tracking view? (I'm guessing we're >creating/editing waypoints in the map view, right?) As cool as that would be. That won't be possible for a while. The waypoints are pre-programmed into the GPS. We could download them to RCGS put I wasn't planning on it yet. The main reason is that bandwitdh is at a major premium. Things like pitch, roll, yaw, vertical speed and battery voltage are probably the most important pieces of data to get in. Perhaps followed by GPS coordinates, altitude etc... We also need to get them at a frequency as high as possible. This is another end I'm working on. Right now with the stuff I've made I can get 2-3 updates a second. We need about 10-20 updates a second. There are two things I'm trying to do to get there. The first is reducing the overhead in the AX.25 protocol. The second is increasing the on air baud rate. >2. This goes along with an earlier question, but could you explain each >of the data fields on the right side of the screen? What's most >important to people, and what's significant about the data? (for >example, with fuel, I imagine the users primary concern would be making >sure there's enough fuel to get back home -- if it drops low enough, >perhaps we should change the color). Absolutely for fuel. These are the alarms (part of the preferences) I was thinking of having. The would be audio/visual warnings. >3. Is there any way to group this data by category/importance? A single >column of numbers makes all the data seem like it's of equal importance, >which I'm guessing isn't the case. The best would be to allow the user to decided which ones are visible and not. I was also thinking we need to probably haved the background (vidColor) as well. No reason to block out video if we do not need to. >4. Could any of these be changed to a more visual indicator? (like a >fuel gage that looks like a vertical progress bar). That might make it >easier to read at a glance. They will be on the HUD and Instruments views. For the rest I want it to saty pretty much tabular. One thing to keep in mind is we are viewing this through LCD glasses. The down side of them id the resolution is reduced. The other thing is that the monitors are inches from your eyes and all the overlay stuff seems pretty big. >I wasn't able to connect to the testserver. I started it from the >console and got a message "Waiting for R/C Ground Station to connect on >port 8000.", started the RCGS, went to file > Connect, and... nothing >happened. We should probably add a confirmation dialog for >success/failure... The TCP/IP stuff on RCGS is not complete yet. Sorry about that. I wrote the README to fast. >Any chance we could integrate the testserver into the GUI so we didn't >have to start them in two processes? Maybe something like File > Run >Simulation? Yup that would be great.. some kind of simulator mode like on a GPS. |
|
From: PK W. <pe...@wo...> - 2004-03-01 01:13:55
|
Your definitely right about getting a usable version 1.0 out early. We shouldn't spend too much time on getting things perfect when we don't already have them working. Ian seems to be very aware of the Swing-GUI aspects of this so I'll defer to him on that and return to the network side of this. I found a good book on CVS, "Open Source Development with CVS" by Fogel and Bar. Their rule for successful projects is to "Release Something Useful" . I suggest we try to do that before the snow melts. They're predicting 8 degrees celsius with a threat of thunderstorms in Toronto tomorrow. So the snow will melt soon. I noticed the question of multiple planes, does this also mean multiple TCP/IP network connetions? I'm working on the assumption that multiple connections may be needed. I didn't get a chance to do much on this today as we took our puppy (Jet, a 5 month old black standard poodle) to visit my parents today. /peter -----Original Message----- From: Michael J. Pawlowsky [SMTP:mi...@vi...] Sent: Sunday, February 29, 2004 7:29 PM To: rcp...@li... Subject: Re: [rcpilot-devs] General GUI formatting ideas Well basically I kind of want to leave it like it is for now and simply get a working version out. I'm very open to changes, additions, deletions etc for the next versions. My experience tells me to get a decent working version out that's simple and easily doable in a small period of time. Add features etc. later on. Otherwise projects can take forever. I rather have many releases than one super duper release. Also feedback from people will help guide us where to focus efforts. As for switching tabs, the idea is to do this with a foot/hand switch. Probably a USB device. As for all the different views with not many changes. You need to remember one of the most important things is to keep as much video on the screen as possible. A quick survey I did basically showed that what people wanted the most was the HUD view. This is because it allows them to overlay the data while still being able to get maximum vision. Most of us up until now have been overlaying text on top of our video. You will see a sample output on the second page of the link I sent you earlier. Off to the other mails.... ;-) *********** REPLY SEPARATOR *********** On 2/29/2004 at 3:14 PM Ian Dallas wrote: >I've been thinking about alternatives to the tab format... > >There seems to be a lot of overlap between the various tabs, like with >the shared right frame, or the video being displayed on three different >screens. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ rcpilot-devs mailing list rcp...@li... https://lists.sourceforge.net/lists/listinfo/rcpilot-devs |
|
From: PK W. <pe...@wo...> - 2004-03-01 00:54:09
|
I agree with Ian on this, the data should be stored in a Model that is appropriate for the application, then you can wrap that Model in an AbstractTable Model and create as many JTables from that as you need. For the underlying model I'd be tempted to use some kind of Map class so you can reference the data by name. /peter -----Original Message----- From: Ian Dallas [SMTP:occ...@ia...] Sent: Sunday, February 29, 2004 2:22 PM To: rcp...@li... Subject: [rcpilot-devs] JTables comments > I just walked through the tutorial of the JTable class on Sun's site. > It's very much like the Mac's List Manager. Although very cool, I just > don't think it's want I want here. JTable definitely takes a lot of customization to get it working properly <g>. Keep in mind that it's strictly meant for presenting data in a GUI -- it's the "view" part of the "model/view/controller." So, for right now, it sounds like we probably shouldn't worry too much about the view aspect of it. Let's just get a native data format we're happy with and we can wrap an AbstractTableModel around it later. Generally speaking, if anyone is using classes from javax.swing.*, that's probably a bad sign, unless you're laying out something for the user interface. --ian ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ rcpilot-devs mailing list rcp...@li... https://lists.sourceforge.net/lists/listinfo/rcpilot-devs |
|
From: Michael J. P. <mi...@vi...> - 2004-03-01 00:42:41
|
Well basically I kind of want to leave it like it is for now and simply get a working version out. I'm very open to changes, additions, deletions etc for the next versions. My experience tells me to get a decent working version out that's simple and easily doable in a small period of time. Add features etc. later on. Otherwise projects can take forever. I rather have many releases than one super duper release. Also feedback from people will help guide us where to focus efforts. As for switching tabs, the idea is to do this with a foot/hand switch. Probably a USB device. As for all the different views with not many changes. You need to remember one of the most important things is to keep as much video on the screen as possible. A quick survey I did basically showed that what people wanted the most was the HUD view. This is because it allows them to overlay the data while still being able to get maximum vision. Most of us up until now have been overlaying text on top of our video. You will see a sample output on the second page of the link I sent you earlier. Off to the other mails.... ;-) *********** REPLY SEPARATOR *********** On 2/29/2004 at 3:14 PM Ian Dallas wrote: >I've been thinking about alternatives to the tab format... > >There seems to be a lot of overlap between the various tabs, like with >the shared right frame, or the video being displayed on three different >screens. |
|
From: Michael J. P. <mi...@vi...> - 2004-03-01 00:31:21
|
Well first you can get a shot at: http://www.wimac.org/projects/mpawlowsky/drone/index.html It's very old stuff and the technology is extremely outdated. But you will see where this project began and a bit of my vision of where I want it to go. My setup has changed quite a bit since then. Also http://www.cyber-flyer.com/ (Val who's on this list as well) has quite a few shots on his site. As for a HUD.... You will find one attached. That is if I can.. if it gets rejected I will e-mail it directly. *********** REPLY SEPARATOR *********** On 2/29/2004 at 3:18 PM Ian Dallas wrote: >I'd love to get a sample HUD to use while building the interface... > >--ian |
|
From: Ian D. <occ...@ia...> - 2004-02-29 23:30:56
|
I'd love to get a sample HUD to use while building the interface... --ian |
|
From: Ian D. <occ...@ia...> - 2004-02-29 23:26:31
|
I've been thinking about alternatives to the tab format... There seems to be a lot of overlap between the various tabs, like with the shared right frame, or the video being displayed on three different screens. My concern is that: * This creates a somewhat disjointed user experience; each tab feels like a bug jump. * If users are using a mouse, a tab is a fairly small target. * Tabs can't be combined. For example, you can't show the instruments AND the tracker, or the tracker AND NOT the data from the right frame. What about if, instead, we started with a HUD-centric view? The idea would that you're basically always looking at the HUD, and you can add things to that if you want, but the HUD stays exactly the same. I don't know how the control scheme would work, but one option would be to have something like a menu bar at the top, a la Internet Explorer, with options to: 1. Overlay instruments 2. Overlay data (the right frame in the current GUI) 2. Overlay the tracker 3. Switch to a map view 4. Switch to a table view When switching to map/table views, the HUD (and tracker?) could be displayed in the corner of the screen. --ian |
|
From: Ian D. <occ...@ia...> - 2004-02-29 23:04:10
|
1. Add a slider bar for the zoom level, instead of +/- buttons. This will make it easier to change, and provide one more visual indicator of how zoomed in/out you are. Also, I think the control should be in the left pane, since the right pane is shared with Map and Table views. Ideally, the zoom control should be combined with the scale value, so instead of a separate scale label, we just have an indicator on the zoom level control. Is there a standard unit of measure for describing radar-like displays like this? Are users more interested in the radius of the circle, a pixel per km., or the distance between rings? What does "scale" mean in the current version? 2. Should the user be able to customize the maximum distance the plane is allowed to fly from the center (should we also allow them to set how near we let the plan fly to the edge before warning them?). 3. Should the user be able to customize how far out they can zoom? 4. If the plan flies too far away, we should warn the user. I thought perhaps we could show a flashing ring to indicate the maximum allowable distance, and perhaps a numerical indicator that shows how many meters and/or seconds they are from the edge. What's your vote? 5. If the plane is off the radar, should we show an indication of which direction off screen it is? (for example, if they zoom in really tight and the plane is no longer visible) If so, how should this be displayed? 6. Is there any reason to show data right next to the plane icon? (for example, a label with the current distance, so you can instantly tell how far away the plane is) Perhaps something the user could customize... 7. Do we want users to be able to adjust the color of the tracking overlay? (so they can adjust how much it contrasts against the video in the background) 8. Should users be able to customize how many rings are drawn? Perhaps even setting it to *just* an outer ring... > Another question for you... How are you with CVS? You can download > all the source using anonymous CVS. I would love if you took a look > at it, since I wouldn't mind at discussing a few things with Peter > and you. I'll let you know when I get a chance to setup CVS -- probably sometime in a week or so. --ian |
|
From: Ian D. <occ...@ia...> - 2004-02-29 22:50:57
|
Michael J. Pawlowsky wrote: > Have you downloaded and tried the dev version from the web site? > The tracker view is pretty much done. Oops, didn't see the updated snapshot. My bad... of course, that means I have a few *more* questions <g>. 1. Do way points show up on the tracking view? (I'm guessing we're creating/editing waypoints in the map view, right?) 2. This goes along with an earlier question, but could you explain each of the data fields on the right side of the screen? What's most important to people, and what's significant about the data? (for example, with fuel, I imagine the users primary concern would be making sure there's enough fuel to get back home -- if it drops low enough, perhaps we should change the color). 3. Is there any way to group this data by category/importance? A single column of numbers makes all the data seem like it's of equal importance, which I'm guessing isn't the case. 4. Could any of these be changed to a more visual indicator? (like a fuel gage that looks like a vertical progress bar). That might make it easier to read at a glance. I wasn't able to connect to the testserver. I started it from the console and got a message "Waiting for R/C Ground Station to connect on port 8000.", started the RCGS, went to file > Connect, and... nothing happened. We should probably add a confirmation dialog for success/failure... Any chance we could integrate the testserver into the GUI so we didn't have to start them in two processes? Maybe something like File > Run Simulation? |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 21:19:50
|
>1. Why does the user need this page? What's the most important piece of >data to them? The main idea here is that you can easily loose your sense of where the plane is. And things don't look like they do up there as they do from the ground. So you want a quick way to locate the plane and return back "Home". The center is home.. the plane points to the direction it's flying in. So you you can get a good idea how far out you are and which way you need to have the plane pointing to get back home. Anything with a blue background (vidColor) ends up being the overlay of the video from the plane. So as you see that view, you are still seing the live video feed as well. >2. Do we want to show any of the data from this page elsewhere else in >the GUI? (for example, a mini tracker in the Instrumentation View) Good idea... let's keep it for version 2. ;-) >3. What are the numbers on the right side of the page? How often are >these changed? What are some possible ranges here? What are people >looking for in the data? And how will they want to use it? (for example, > should we allow them to sort it, or scroll through past data?) Real time data there for now. An option of what is visible and what is not would be cool. But next version as well. As for the ranges, if you look at the AX.25 Frame Data Definition doc on the website you will see what the ranges can be. >4. Will users be able to control the plane from this view? How? They will be able to control it using the usual R/C Transmitter. Much later on I would like to use a Joystick, and after that be able to uplaod waypoints and routes. But these are simply a twinkle in my eye for now. >5. Pardon my ignorance, but how is the tracker view different from the >map view (aside from having a different background)? The Map view show you where the plane is in relation to a some geographical references. My plane should be over water... My plane is heading towards a mountain, or down the main street... etc. The Tracker view is really a way to get the plane back home, also if you decide to set a limit of x-distance (the outer ring) you can visually see when you are going beyond that limit. That is something else I want to have. Alarms. The first one being a out of range alarm. Also a RSSI alarm (when the receiver in the plane is loosing the signal). >6. Should there be some way of adjusting the "zoom" level for the >tracker? Is this something we should handle automatically? And should >there be a legend that indicates the current zoom level (like "100 >pixels = 1 km"?) That part is done. from 1.25 to 6,0000 something I think. I haven't decided if it will be Nautical miles or kilometers yet. At the moment it's in Nautical miles. >7. What's the behavior for a plane going beyond the edge of the tracker? Tha all depends on one setup. Generally the way I setup a plane is that if it get's out of range PCM Failsafe kicks in. (A preset value for every channel of the receiver). One of the presets turns on the autopilot so that the plane will either follow a pre-programmed route or have a waypoint of "Home" in it so it simply flies itself back into range. >8. Will we ever be tracking more than one object? Possibly in future version. We are basically using AX.25 and something similar to APRS for all this. There are many Digipeaters around and I was thinking it would be nice to add APRS support at one point so that you can take advantage of the public digipeaters to receive data whgen you personally might be out of range. But for now.. just one plane. >9. How should the plane be represented on screen? A dot? A >user-configurable icon? If you look in the Shapes.java class there is function to draw a plane and you can specify the heading. 0 being up, 180 down etc. >For the mock object that controls telemtry, however that's setup, it >would be great if it could respond to commands from the user. For the >very first version, if it's easier, we could just have it spit out a >bunch of random numbers to track, but I'd like to make the RCGS >interactive as soon as possible. Same here... I was thinking of having a simulator mode in it at one point. So you could say this course, at this speed, with winds in this direction at this speed etc. Somewhat like the simulator on a GPS. >In general, I think our goal with the mock objects for the GUI should be >to present people with a more-or-less-complete simulation. So when they >turn left, the tracker/map/instruments reflect that. That'll let people >test drive the product to see if they like it, *and* give people >experience with the RCGS before they start flying their plane with it. >Also, the preferences dialog sounds very simple -- check boxes and >textfields, I'm guessing. If you want to send me the requirements I can >dash that off too. Yup.. and a couple of color chooser etc. I will get some of the stuff together but I'm thinking kind of leave it open because I'm sure lot's of prefs will creep up while developping. So it would be nice to have 4-5 tabs and we simply add to the as need be and clean it up before the release. >How soon do we want to release a public beta? The About/Help stuff can >wait until then... I'm a little rusty on my JavaHelp, but I can bone up >on it. Also, there's no sense in writing help text until we have a GUI >that actually works, at which point we can describe to people *how* it >works. I agree there. The help will simply b e HTML files. I was thinking of asking the Web guys to do it after they are done with the site. >How soon do we want to have a fully functioning Ground Station we can >test with an actual plane? How long until the snow melts around here??? ;-) Another question for you... How are you with CVS? You can download all the source using anonymous CVS. I would love if you took a look at it, since I wouldn't mind at discussing a few things with Peter and you. Cheers, Mike |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 20:52:27
|
So many questions... Let me just ask you one to start and then I will get to yours. Have you downloaded and tried the dev version from the web site? The tracker view is pretty much done. Give me a bit and I will answer your questions in the next mail. ;-) Mike |
|
From: Ian D. <occ...@ia...> - 2004-02-29 19:47:24
|
> Cool.. What's the sitcom called? It's called Drawn Together. It hasn't aired yet. > As for the GUI... > Off of the top of my head, here are some things that we need for the Ground Station. > > 1) The HUD view > 2) The Map view - started but nothing really there > 3) A preference dialog (tabbed dialog) > 4) About/Help > > Which one would you like to work on? I will flush out some "requirements" for the one you want to work on. The tracker view seems like the most straight-forward, any chance we could start with that? I'd love to get the mock objects stuff started, and sending coordinate info seems like about the simplest thing we'll be dealing with. 1. Why does the user need this page? What's the most important piece of data to them? 2. Do we want to show any of the data from this page elsewhere else in the GUI? (for example, a mini tracker in the Instrumentation View) 3. What are the numbers on the right side of the page? How often are these changed? What are some possible ranges here? What are people looking for in the data? And how will they want to use it? (for example, should we allow them to sort it, or scroll through past data?) 4. Will users be able to control the plane from this view? How? 5. Pardon my ignorance, but how is the tracker view different from the map view (aside from having a different background)? 6. Should there be some way of adjusting the "zoom" level for the tracker? Is this something we should handle automatically? And should there be a legend that indicates the current zoom level (like "100 pixels = 1 km"?) 7. What's the behavior for a plane going beyond the edge of the tracker? 8. Will we ever be tracking more than one object? 9. How should the plane be represented on screen? A dot? A user-configurable icon? For the mock object that controls telemtry, however that's setup, it would be great if it could respond to commands from the user. For the very first version, if it's easier, we could just have it spit out a bunch of random numbers to track, but I'd like to make the RCGS interactive as soon as possible. In general, I think our goal with the mock objects for the GUI should be to present people with a more-or-less-complete simulation. So when they turn left, the tracker/map/instruments reflect that. That'll let people test drive the product to see if they like it, *and* give people experience with the RCGS before they start flying their plane with it. Also, the preferences dialog sounds very simple -- check boxes and textfields, I'm guessing. If you want to send me the requirements I can dash that off too. How soon do we want to release a public beta? The About/Help stuff can wait until then... I'm a little rusty on my JavaHelp, but I can bone up on it. Also, there's no sense in writing help text until we have a GUI that actually works, at which point we can describe to people *how* it works. How soon do we want to have a fully functioning Ground Station we can test with an actual plane? --ian |
|
From: Ian D. <occ...@ia...> - 2004-02-29 19:33:50
|
> I just walked through the tutorial of the JTable class on Sun's site. > It's very much like the Mac's List Manager. Although very cool, I just > don't think it's want I want here. JTable definitely takes a lot of customization to get it working properly <g>. Keep in mind that it's strictly meant for presenting data in a GUI -- it's the "view" part of the "model/view/controller." So, for right now, it sounds like we probably shouldn't worry too much about the view aspect of it. Let's just get a native data format we're happy with and we can wrap an AbstractTableModel around it later. Generally speaking, if anyone is using classes from javax.swing.*, that's probably a bad sign, unless you're laying out something for the user interface. --ian |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 17:44:57
|
I just walked through the tutorial of the JTable class on Sun's site. It's very much like the Mac's List Manager. Although very cool, I just don't think it's want I want here. I started to plug in my event stuff. I think what I might do to keep things easy is put all the Telemetry data in an array with the key being the same key as the id of the data type from the AX.25 frame. Then just have a bunch of finals somewhere so they can be called by the name. I need a few hours to think it threw.. ;-) Cheers, Mike *********** REPLY SEPARATOR *********** On 29/02/2004 at 7:43 AM PK Wooster wrote: >I think the best bet is to use the capabilities of the DefaultTableModel >and the JTable classes. |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 15:31:37
|
By the way Peter, if you are ever out this way let me know and we'll put you "under the hood". The expression comes from having to put something over your head on very bright sunny days to enable a decent viewing with the LCD glasses on. It makes you look like you are about to be sent to the executioner! ;-) Cheers, Mike |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 15:25:28
|
I added Pitch, Roll and Yaw to the data definitions. I also changed the IDs to more or less have groups with lots of space in between to have room to add stuff. You can see the changes at: http://rcpilot.sourceforge.net/docs/AX25DataDef.html Cheers, Mike |
|
From: PK W. <pe...@wo...> - 2004-02-29 14:41:13
|
I was going to have AGWPE call the methods in AGWPacketTransport, I've defined a structure for a packet that has two byte buffers, one for the header and one for the data. It has get and set methods for the header values. The AGWTest program is just a simple terminal that tries to use that stuff to talk to an echo server. I'll try to get to this later today. At present the code compiles clean but doesn't run, I'll get that fixed first. On tables, I did a bit of researchin old tables I have and its the AbstractTableModel that you should extend. /peter -----Original Message----- From: Michael J. Pawlowsky [SMTP:mi...@vi...] Sent: Sunday, February 29, 2004 8:40 AM To: R/C Pilot Developers List Subject: RE: [rcpilot-devs] RCGS - Telemetry Data I haven't looked at the JTable stuff yet. I guess I should :-) For some reason I see it more for stuff like listings, spreadsheets etc. But what I did yeterday will work for anything that registers to receive the events. So it doesn't really make a difference what it is. Although quite a bit more hassle to start off with then simply having some variables, it makes it easier to add objects later on. I got the cvs notices and updated with the AGW stuff. Basically what we need it to do is connect to AGWPE and then register itself. Then ask for unproto frames. I was thinking about the test server. So far I have it to replace AGWPE. So RCGS would connect to the test server. But I'm thinking of changing that to connect and register to AGWPE and then send AGWPE frames that will get passed on to RCGS. This way we can test out the functionality of RCGS easier. However the down side is that you will need to install AGWPE to test it. What do you think? *********** REPLY SEPARATOR *********** On 29/02/2004 at 7:43 AM PK Wooster wrote: >I think the best bet is to use the capabilities of the DefaultTableModel >and the JTable classes. I'll give it a try and see how well it works. I >checked in the first revisions of the AGW network code yesterday. WinCVS >got its tail in a knot as it was sending out the notification, so I don't >know if those messages went out. >/peter ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ rcpilot-devs mailing list rcp...@li... https://lists.sourceforge.net/lists/listinfo/rcpilot-devs |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 13:51:39
|
I haven't looked at the JTable stuff yet. I guess I should :-) For some reason I see it more for stuff like listings, spreadsheets etc. But what I did yeterday will work for anything that registers to receive the events. So it doesn't really make a difference what it is. Although quite a bit more hassle to start off with then simply having some variables, it makes it easier to add objects later on. I got the cvs notices and updated with the AGW stuff. Basically what we need it to do is connect to AGWPE and then register itself. Then ask for unproto frames. I was thinking about the test server. So far I have it to replace AGWPE. So RCGS would connect to the test server. But I'm thinking of changing that to connect and register to AGWPE and then send AGWPE frames that will get passed on to RCGS. This way we can test out the functionality of RCGS easier. However the down side is that you will need to install AGWPE to test it. What do you think? *********** REPLY SEPARATOR *********** On 29/02/2004 at 7:43 AM PK Wooster wrote: >I think the best bet is to use the capabilities of the DefaultTableModel >and the JTable classes. I'll give it a try and see how well it works. I >checked in the first revisions of the AGW network code yesterday. WinCVS >got its tail in a knot as it was sending out the notification, so I don't >know if those messages went out. >/peter |
|
From: PK W. <pe...@wo...> - 2004-02-29 12:54:52
|
I think the best bet is to use the capabilities of the DefaultTableModel and the JTable classes. I'll give it a try and see how well it works. I checked in the first revisions of the AGW network code yesterday. WinCVS got its tail in a knot as it was sending out the notification, so I don't know if those messages went out. /peter -----Original Message----- From: Michael J. Pawlowsky [SMTP:mi...@vi...] Sent: Sunday, February 29, 2004 5:24 AM To: R/C Pilot Developers List Subject: [rcpilot-devs] RCGS - Telemetry Data Yesterday I made a model of some telemetry data classes to test something out. Basically the issue was how to get all the "Telemetry Tables" to update without having to create a class for each one of the telemetry tables that are found in 3 of the views. So basically what will happend is that an object is created which contains the telemtry data. As data comes in, we call setData for that type of data, for instance setAltitude(1000), setSpeed(65) etc. As those are called they fire off events to let the JTextFields know they need to update themselves. Any other object that comes along later can register itself to receive these events. So basically I will get rid of the "Globals" class and replace it with a TelemetryData class and supporting classes. Might take me a few days to plug this all in. Cheers, Mike ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ rcpilot-devs mailing list rcp...@li... https://lists.sourceforge.net/lists/listinfo/rcpilot-devs |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 10:36:15
|
Yesterday I made a model of some telemetry data classes to test something out. Basically the issue was how to get all the "Telemetry Tables" to update without having to create a class for each one of the telemetry tables that are found in 3 of the views. So basically what will happend is that an object is created which contains the telemtry data. As data comes in, we call setData for that type of data, for instance setAltitude(1000), setSpeed(65) etc. As those are called they fire off events to let the JTextFields know they need to update themselves. Any other object that comes along later can register itself to receive these events. So basically I will get rid of the "Globals" class and replace it with a TelemetryData class and supporting classes. Might take me a few days to plug this all in. Cheers, Mike |
|
From: Michael J. P. <mi...@vi...> - 2004-02-29 10:21:29
|
Hi Ian, Cool.. What's the sitcom called? As for the GUI... Off of the top of my head, here are some things that we need for the Ground Station. 1) The HUD view 2) The Map view - started but nothing really there 3) A preference dialog (tabbed dialog) 4) About/Help Which one would you like to work on? I will flush out some "requirements" for the one you want to work on. Mike *********** REPLY SEPARATOR *********** On 28/02/2004 at 8:22 PM Ian Dallas wrote: >Hi, I'm Ian. > >I'll be working on the GUI... as soon as someone gives me a set of >requirements and some mock objects <g>. > >Outside of programming, I work as a Writers' Assistant on an animated >sitcom that'll air on Comedy Central starting in October 2004. > >--ian |
|
From: Ian D. <occ...@ia...> - 2004-02-29 04:34:03
|
Hi, I'm Ian. I'll be working on the GUI... as soon as someone gives me a set of requirements and some mock objects <g>. Outside of programming, I work as a Writers' Assistant on an animated sitcom that'll air on Comedy Central starting in October 2004. --ian |
|
From: Michael J. P. <mi...@vi...> - 2004-02-28 16:13:41
|
Hi Antonio, Glad to see you made it to the list! I sent you several mails but have no idea where they ended up. You might want to look at your Source Forge account. With your experience there might me 2 projects where we could really use your help. The first is the data modem. Basically we are looking for a minimum 4800 baud and preferably 9600 baud modem that can be used on the audio channel of a 2.4Ghz video transmitter. I found this web site this morning http://www.amsat.org/amsat/articles/kd2bd/9k6modem/9k6modem.html and sent the author a mail. The one negative side about his design for us is it requires 12V. I would prefer something at 5V. The second is the communications manager. This is a device that is a I2C master and listens to the other modules. The communications manager puts the AX.25 frames together from the data collected on th I2C bus and prioritizes the information and passes it along to the modem. It should also be the source of all power needs for the other modules. Simply since it will be a conveninet way to have only one connector per module. I decided to go with I2C as a communications protocol after looking at several options. I was very interested in CAN for a while but decided we didn't really need that kind of speed and the added complexity and parts made it less of a desirable solution. As well, I2C support is built into many products these days. If you are interested in actively designing either of these, or if you have something else in mind that you want to work on let me know. Cheers, Mike *********** REPLY SEPARATOR *********** >My name is Antonio Sergio Sena, im Portuguese, HamRadio operator for almost >10 years working as CT2GPW, and im an Electronics Engineer. >Im doing some work with AX.25, packet comms, telemetry systems, control and >automation in all sort of things, for quite a while. And, mostly with PIC. >Both ASM and C. >Ive read the past threads for this list, and found that there is some >interest on AX.25, FSK, and telemetry systems. So, i would like to >contribute in whatever i can. |
|
From: Antonio S. S. <as...@pr...> - 2004-02-28 15:09:34
|
Hello to all, allow me to introduce myself. My name is Antonio Sergio Sena, im Portuguese, HamRadio operator for almost 10 years working as CT2GPW, and im an Electronics Engineer. Like some of us say «my hobbie is my work», i for sure say the same. Being able to aply that knowledge to the hobbies, is a mans life luck! Im doing some work with AX.25, packet comms, telemetry systems, control and automation in all sort of things, for quite a while. And, mostly with PIC. Both ASM and C. Ive read the past threads for this list, and found that there is some interest on AX.25, FSK, and telemetry systems. So, i would like to contribute in whatever i can. You can go and have a look at http://www.qsl.net/ct2gpw/html/electronics.htm. Quite some old stuff, hasnt been update for long, but it might give you an idea of what ive done in the past. Presently, im working on wireless telemetry and sensor systems. Autonomous, low power and very integrated electronics. Ive designed some Development systems for PIC micros, that are adaptive for other technologies. At http://www.primetec.pt/products.php?sec=2&cat=1. Also, have good experience with EDA packages for simulation, schematic and pcb design. Cadence PCAD CAD and Specctra software among them. Looking forward to give some good suport and contribution for the project. Please feel free to post any questions. Regards, Antonio Sergio Sena CT2GPW |
1 message has been excluded from this view by a project administrator.
