[Flightgear-users] fgfs as a Ground Control System?

2005-06-21 Thread Kitts
Hi Folks,

I am looking forward to something and would want input from all you 
Flightgear users and developers.

If i have not mentioned before, I am a mechanical engineer and an 
aero-modeler. I have also been a electronics hobbyist since my childhood. I 
set out to combine my abilities in these areas.

Apart from just plain simple model flying i decided to do something more and 
built some avionics with sensors to put onto my model aircrafts. The 
embedded software is nearing completion and i am currently working to the 
communication part of it. Now what follows is the interesting part to me...

I would like to use FLightGear as the Ground Control System (GCS) for my 
aircraft thus throwing it into the class of mini UAV's. My current thoughts 
supports an ASCII mode and a binary mode of communication. The ASCII mode 
is much like NMEA protocol. This is the part that i have finished 
developing (ASCII is easy for debugging ;-)). I am yet to implement the 
binary mode of communication.

In using FlightGear as a GCS, i would like to receive any inputs from fellow 
users and developers. How complicated would it be to do this. My current 
thoughts are as follows;

I start flightgear with --fdm=external (or NULL; What is the difference?) 
and set it to receive a generic protocol over the serial port and at say, 
4Hz. The generic protocol is suitably written to accept 6 degree of freedom 
information from my device.

Simultaneously, i would like to transmit control surface information which 
my device will receive and accordingly control the servos onboard.

While this just might work, i want to do better than this and hence plan 
accordingly. I would like to extend the protocol to be more configurable, 
and interactive. Further, I have video being streamed from onboard the 
aircraft in an analog form. To convert this i use a TV tuner and interface 
it with the computer. I got myself an external Pinnacle PCTV USB2 tuner so 
i can use with a laptop, but unfortunately cant get it to work on linux 
where i do my development. Anyway, assuming that i get the drivers 
configured right, i would like to get the video too into FlightGear be it 
running on any platform.

Here is my estimate of what needs to be done to achieve all of this through 
FlightGear.

1) Add another protocol under Network which can communicate with my hardware 
and read/modify internal properties appropriately. I will have to add more 
property values for this device.

2) Add menu items that provide user interface with the hardware. This may 
not be very difficult as from what i recollect reading, FlightGear provides 
facility for adding menus etc.?

3) Add parameters to the Headsup Display. This again i remember reading as 
configurable?

4) Embed a small window where live video is displayed. Preferably it should 
be possible toggle full screen live Video and embed FlightGears native 
Scenery display. I should also be able to save the video synchronized with 
all other property values.

I suppose the major challenge is with the 4th point while the rest are 
relatively easy. Correct me if i am wrong.

Another important thing is the FDM. What should i use? I am unable to send 
all data set in the --native protocol from onboard. Is there a possibility 
that i fly with the FDM running locally and i only update values that i 
can?

I am not a C++ programmer but a C programmer in the embedded world. I am 
just stepping into C++ with FlightGear. Any advise,suggestions or guidance 
that helps is most welcome.

FlightGear is truly an amazing piece of work with huge potential. I just 
want to add one more possibility. Does anybody already use it for such a 
purpose?

-- 
Cheers!
Kitts


___
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-users] fgfs as a Ground Control System?

2005-06-21 Thread Curtis L. Olson

Kitts wrote:

I am looking forward to something and would want input from all you 
Flightgear users and developers.


If i have not mentioned before, I am a mechanical engineer and an 
aero-modeler. I have also been a electronics hobbyist since my childhood. I 
set out to combine my abilities in these areas.


Apart from just plain simple model flying i decided to do something more and 
built some avionics with sensors to put onto my model aircrafts. The 
embedded software is nearing completion and i am currently working to the 
communication part of it. Now what follows is the interesting part to me...
 



Hi Kitts,

