On Tuesday 21 Jun 2005 9:08 pm IST, Curtis L. Olson wrote: CL> Kitts wrote: CL> CL> >I am looking forward to something and would want input from all you CL> >Flightgear users and developers. CL> > CL> >If i have not mentioned before, I am a mechanical engineer and an CL> >aero-modeler. I have also been a electronics hobbyist since my childhood. I CL> >set out to combine my abilities in these areas. CL> > CL> >Apart from just plain simple model flying i decided to do something more and CL> >built some avionics with sensors to put onto my model aircrafts. The CL> >embedded software is nearing completion and i am currently working to the CL> >communication part of it. Now what follows is the interesting part to me... CL> > CL> > CL> CL> Hi Kitts, CL> CL> I think there are at least a few others involved in FlightGear that are CL> doing or have plans of doing similar things ... myself included. I CL> actually have two projects in the works. One through the University of CL> Minnesta where I assembled the airframe and am now the chief test pilot CL> (http://www.flightgear.org/~curt/Models/Construction/Rascal110/) and the CL> second is my home project where I have to figure out everything myself CL> (http://www.flightgear.org/~curt/Models/Current/EGN-1/)
Wow! this is some neat work... i too would like to get a web page up and going where i shall publish all the crazy things i do! :-) CL> Do you have any sort of web site for your project or pictures or details CL> of exactly what you are doing? As my own projects progress, I'm CL> becoming increasingly interested in this stuff. I do not have any website but i can mail you with all details and pictures that you might be interested in. This indeed is very interesting work. Unfortunately, where i live, necessary equipment is not easily available, which restricts or delays much of my progress. CL> >I would like to use FLightGear as the Ground Control System (GCS) for my CL> >aircraft thus throwing it into the class of mini UAV's. My current thoughts CL> >supports an ASCII mode and a binary mode of communication. The ASCII mode CL> >is much like NMEA protocol. This is the part that i have finished CL> >developing (ASCII is easy for debugging ;-)). I am yet to implement the CL> >binary mode of communication. CL> > CL> > CL> CL> I think this sort of thing is very doable. If you have a gps onboard CL> and can transmit that data to your ground station, that get's you pretty CL> far. You can compute estimates for a lot of the parameters that aren't CL> available directly from the gps. If you pass this data to FlightGear, This is pretty much what i want to do. I have a GPS onboard but i do not send data as is received from the GPS but format it and generate packets of data to my interest and send it. The data rate is however, low at a maximum of 4Hz for Position (GPS) and about 10Hz for orientation. This causes Flightgear to not produce a smooth view. I was wondering if there could be a way to extrapolate data and correct it as new data is received. This i understand can be pretty bad if error of extrapolation was large. This could be lessened by flying in FlightGear, an aircraft model similar in performance with the real one. CL> then you immediately have a system that provides a live synthetic view CL> from the perspective of your UAV. You can also adapt or create a 2d CL> panel which would give you a set of live gauges ... heading, altitude, CL> velocity, rate of climb (est), attitude (est). You could do this as old CL> style steam gauges, you could do it as a hud, or even possibly a modern CL> looking glass cockpit, or all of the above. I would prefer a glass cockpit display with HUD as i find it most comfortable to read. But i need analog control and hence a Joystick and never a Keyboard! :-) CL> >In using FlightGear as a GCS, i would like to receive any inputs from fellow CL> >users and developers. How complicated would it be to do this. My current CL> >thoughts are as follows; CL> > CL> >I start flightgear with --fdm=external (or NULL; What is the difference?) CL> > CL> > CL> CL> --fdm=null is the proper form, --fdm=external is the same thing and is CL> there for historical reasons. Hmmm... Thought so. I found no difference using either. CL> >and set it to receive a generic protocol over the serial port and at say, CL> >4Hz. The generic protocol is suitably written to accept 6 degree of freedom CL> >information from my device. CL> > CL> >Simultaneously, i would like to transmit control surface information which CL> >my device will receive and accordingly control the servos onboard. CL> > CL> > CL> CL> Ahh, ok, so you want to live dangerously! This I think is doable, CL> although I'd be a bit worried about latencies and lags and the PIO's PIO's? CL> that might result if you aren't careful. If it was me, I'd at least CL> make the system self stable (IR co-pilot, or something gyro based) so CL> that I wouldn't have to manually keep the wings level or hold a CL> particular pitch or speed. The ground station could send higher level CL> commands like fly to such and such waypoint, or hold such and such CL> heading and altitude ... Yup! :-) Actually, this is at a later stage. I will approach this in stages. I would first use a standard Futaba R/C connected to the computer through the trainer port. and allow the computer to control the aircraft as if it were the student. In emergence the R/C still is the master and i can take over anytime. As confidence builds, ill pass more and more control to the computer. And yes i do have an amount of stabilizing onboard. The problem is that the stabilizing system is again my own design and hence i have to test it out before building confidence! :-) CL> >While this just might work, i want to do better than this and hence plan CL> >accordingly. I would like to extend the protocol to be more configurable, CL> >and interactive. CL> > CL> CL> There has been discussion of implimenting an xml configurable binary CL> format. That doesn't help you if you want to adjust the fields in real CL> time, but I'm not sure you want to add that kind of complexity to a CL> system where a very small bug can ruin your day/week/month. Glad to know this. I went through the source implementing the generic protocol and thought of how i could modify to make it binary mode. I did not look into the interactive part yet. The protocol onboard however, is interactive. I predict that as i progress through the project there will be more data to handle and it would be a waste of bandwidth to be communicating all of the data every iteration and instead doing so only when needed like when the user asks for it. SAy for example i need to switch on/off the camera, i need not send this control parameter everytime. CL> > Further, I have video being streamed from onboard the CL> >aircraft in an analog form. To convert this i use a TV tuner and interface CL> >it with the computer. I got myself an external Pinnacle PCTV USB2 tuner so CL> >i can use with a laptop, but unfortunately cant get it to work on linux CL> >where i do my development. Anyway, assuming that i get the drivers CL> >configured right, i would like to get the video too into FlightGear be it CL> >running on any platform. CL> > CL> > CL> CL> Someone mentioned that they were working on integrating a live video CL> stream into FlightGear. Perhaps you can search the archives, or perhaps CL> they will speak up. I got the impression that they managed to get CL> something working, but that it might have been kind of a hack job CL> specific to their particular needs. No code was submitted to the CL> project that I'm aware of. This is good news. I hope they speak up. That way i can get the latest information. Ill search the archives to get what i can. CL> >Here is my estimate of what needs to be done to achieve all of this through CL> >FlightGear. CL> > CL> >1) Add another protocol under Network which can communicate with my hardware CL> >and read/modify internal properties appropriately. I will have to add more CL> >property values for this device. CL> > CL> Adding a protocol is pretty straight forward, but you may want to double CL> check if you can use or adapt an existing protocol. I can adapt the NMEA protocol but by modifying it to accommodate for the strings that i use. As i mentioned i do not send the GPS strings as is. I have made my own strings with important data such as; $PDOF,<LAT>,<LON>,<ALT>,<ROLL>,<PITCH>,<GPS-HEADING>,<AIRSPEED>,<ANGLE OF ATTACK>,<ANGLE OF SIDESLIP>*<CHECKSUM> The units/format of LAT LON etc too are not of the standard form. I send them as a signed value with each step corresponding to a 1000th of an arc second. CL> >2) Add menu items that provide user interface with the hardware. This may CL> >not be very difficult as from what i recollect reading, FlightGear provides CL> >facility for adding menus etc.? CL> > CL> > CL> CL> Adding menus to adjust property values is pretty straight forward and CL> all xml configurable. If you need to put function call backs behind CL> your menus, that would be some additional effort. I am yet to get into the details of this to find out if i need to put function calls but from first sight i think i will need to if i have to have option like the one mentioned earlier. (Turning the camera on/off) CL> >3) Add parameters to the Headsup Display. This again i remember reading as CL> >configurable? CL> > CL> > CL> CL> The HUD is xml configurable, although I've never dug into it to see what CL> the limits are. CL> CL> >4) Embed a small window where live video is displayed. Preferably it should CL> >be possible toggle full screen live Video and embed FlightGears native CL> >Scenery display. I should also be able to save the video synchronized with CL> >all other property values. CL> > CL> >I suppose the major challenge is with the 4th point while the rest are CL> >relatively easy. Correct me if i am wrong. CL> > CL> > CL> CL> Yes, I think #4 presents the most technical challenges, but it shouldn't CL> at all be insurmountable. Let us know how you do. :-) Well if you say so i could make the attempt! :-) but like i said before, i am new to C++. The fact is i have done a lot of embedded programming in C and assembly but never anything for the desktop. C++ does not seem very friendly to me unless it is me who has done the whole thing! With all the derived classes and then trying to trace the base class.... and overloading and.... aah never mind! :-) CL> >Another important thing is the FDM. What should i use? I am unable to send CL> >all data set in the --native protocol from onboard. Is there a possibility CL> >that i fly with the FDM running locally and i only update values that i CL> >can? CL> > CL> > CL> CL> That won't work ... I would just run with --fdm=null and pass in the CL> data that you do have. Optionally you can compute estimates for things CL> you don't have just to make the display prettier. Optionally i can compute? How? Is it not the FDM that does all that computation? CL> >I am not a C++ programmer but a C programmer in the embedded world. I am CL> >just stepping into C++ with FlightGear. Any advise,suggestions or guidance CL> >that helps is most welcome. CL> CL> C++ knowledge comes in handy when you are writing a lot of new code, but CL> if you are just modifying or adapting existing code, I'm pretty sure CL> that a reasonable amount of "C" knowledge will allow you to bluff your CL> way through. I started out mostly just knowing "C", even today I CL> sometimes wonder if I might still code/think more like a "C" programmer CL> than a "C++" programmer. I certainly tend to avoid the fancier and more CL> obscure C++ constructs in my own code. I like to keep things readable, CL> at least for myself, it's hard to say if any one else can read my code. CL> But I will tend to [try to] err on the side of readabity over CL> performance in most cases. CL> CL> >FlightGear is truly an amazing piece of work with huge potential. I just CL> >want to add one more possibility. Does anybody already use it for such a CL> >purpose? CL> CL> You aren't the first to have this thought cross your mind, but certainly CL> there is a lot of room to advance the state of the art here (at least as CL> far as flight gear is concerned) and make FlightGear much more conducive CL> towards this sort of thing. CL> CL> What are you using for your wireless data link? I need to come up with CL> some sort of cheap wireless modem for my hobby project. The most CL> important feature for me will need to be "cheap". :-) I have used 3 devices till date to achieve wireless link. I have used RF modules from Linx (http://www.linxtechnologies.com/index.php?section=products&category=rf_modules&subcategory=es_series), BIM1 modules from Radiometrix (http://www.radiometrix.co.uk/products/bim1.htm) and XStream radio modems from maxstream (http://www.maxstream.net/products/xstream/module/9xstream.php). Of the three, the maxstream module is what i currently use as it has provided me with the most reliable link and longest range. I have however, had reasonably good success with the BIM1 modules. It however requires robust error checking algorithms for reliable use. These have the advantage of being light weight and giving pretty good range. -- Cheers! Kitts _______________________________________________ Flightgear-users mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
