Re: [Flightgear-devel] mpmap
I think maybe we need to also invite the fgms team into this discussion The only way really to get a position sat on webserver atmo is to poll a fgms telnet server.. upon its admin port.. eg telnet telnet mpserver01.flightgear.org 5001 return lines.. which are then "parsed" into various formats.. so we need to cover this scenario across anyones installation.. to make it usable.. another thought.. pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap
On Wed, May 16, 2012 at 12:15 AM, Curtis Olson wrote: > Locally I've been playing around with open layers a bit. Also web sockets. > The idea that I think would be interesting to try would be to build a > websocket interface into flightgear, then serve out the map data locally > rather than from a server. Well nowadays websockets is a good idea.. BUT still a bit "unstsable"... but definately its more the way to go and am very happy you mention that.. so this is cool.. and an idea from before https://github.com/ac001/FlightGear-MP-tools/blob/master/MP_monitor.py So the above script chek for DNS servers.. with mpserve*.. and then polls via telnet.. > > Essentially if you are running FlightGear with MP turned on and running the > mpmap in your browser, you burn your bandwidth twice to ship the same > information down your internet pipe to two separate applications. > > If you served the map from FlightGear directly, you could draw the nearby MP > traffic, local AI traffic, and not double burn your internet bandwidth at > the same time. > Which leads to the conclusion that maybe the best maybe might be to "slave a local app" eg in qt client local that queries the local isntance of fg for data.. of position etc.. > I have a basic websocket interface, but I haven't tried to integrate it into > FlightGear yet. Also we'd need to expand FlightGear's httpd interface to > also be able to serve .html and .js files -- probably from a single > authorized subdirectory for security reasons. Well thats fine.. But at #1 there are a few issues.. 1) we need to replace current "map" and == telnet mpserver 2) we need to be it work with different "reliable and selectable" maps (osm api does that mainly) and 3) we need to overlay on the map .. .. a) flight positions and .. b). nav data.. So indeed its a complex problem.. However I think if we "split up the stuff cleverly".. by a load of us having a go at it.. I think it woul be straight forwad.. I think the main "issue" is actually the "capacity" of the server.. for example a current mpmap install requires a postgres db and perl and telnet access.. Wheraes the reality is we want anyone with an account and internet facing ISP machine to be able to host.. eg with php virtual host or AWS, djano.. python instance.. etc.. google app engine... (which only spreeks port 80 in and out) or behind an nginx and port forwarding as in my case with fgx.ch.. Also the database of navdata is an issue.. But these are many issues.. So my suggestion is we start at #1 at ksfo.. and set up a new map system/ So I am prepared to lead this project.. but I must stress that we need to make it user friendly and amenable for end installers etc.. eg I dont want a new keen fligthgear player to give up in installing it on his prvate server.. because fo postgres, or no mysql etc.. I want them to be able to install and maybe even set some limits on "range" and be able to rely on navdata and etc from upstream.. somewhere.. ALSO ALSO the mainissue is a destop replacement for atlas.. and that is clear to me with marble.. which is a kde project.. and then maybe we can overlay this http://map.fgx.ch/ BUt BUT.. even beter.. If we use websockect we can be clever also.. eg we can send queries and get results of stuff. kinda IRC like and MAYBE eg /metar ksfo even /msg foobar descend and maintain 200ft /vor BNN << return data on BNN we can even replicate aircraft systems So .. Where do we go from here..?? I think we need a little bit of a plan first.. before any of us ding down a wrong path .. But we also need to recognise a proper new project and team to support.. (maybe next year GSOC we have plan for this project even... ) pete > > On May 15, 2012 5:58 PM, "Peter Morgan" wrote: >> >> I guess no one is maintain the mpmap anymore.. >> >> and I had a good look a pigeons code.. >> >> and it runs perl and google maps v2.. >> >> so google maps v3 is outta the question )too complicated to drop in) >> but also also been playing with osm >> >> So is there a plan to move forward with mpmap.. ? >> >> I have clear idea what I want to do which is make it osm compatible >> for a start.. >> and then take it from there.. >> >> So anyone else playing with this idea? anyone else done and development ? >> where can we share these new ideas as a repo ? >> >> >> pete >> >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > ---
Re: [Flightgear-devel] mpmap
Locally I've been playing around with open layers a bit. Also web sockets. The idea that I think would be interesting to try would be to build a websocket interface into flightgear, then serve out the map data locally rather than from a server. Essentially if you are running FlightGear with MP turned on and running the mpmap in your browser, you burn your bandwidth twice to ship the same information down your internet pipe to two separate applications. If you served the map from FlightGear directly, you could draw the nearby MP traffic, local AI traffic, and not double burn your internet bandwidth at the same time. I have a basic websocket interface, but I haven't tried to integrate it into FlightGear yet. Also we'd need to expand FlightGear's httpd interface to also be able to serve .html and .js files -- probably from a single authorized subdirectory for security reasons. On May 15, 2012 5:58 PM, "Peter Morgan" wrote: > I guess no one is maintain the mpmap anymore.. > > and I had a good look a pigeons code.. > > and it runs perl and google maps v2.. > > so google maps v3 is outta the question )too complicated to drop in) > but also also been playing with osm > > So is there a plan to move forward with mpmap.. ? > > I have clear idea what I want to do which is make it osm compatible > for a start.. > and then take it from there.. > > So anyone else playing with this idea? anyone else done and development ? > where can we share these new ideas as a repo ? > > > pete > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] LiDAR simulation in FG and powerline scenery
Hi Curtis, Curtis Olson wrote: > Hi Tiago, > > Just a real quick reply because no one else ahs ... > > On Mon, May 14, 2012 at 4:59 PM, Tiago Gusmão wrote: > > Hello, > > It's been a long time since i've posted here! > > I'm currently employed in a small company here in Portugal > (http://www.albatroz-eng.com/). Our main products in a system that > inspects powerlines from helicopters. > This year we are going to a big exhibition and i've suggested that it > would be interesting to have a simulator (only because we would have a > hard time flying the helicopter inside the building ;) ). > > Our solution is basically comprised of a LiDAR, an INS/GPS unit and > camera(s). > > Simulating INS/GPS is easy because all the data is in the FG tree AFAIK. > > > Yes, FlightGear provides "exact" roll, pitch, yaw (true) as well as lon, > lat, and altitude. > > > Camera(s) can be linked instances of FG with the views properly set > (perhaps captured with image server). > > > I've done some work with setting up a model of a pan/tilt camera system > that can point at a specific wgs84 point or along a specific NED vector > (i.e. nadir, or exactly at my shadow, etc.) This was [unfortunately] > for a paid consulting project so that code doesn't live in the > FlightGear tree. However, it's really easy to configure a view that > stays locked on a specific lon/lat and I hacked a small bit of nasal to > copy the point you click on over into the view target variables so you > can click any where in the scene and the pan/tilt camera will hold > center on that exact location. FlightGear offers a lot of flexibility > and comparability in this arena. I was only considering cameras that are fixed to the aircraft but we do integrate video feeds from gimbal cameras so this might be a nice idea and, as you say, probably not that hard to do. > > > LiDAR is the only part the gets tricky. Our LiDAR is placed pointing to > the side and down of the aircraft. It's a 2D LiDAR that captures > "slices" of the powerline and as the helicopter flies forward we get all > the line (like this: > http://www.albatroz-eng.com/solutions/plmi/lidar_ohl_example.PNG). > My ideia is to have an instance of FG with the camera pointed as if it > was the LiDAR and then capture a column of the Z-buffer. > > From what i understand FG has depth partitioning. I'm guessing we don't > want this active for this application. Is this correct? Is there any > "switch" for this or will i need to dive into the code? The LiDAR has > about 150m of useful range. > > Is there any "recommended" method of getting the values from the > z-buffer? From what i hear some methods have very low performance. Has > anyone tinkered with this? > > > FlightGear has the ability to intersect a vector with the terrain and > return the exact altitude of the "hit". This is essentially what we are > doing when we compute the location of the point we click on with the > mouse. However, it may not scale well to the number of intersection > tests you would need to do (per frame) for a scanning lidar system. > > Perhaps there could be a z-buffer trick you could use, but I don't know? > Maybe Fred (who's working on shadows and lighting effects) might be the > best one to comment on that since he has his head in that type of code > right now ... (?) The concept of using the z-buffer seems easy: get the pixel data with z ,apply the inverted projection matrix and from those coordinates get a distance and angle and it's done. It's the details that concern me :) > > The intersection test code does cache small bits of scenery that was > most recently used, so if you do scan across a line of terrain quickly > you might get a bunch of cache hits and have a chance at making this > work, but you'd definitely need to test it out before putting your eggs > in that basket. > > I think the problem will be doing this at a resolution that could pick > out individual power lines. I did consider that we can do intersection. We take ~400 points at 25fps in the LiDAR. I think we would be lucky to get any cables in the simulator with those sampling intervals unless we would actually model them as thick cylinders (which would impact performance a lot if we make cables with lots of segments). > > It would be possible to create models of trees and shrubs and connected > power lines and populate an area of the scenery with your custom models > -- it would be some effort, but if you can make (or locate) quality > models, the result would be quite nice. What is the state of the art for populating a map with models? I seem to remember being able to point-and-click on the terrain to "drop" a model but is there any way to make the changes permanent? > > Here's another random idea -- what about "faking" the LiDAR data or at > least some of it? I'm no
[Flightgear-devel] mpmap
I guess no one is maintain the mpmap anymore.. and I had a good look a pigeons code.. and it runs perl and google maps v2.. so google maps v3 is outta the question )too complicated to drop in) but also also been playing with osm So is there a plan to move forward with mpmap.. ? I have clear idea what I want to do which is make it osm compatible for a start.. and then take it from there.. So anyone else playing with this idea? anyone else done and development ? where can we share these new ideas as a repo ? pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] LiDAR simulation in FG and powerline scenery
Hi Tiago, Just a real quick reply because no one else ahs ... On Mon, May 14, 2012 at 4:59 PM, Tiago Gusmão wrote: > Hello, > > It's been a long time since i've posted here! > > I'm currently employed in a small company here in Portugal > (http://www.albatroz-eng.com/). Our main products in a system that > inspects powerlines from helicopters. > This year we are going to a big exhibition and i've suggested that it > would be interesting to have a simulator (only because we would have a > hard time flying the helicopter inside the building ;) ). > > Our solution is basically comprised of a LiDAR, an INS/GPS unit and > camera(s). > > Simulating INS/GPS is easy because all the data is in the FG tree AFAIK. > Yes, FlightGear provides "exact" roll, pitch, yaw (true) as well as lon, lat, and altitude. > Camera(s) can be linked instances of FG with the views properly set > (perhaps captured with image server). > I've done some work with setting up a model of a pan/tilt camera system that can point at a specific wgs84 point or along a specific NED vector (i.e. nadir, or exactly at my shadow, etc.) This was [unfortunately] for a paid consulting project so that code doesn't live in the FlightGear tree. However, it's really easy to configure a view that stays locked on a specific lon/lat and I hacked a small bit of nasal to copy the point you click on over into the view target variables so you can click any where in the scene and the pan/tilt camera will hold center on that exact location. FlightGear offers a lot of flexibility and comparability in this arena. > LiDAR is the only part the gets tricky. Our LiDAR is placed pointing to > the side and down of the aircraft. It's a 2D LiDAR that captures > "slices" of the powerline and as the helicopter flies forward we get all > the line (like this: > http://www.albatroz-eng.com/solutions/plmi/lidar_ohl_example.PNG). > My ideia is to have an instance of FG with the camera pointed as if it > was the LiDAR and then capture a column of the Z-buffer. > > From what i understand FG has depth partitioning. I'm guessing we don't > want this active for this application. Is this correct? Is there any > "switch" for this or will i need to dive into the code? The LiDAR has > about 150m of useful range. > > Is there any "recommended" method of getting the values from the > z-buffer? From what i hear some methods have very low performance. Has > anyone tinkered with this? > FlightGear has the ability to intersect a vector with the terrain and return the exact altitude of the "hit". This is essentially what we are doing when we compute the location of the point we click on with the mouse. However, it may not scale well to the number of intersection tests you would need to do (per frame) for a scanning lidar system. Perhaps there could be a z-buffer trick you could use, but I don't know? Maybe Fred (who's working on shadows and lighting effects) might be the best one to comment on that since he has his head in that type of code right now ... (?) The intersection test code does cache small bits of scenery that was most recently used, so if you do scan across a line of terrain quickly you might get a bunch of cache hits and have a chance at making this work, but you'd definitely need to test it out before putting your eggs in that basket. I think the problem will be doing this at a resolution that could pick out individual power lines. It would be possible to create models of trees and shrubs and connected power lines and populate an area of the scenery with your custom models -- it would be some effort, but if you can make (or locate) quality models, the result would be quite nice. Here's another random idea -- what about "faking" the lidar data or at least some of it? I'm not sure you would have the performance to physically model everything the way it is in real life, but if you have the aircraft location and orientation and an offline DB of your power lines, perhaps you could compute "fake" lidar data from that using special purpose code, and that could feed your lidar display? I'm sure there are several ways you could attack this and it may just mean picking the best likely approach, diving in, and then seeing how far you can get with it? Best regards, Curt. For the scenery we would need a powerline with believable trees, shrubs > and houses below and nearby (and they obviously can't be done with some > trick that results in no z-buffer entry). The scenery doesn't need to > match real world locations of powerlines. > > Do we have any part of the scenery that is suited for this? > Last time i've seen we have towers but no cables between them. Is this > still true? How should we go about solving this? > I'm guessing i could make the powerline as an extremely big model but if > it can be done with code i think we would be better served (and it would > be a nice addition to FG) > If we could crash into the powerlines it would be a good feature but > it's not
Re: [Flightgear-devel] Regional textures merge request
Hi Thorsten, > Quick question to Stuart: > > Currently the conditionals for texture selection are done using > /position/longitude-deg,... i.e. aircraft position. The actual tile > position however is different from that by the visibility and an > direction, which makes for some uncertainty. > > So, it'd be more consistent to place a condition on the position of > the tile to be loaded rather than the aircraft - is that information > exposed somewhere (or would it be difficult to do that)? I suspect that special keywords in the format of the material file and a change in the tile loader are required to do that. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Readme contains incorrect information
On Mon, 2012-05-14 at 17:00 -0400, Ian Duncan wrote: > I am an avid FlightGear user and enjoy Flight Gear very much. However, I > would like to bring something to your attention that angers me. The > readme file for the flightgear 2.60 source code contains incorrect > information. There are also other minor issues > > * There is no program called "configure" in flightgear-2.60.tar.bz2 (the > package I downloaded: it is located on all three mirrors) > * There is no makefile that I can see. (Makefile) > > Please fix this. As a user of flight gear I should not have to put up > with this. My feeling about this is, provide correct and usable software > packages, source code, and readme files so we can all enjoy flightgear. You can, we switched to cmake and probably forgot to update the readme. Just type the following in the source directory: mkdir build; cd build; cmake .. && make install Erik -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