I think there are at least a few others involved in FlightGear that are 
doing or have plans of doing similar things ... myself included.  I 
actually have two projects in the works.  One through the University of 
Minnesta where I assembled the airframe and am now the chief test pilot 
(http://www.flightgear.org/~curt/Models/Construction/Rascal110/) and the 
second is my home project where I have to figure out everything myself 
(http://www.flightgear.org/~curt/Models/Current/EGN-1/)


Do you have any sort of web site for your project or pictures or details 
of exactly what you are doing?  As my own projects progress, I'm 
becoming increasingly interested in this stuff.


I would like to use FLightGear as the Ground Control System (GCS) for my 
aircraft thus throwing it into the class of mini UAV's. My current thoughts 
supports an ASCII mode and a binary mode of communication. The ASCII mode 
is much like NMEA protocol. This is the part that i have finished 
developing (ASCII is easy for debugging ;-)). I am yet to implement the 
binary mode of communication.
 



I think this sort of thing is very doable.  If you have a gps onboard 
and can transmit that data to your ground station, that get's you pretty 
far.  You can compute estimates for a lot of the parameters that aren't 
available directly from the gps.  If you pass this data to FlightGear, 
then you immediately have a system that provides a live synthetic view 
from the perspective of your UAV.  You can also adapt or create a 2d 
panel which would give you a set of live gauges ... heading, altitude, 
velocity, rate of climb (est), attitude (est).  You could do this as old 
style steam gauges, you could do it as a hud, or even possibly a modern 
looking glass cockpit, or all of the above.


In using FlightGear as a GCS, i would like to receive any inputs from fellow 
users and developers. How complicated would it be to do this. My current 
thoughts are as follows;


I start flightgear with --fdm=external (or NULL; What is the difference?) 
 



--fdm=null is the proper form, --fdm=external is the same thing and is 
there for historical reasons.


and set it to receive a generic protocol over the serial port and at say, 
4Hz. The generic protocol is suitably written to accept 6 degree of freedom 
information from my device.


Simultaneously, i would like to transmit control surface information which 
my device will receive and accordingly control the servos onboard.
 



Ahh, ok, so you want to live dangerously!  This I think is doable, 
although I'd be a bit worried about latencies and lags and the PIO's 
that might result if you aren't careful.  If it was me, I'd at least 
make the system self stable (IR co-pilot, or something gyro based) so 
that I wouldn't have to manually keep the wings level or hold a 
particular pitch or speed.  The ground station could send higher level 
commands like fly to such and such waypoint, or hold such and such 
heading and altitude ...


While this just might work, i want to do better than this and hence plan 
accordingly. I would like to extend the protocol to be more configurable, 
and interactive.




There has been discussion of implimenting an xml configurable binary 
format.  That doesn't help you if you want to adjust the fields in real 
time, but I'm not sure you want to add that kind of complexity to a 
system where a very small bug can ruin your day/week/month.


Further, I have video being streamed from onboard the 
aircraft in an analog form. To convert this i use a TV tuner and interface 
it with the computer. I got myself an external Pinnacle PCTV USB2 tuner so 
i can use with a laptop, but unfortunately cant get it to work on linux 
where i do my development. Anyway, assuming that i get the drivers 
configured right, i would like to get the video too into FlightGear be it 
running on any platform.
 



Someone mentioned that they were working on integrating a live video 
stream into FlightGear.  Perhaps you can search the archives, or perhaps 
they will speak up.  I got the impression that they managed to get 
something working, but that it might have been kind of a hack job 
specific to their particular needs.  No code was submitted to the 
project that I'm aware of.


Here is my estimate of what needs to be done to achieve all of this through 
FlightGear.


1) Add another protocol 

Re: [Flightgear-users] fgfs as a Ground Control System?

2005-06-21 Thread Kitts
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 

Re: [Flightgear-users] fgfs as a Ground Control System?

2005-06-21 Thread Curtis L. Olson

Kitts wrote:


PIO's?
 



Pilot induced oscillations ...

CL 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?
 



