Re: [Flightgear-users] Network Control of FG
On Tue, 29 Mar 2005 09:45:43 -0500, Eric wrote in message [EMAIL PROTECTED]: On Thu, Mar 24, 2005 at 03:24:01PM -0500, Jeff McBride wrote: I am looking into the possibility of using FlightGear as a simulator to test flight control software that I am developing for a UAV (Unmanned Aerial Vehicle) project. The idea is that I will take control values (ailerons, throttle, etc) from the telemetry link and pass them to FG, then take the resulting location, speed, etc. from FG and pass it back to the UAV as if it were coming from the on-board GPS. Sorry for the delayed response, I just noticed this thread yesterday and wanted to talk to my employer before posting ... We have had a similar setup working in our lab for over six monthes. It is a hardware-in-the-loop simulation for testing our UAV hardware and adaptive autopilot. I am hoping to get a paper out in late Summer (at AIAA's [EMAIL PROTECTED]) which will cover the details. I'll provide an overview below. If anyone is interested in more details, let me know. From what I can tell, FG has support for this kind of thing, but no documentation of it. So, my question for the experts is what is the best way to do this? I was going to try to use the generic network interface, but as far as I can tell it doesn't support a bi-directional link. Perhaps I can run two of these (one in, one out), but is there a better way I should be looking at? There seem to be a lot of options. Our hardware, an embedded computer running Linux, interfaces with sensors and acuators via a serial port. We wrote a small briding application which reads the data from FlightGear using the native I/O (FGNetFDM and FGNetCtrls) and translates the data to the same format as produced by the sensors (i.e. the bridging application generates NMEA GPS packets). As mentioned in the thread, the code is setup to read all available data from the sockets and throw away all but the latest packet. Once everything is initialized, we can operate easily at 50Hz sending and receiving a single packet to FG within the timeslice. The controls packet contains quite a few fields and, in addition to the expected aileron, elevator, rudder, and throttle, a few others are required. I'd have to dig back through our code to see what we set if you are interested. All of the information you need to simulate your sensors should be in the FDM packet; be careful with the units. Of course, my next problem will be creating a model of the plane I am flying, but I am waiting until I get there to tackle that one. Creating the model was definately the hardest task. During initial testing, we used the models available in Flightgear, mainly the Cub, as it was one of the slowest flying airplanes. We have since developed a working JSBSim model of our R/C sized aircraft. We should have some flight test data in the next month which we will be able to compare to FlightGear to gauge how accurate our model is. Hope the information proved useful and as I mentioned above, if anyone is interested in additional details, please let me know. ..oh yeah, shoot! ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
On Thu, Mar 24, 2005 at 03:24:01PM -0500, Jeff McBride wrote: I am looking into the possibility of using FlightGear as a simulator to test flight control software that I am developing for a UAV (Unmanned Aerial Vehicle) project. The idea is that I will take control values (ailerons, throttle, etc) from the telemetry link and pass them to FG, then take the resulting location, speed, etc. from FG and pass it back to the UAV as if it were coming from the on-board GPS. Sorry for the delayed response, I just noticed this thread yesterday and wanted to talk to my employer before posting ... We have had a similar setup working in our lab for over six monthes. It is a hardware-in-the-loop simulation for testing our UAV hardware and adaptive autopilot. I am hoping to get a paper out in late Summer (at AIAA's [EMAIL PROTECTED]) which will cover the details. I'll provide an overview below. If anyone is interested in more details, let me know. From what I can tell, FG has support for this kind of thing, but no documentation of it. So, my question for the experts is what is the best way to do this? I was going to try to use the generic network interface, but as far as I can tell it doesn't support a bi-directional link. Perhaps I can run two of these (one in, one out), but is there a better way I should be looking at? There seem to be a lot of options. Our hardware, an embedded computer running Linux, interfaces with sensors and acuators via a serial port. We wrote a small briding application which reads the data from FlightGear using the native I/O (FGNetFDM and FGNetCtrls) and translates the data to the same format as produced by the sensors (i.e. the bridging application generates NMEA GPS packets). As mentioned in the thread, the code is setup to read all available data from the sockets and throw away all but the latest packet. Once everything is initialized, we can operate easily at 50Hz sending and receiving a single packet to FG within the timeslice. The controls packet contains quite a few fields and, in addition to the expected aileron, elevator, rudder, and throttle, a few others are required. I'd have to dig back through our code to see what we set if you are interested. All of the information you need to simulate your sensors should be in the FDM packet; be careful with the units. Of course, my next problem will be creating a model of the plane I am flying, but I am waiting until I get there to tackle that one. Creating the model was definately the hardest task. During initial testing, we used the models available in Flightgear, mainly the Cub, as it was one of the slowest flying airplanes. We have since developed a working JSBSim model of our R/C sized aircraft. We should have some flight test data in the next month which we will be able to compare to FlightGear to gauge how accurate our model is. Hope the information proved useful and as I mentioned above, if anyone is interested in additional details, please let me know. Eric -- Eric F. Sorton [EMAIL PROTECTED] ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
The socket interfaces *should* grap all pending packets and discard all but the most recent, so you shouldn't have a problem with building up a backlog (been there/done that.) :-) Curt. Curt, Is this true for the generic interface? I am having delay problems still, and I am looking at FGGeneric::parse_message() and FGGeneric::process() in generic.cxx and I don't see how it is discarding all but the most recent. Correct me if I'm wrong. Otherwise, I guess I'll be fixing it or switching to the CTRLS packets. Looks like an easy enough fix. Has anyone ever compiled FG on MS Visual Studio? -Jeff ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
Jeff McBride wrote: The socket interfaces *should* grap all pending packets and discard all but the most recent, so you shouldn't have a problem with building up a backlog (been there/done that.) :-) Curt. Curt, Is this true for the generic interface? I am having delay problems still, and I am looking at FGGeneric::parse_message() and FGGeneric::process() in generic.cxx and I don't see how it is discarding all but the most recent. Correct me if I'm wrong. Otherwise, I guess I'll be fixing it or switching to the CTRLS packets. Looks like an easy enough fix. Has anyone ever compiled FG on MS Visual Studio? I didn't write the generic interface so I don't know off the top of my head. If you are having delay problems and you don't see any facility for discarding extra packets, then it probably isn't doing that. The net_fdm and net_ctrls based stuff (binary structures) do discard extra packets and only keep the most recent. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
Jeff McBride wrote: I am looking into the possibility of using FlightGear as a simulator to test flight control software that I am developing for a UAV (Unmanned Aerial Vehicle) project. The idea is that I will take control values (ailerons, throttle, etc) from the telemetry link and pass them to FG, then take the resulting location, speed, etc. from FG and pass it back to the UAV as if it were coming from the on-board GPS. From what I can tell, FG has support for this kind of thing, but no documentation of it. So, my question for the experts is what is the best way to do this? I was going to try to use the generic network interface, but as far as I can tell it doesn't support a bi-directional link. Perhaps I can run two of these (one in, one out), but is there a better way I should be looking at? There seem to be a lot of options. Of course, my next problem will be creating a model of the plane I am flying, but I am waiting until I get there to tackle that one. Have a look at docs-mini/README.IO for starters. You can pass control inputs into FlightGear by creating an FGNetCTRLS (src/Network/net_ctrls.hxx) packet and sending it over to FlightGear. You can then have FlightGear send back an FGNetFDM packet (src/Network/net_fdm.hxx) which will include all the position, velocity, orientation type data. Yes, you'll eventually have to create a model of your airplane, but you can certainly iron out all the interface issues while using an existing aircraft model. I don't know how well our FDM engines scale to R/C or UAV scales, but I'd think with some fiddling around you could get something to work. I'm an R/C pilot myself, and involved in a UAV project here at the University of Minnesota, so I'll be interested to hear what you come up with. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
Arnt Karlsen wrote: ..which UAV, url? No url yet, but I can tell you it is my senior design project at Virginia Commonwealth University and it is for a AUVSI sponsored competition: http://www.bowheadsupport.com/paxweb/seafarers/default.htm ..this blows you away from the truth, as FG will not know the exact details of the weather your UAV flies in. Doing the opposite of what you propose, taking speed, altitude, etc and attitude data from the telemetry link, to FG and then have FG fly your UAV like an RC model plane, can be used to find the true weather. Etc. I was thinking something like my UAV could be sitting on the ground, but using FG to provide feedback, could think that it is flying. That way we can do a full system test without taking off. Although, I also plan to do as you say and pass on the data from the plane to FG for visualization while it is flying or for mission replay. I'm not sure if this will provide any real usefulness, but I'm pretty sure it will look cool ..it's all in the source. ;o) And here, you will be pioneering and do a paper on this, right? ;o) Ahh yes. I have figured out a good bit so far, and Curt just pointed out the Readme.IO file that I somehow missed. -Jeff ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
Jeff McBride wrote: I was thinking something like my UAV could be sitting on the ground, but using FG to provide feedback, could think that it is flying. That way we can do a full system test without taking off. For what it's worth, I saw a demo at Lockheed-Martin where they used the same basic approach to develop a test bed for their control algorithms. This way they can put their actual control hardware in the loop, rather than just a simulation of their control hardware. They used, errr, X-Plane, and couldn't stop gushing about how accurate the flight model was. But I got a chance to fly it, and was not nearly as impressed as they wanted me to be. Their model had huge amounts of adverse yaw ... small amounts of banking would result in 10-15-20 degrees of yaw with resulting dutch roll. In my attempt to land, I had the throttle pulled back to idle, and ran the entire length of a 5000' runway at about 10' AGL doing about 45 kts. without bleeding off any speed (while they insisted I was going to have to slow down if I wanted to land the thing.) Finally at the end of the runway I planted the wheels just to see what would happen. I bounced right back up to about 10' AGL but was now doing 56 kts. and accelerating ... all with the throttle idle. Either they were generating a lot of extra thrust at idle, or X-Plane was creating energy from nothing, or I want their design for my round-the-world attempt. I'm not saying the FG dyanmics models will do any better at R/C model scales ... I don't know if anyone has tried yet (?) I should also point out that the Lockheed-Martin guys had many successful real flights with their various UAV models so even with a slightly questionable flight dynamics model, they still were able to achieve pretty impressive real world results. Although, I also plan to do as you say and pass on the data from the plane to FG for visualization while it is flying or for mission replay. I'm not sure if this will provide any real usefulness, but I'm pretty sure it will look cool. I think there are a lot of interesting things you could do with this capability. If you are operating in a known environment, you could add important objects to the FG world so you could see/avoid them. You could play around with remote piloting your vehicle based on a synthetic view. I know someone was working on integrating a live video feed into FG so you would have live video + a larger surrounding synthetic context. Also I think that seeing your flight from a pilot's perspective or a virutal chase plane view will give you different (useful) information that you wouldn't get just from observing the aircraft from the ground in real life. Keep us posted! Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
Jeff McBride wrote: That is helpful. Somehow I missed that file. I have gotten the generic ASCII interface working enough to pass data back and forth. Is there any reason to switch to the binary format (CTRLS and FDM) now that I'm already started on the generic? I'm familiar with the binary interface, but if the generic interface is working for you, then I can't think of a reason to switch. One issue I'm curious about: It seems that the IO system will only read one message per period (as specified in the packet rate option). So, if I send the messages just a little too fast, a delay will keep building up indefinitely? Is this true with all the IO interfaces? The socket interfaces *should* grap all pending packets and discard all but the most recent, so you shouldn't have a problem with building up a backlog (been there/done that.) :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
On Fri, 25 Mar 2005 10:46:11 -0500, Jeff wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..which UAV, url? No url yet, but I can tell you it is my senior design project at Virginia Commonwealth University and it is for a AUVSI sponsored competition: http://www.bowheadsupport.com/paxweb/seafarers/default.htm ..this blows you away from the truth, as FG will not know the exact details of the weather your UAV flies in. Doing the opposite of what you propose, taking speed, altitude, etc and attitude data from the telemetry link, to FG and then have FG fly your UAV like an RC model plane, can be used to find the true weather. Etc. I was thinking something like my UAV could be sitting on the ground, but using FG to provide feedback, could think that it is flying. That way we can do a full system test without taking off. ..you basically want FG in the air and the UAV RC model on the ground on the same frequency so you can watch the rudders move. A can do thing, just tell your poor innocent UAV a ton of lies. ;o) Although, I also plan to do as you say and pass on the data from the plane to FG for visualization while it is flying or for mission replay. I'm not sure if this will provide any real usefulness, but I'm pretty sure it will look cool .. ;o) ..it also makes a starting point for an ATC get-outta-my-way traffic viewer and planning and maybe manouvering interface, to even warrant wooing funding from those worried .gov types. ;o) ..it's all in the source. ;o) And here, you will be pioneering and do a paper on this, right? ;o) Ahh yes. I have figured out a good bit so far, and Curt just pointed out the Readme.IO file that I somehow missed. ..ah! ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-users] Network Control of FG
Hi, I am looking into the possibility of using FlightGear as a simulator to test flight control software that I am developing for a UAV (Unmanned Aerial Vehicle) project. The idea is that I will take control values (ailerons, throttle, etc) from the telemetry link and pass them to FG, then take the resulting location, speed, etc. from FG and pass it back to the UAV as if it were coming from the on-board GPS. From what I can tell, FG has support for this kind of thing, but no documentation of it. So, my question for the experts is what is the best way to do this? I was going to try to use the generic network interface, but as far as I can tell it doesn't support a bi-directional link. Perhaps I can run two of these (one in, one out), but is there a better way I should be looking at? There seem to be a lot of options. Of course, my next problem will be creating a model of the plane I am flying, but I am waiting until I get there to tackle that one. Thanks, -Jeff ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Network Control of FG
On Thu, 24 Mar 2005 15:24:01 -0500, Jeff wrote in message [EMAIL PROTECTED]: Hi, I am looking into the possibility of using FlightGear as a simulator to test flight control software that I am developing for a UAV (Unmanned Aerial Vehicle) project. ..which UAV, url? The idea is that I will take control values (ailerons, throttle, etc) from the telemetry link and pass them to FG, then take the resulting location, speed, etc. from FG and pass it back to the UAV as if it were coming from the on-board GPS. ..this blows you away from the truth, as FG will not know the exact details of the weather your UAV flies in. Doing the opposite of what you propose, taking speed, altitude, etc and attitude data from the telemetry link, to FG and then have FG fly your UAV like an RC model plane, can be used to find the true weather. Etc. From what I can tell, FG has support for this kind of thing, but no documentation of it. ..it's all in the source. ;o) And here, you will be pioneering and do a paper on this, right? ;o) So, my question for the experts is what is the best way to do this? I was going to try to use the generic network interface, but as far as I can tell it doesn't support a bi-directional link. Perhaps I can run two of these (one in, one out), but is there a better way I should be looking at? There seem to be a lot of options. .. ;o) Of course, my next problem will be creating a model of the plane I am flying, but I am waiting until I get there to tackle that one. ..for ideas, chk the back traffic here and in FG-devel for AI traffic, Nasal, script, autopilot, some of the guys here has played with scripts flying AI airline schedules, which isn't too far from being UAV mission scripts. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