The thing you have to remember about the FDM's is that they are self 
contained units that maintain their own internal state.  They aren't 
setup to have their internal values overridden by an external source, 
and there are issues and problems doing that.  For instance if you 
estimate some sequence of positions over a second or two, but you were 
hit with a gust and ended up a long ways off from the estimate, now you 
plug those new values into the FDM, it sees a huge distance travelled 
compaired to the estimate in a very short time frame, and might generate 
huge forces that could ripple through the future calculates and throw 
your estimates off even further.


You almost need a way to check point the calculations so you can backup 
to the last known good value when your next good data arrives.


It's not trivial, there are a ton of pitfalls, and our FDM's aren't 
setup to be able to do that.


Having said that, I don't think any of these things are insurmountable, 
and there might even be easy solutions to many of the challenges, but 
you'd have to go dig into the flight model code with a certain level of 
understanding of what you are doing and what you hope to accomplish 
before you are going to have any success with this approach.


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=productscategory=rf_modulessubcategory=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.
 



Where can I find a price or someone selling the maxstream module?  I'm 
must be missing the link, or do they not sell to individuals?


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] fgfs as a Ground Control System?

2005-06-21 Thread Erik Hofman

Curtis L. Olson wrote:

Kitts wrote:


CL 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?


The thing you have to remember about the FDM's is that they are self 
contained units that maintain their own internal state.  They aren't 
setup to have their internal values overridden by an external source, 
and there are issues and problems doing that. 


It might be an idea to extend the ACMS FDM, it takes some inputs (I have 
to lookup which ones, but I think it's at least lat, lon, speed and 
direction) and continues to fly until the next update.


Erik

___
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-users] fgfs as a Ground Control System?

2005-06-21 Thread Kitts
On Wednesday 22 Jun 2005 12:27 am IST, Curtis L. Olson wrote:

CL Kitts wrote:
CL 
CL PIO's?
CL   
CL 
CL 
CL Pilot induced oscillations ...

Oh! ok. Yeah this happens all the time when i use the keyboard in the 
simulator! :-)

CL CL I would just run with --fdm=null and pass in the 
CL CL data that you do have.  Optionally you can compute estimates for 
things 
CL CL you don't have just to make the display prettier.
CL 
CL Optionally i can compute? How? Is it not the FDM that does all that 
CL computation?
CL   
CL 
CL 
CL The thing you have to remember about the FDM's is that they are self 
CL contained units that maintain their own internal state.  They aren't 
CL setup to have their internal values overridden by an external source, 
CL and there are issues and problems doing that.  For instance if you 
CL estimate some sequence of positions over a second or two, but you were 
CL hit with a gust and ended up a long ways off from the estimate, now you 
CL plug those new values into the FDM, it sees a huge distance travelled 
CL compaired to the estimate in a very short time frame, and might generate 
CL huge forces that could ripple through the future calculates and throw 
CL your estimates off even further.
CL 
CL You almost need a way to check point the calculations so you can backup 
CL to the last known good value when your next good data arrives.
CL 
CL It's not trivial, there are a ton of pitfalls, and our FDM's aren't 
CL setup to be able to do that.
CL 
CL Having said that, I don't think any of these things are insurmountable, 
CL and there might even be easy solutions to many of the challenges, but 
CL you'd have to go dig into the flight model code with a certain level of 
CL understanding of what you are doing and what you hope to accomplish 
CL before you are going to have any success with this approach.

Hmmm... Maybe not right away but as a future thing. For the near future ill 
stick to --fdm=NULL :-)

CL I have used 3 devices till date to achieve wireless link. I have used 
RF 
CL modules from Linx 
CL 
(http://www.linxtechnologies.com/index.php?section=productscategory=rf_modulessubcategory=es_series),
 
CL BIM1 modules from Radiometrix 
CL (http://www.radiometrix.co.uk/products/bim1.htm) and XStream radio 
modems 
CL from maxstream 
CL (http://www.maxstream.net/products/xstream/module/9xstream.php).
CL 
CL Of the three, the maxstream module is what i currently use as it has 
CL provided me with the most reliable link and longest range. I have 
however, 
CL had reasonably good success with the BIM1 modules. It however requires 
CL robust error checking algorithms for reliable use. These have the 
advantage 
CL of being light weight and giving pretty good range.
CL   
CL 
CL 
CL Where can I find a price or someone selling the maxstream module?  I'm 
CL must be missing the link, or do they not sell to individuals?

Price is available on Digikey. Search for Xstream and follow that link RF 
Transmitters/REceivers. There are plenty of variants available in 2 
frequencies. Here is one such variant 
http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=195594Row=517830Site=US

-- 
Cheers!
Kitts


___
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-users] fgfs as a Ground Control System?

2005-06-21 Thread Jeff McBride

Kitts,

Your idea is an interesting one, and I would be interested is hearing 
about anything that comes of it.


I am working on a UAV project at Virginia Commonwealth University where 
we have made use of FlightGear for test purposes to fly our plane, 
hardware in the loop, on the simulator. Essentially, we wrote an 
application that would forward control positions from the on-board 
flight control system received in telemetry  into flight gear, and we 
would use the position and velocity data from the flight gear FDM to 
generate fake GPS reports that we sent to the plane in place of the 
GPS receiver.


I did consider using Flight Gear as a feed back tool while we were 
actually in flight, but we didn't really have the time or the right 
sensor information. We are using the same Co-Pilot system Curtis is 
using in his project and GPS for navigation, so we don't have any real 
attitude (pitch, roll, yaw) information, and we only get position and 
velocity updates once per second. We are working towards a system with 
rate gyros and barometric altitude/airspeed sensors, and may consider 
integrating flight gear further with our ground control station.


I do intend to create a website and publish a couple of papers about the 
project, but I am waiting until after the competition we are preparing 
for (in 2 weeks) before doing so. I will drop a note on the list about 
it when it is available in case anyone wants to take a look.


-Jeff

___
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-users] fgfs as a Ground Control System?

2005-06-21 Thread Kitts
On Wednesday 22 Jun 2005 1:35 am IST, Jeff McBride wrote:

JM Kitts,
JM 
JM Your idea is an interesting one, and I would be interested is hearing 
JM about anything that comes of it.

Thanks. Much has been done on the onboard side of this project. Soon i will 
have to concentrate on the Ground Control part of it which is the challenge 
for me. I need to gather a good understanding of the internals of 
FlightGear and improve my programming skills in C++. I just know that it is 
logically possible to do what i have in mind and set forth to do it.

JM I am working on a UAV project at Virginia Commonwealth University where 
JM we have made use of FlightGear for test purposes to fly our plane, 
JM hardware in the loop, on the simulator. Essentially, we wrote an 
JM application that would forward control positions from the on-board 
JM flight control system received in telemetry  into flight gear, and we 
JM would use the position and velocity data from the flight gear FDM to 
JM generate fake GPS reports that we sent to the plane in place of the 
JM GPS receiver.

How well does this work considering that real world weather conditions are 
very different from those in the simulator? Control surface responses are 
never similar?

JM I did consider using Flight Gear as a feed back tool while we were 
JM actually in flight, but we didn't really have the time or the right 
JM sensor information. We are using the same Co-Pilot system Curtis is 
JM using in his project and GPS for navigation, so we don't have any real 
JM attitude (pitch, roll, yaw) information, and we only get position and 
JM velocity updates once per second. We are working towards a system with 
JM rate gyros and barometric altitude/airspeed sensors, and may consider 
JM integrating flight gear further with our ground control station.
JM 
JM I do intend to create a website and publish a couple of papers about the 
JM project, but I am waiting until after the competition we are preparing 
JM for (in 2 weeks) before doing so. I will drop a note on the list about 
JM it when it is available in case anyone wants to take a look.

I, for one, would sure like to look at it. Looking at others work can spark 
new ideas and put them into perspective...

-- 
Cheers!
Kitts


___
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d