Difference between revisions of "Software Wish List"

From PaparazziUAV
Jump to navigation Jump to search
m
Line 77: Line 77:


=== IVY ===
=== IVY ===
# Make Paparazzi compatible with IVY-C from SVN at this moment 3.11
# Make Paparazzi compatible with IVY-C from SVN at this moment 3.11
# Make Paparazzi compile and compatible with with IVY-Ocaml library from SVN at this moment 1.1.11
# Make Paparazzi compile and compatible with with IVY-Ocaml library from SVN at this moment 1.1.11
== From Old TODO ==
add date/time of generation in generated code
##############################################################
add an irc client to morphix - preconfigured for paparazzi channel
make clean doesn't delete boa config
make a "single node" mode where boa isn't needed and serve file:// URL
force ivybus to 127 in single node
default to that mode
######################################## obsolete ? ##############
dans flybywire
chop servo ne depends pas du servo
pour les missions
possibilit� de "transformer" (rotation Z, translation XYZ) une mission
possibilitite de faire la meme chose pour une partie des waypoints (on en a une partie pour les evolutions et une partie pour le circuit d'atterissage. On deplace ceux du circuit d'atterissage pour qu'il colle a la piste. et on deplace ceux des evolution pour etre en face du jury :)
On stocke la/les transformations et on peut avoir des missions communes muret/ricou         
des declarations de points locales aux blocs et des transformations par blocs
faire medit avec visu3d
proposer d'ajouter un waypoint en relatif par rapport a un autre - et en coordonnees polaires (dist, QDM)
l'interface du captureur de video - c'est aussi visu3d . Il a une liste de textures (photos) et on peut les transformer. La description est sauv�es dans un fichier xml et peut etre recharg�e. les photos vont dans var/photos
dans visu3d, il faudrait pouvoir pivoter en Z sur la position courante (en tenant compte du zoom )
######################
logger les simus comme les vols - y penser en refaisant receive - code commun
Pour les simus a plusieurs avions, il doit y avoir partage d'un certain nombre d'informations entre les differentes instances des simu (par exemple le vent)
Dans un circle, il faut afficher le QDR - calcul au sol??
Pour les missions, il faudrait pouvoir dire . faire un cercle pendant 180� ou faire un cercle pendant n secondes. Il faudrait donc disposer du temps depuis le block et du de l'angle parcouru depuis le debut du cercle.
C'est pour faire un palier en haut de la mont�. Pour laisser le terme accumulateur se recaler avant la descente.
###########################################
Sujet : procedure automatique d'interuption de vol pour microdrone
-identifier des scenarios:
cause de l'interuption : autonomie, meteo, defaillance systeme
-modeliser la zone d'evolution et les autres contraintres (systemes defaillants, meteo)
(dans un meeting, on veut a tout prix eviter le public, les routes etc...)
- initialisation
- iteratif ?
#######################################
integrer les gazs pour estimer l'autonomie restante
###########################################
Sujet Drone Thales
Les eleves (1A ou 2A) construisent un avion et apprennent a le faire voler d'ici juillet.
commande PCB
commande composants radiospare/melexys/coronis/ublox
labo pour assembler (labo micro onde ?)
commande garat (avion, moteur, servos, batteries, radiocommande etc....)
achat de petit outillage (dremel, fer a souder etc...)
assemblage au labo drone
cours de pilotages sur le twinstar
On leur donne les petits projets pendant l'ann�e sur Paparazzi.
############################################
mettre les projets enac sur la page web enac
############################################
Pourquoi on ne laisse pas message.xml modifiable, pour les taux de telemesure par exemple.
on split les Makefiles
###########
manque gerbmerge dans les dependance??? ha non ca n'existe pas... a packager !
> - Pitch should more be in degree than in radian in flight plan files.
>It could be in the future version of Paparazzi.
>
>
> - It's strange MIN_HEIGHT_CARROT and MAX_HEIGHT_CARROT are in the
>code. Shouldn't it be in a conf file so as to change it ?
>
- In the same way, MIN_SPEED_FOR_TAKEOFF should be in the airframe
conf file ?

Revision as of 09:00, 1 March 2011

Please use the Discussion tab at the top of the page, as appropriate

Introduction

After you played around with the GCS, the Airborne code, tested it and used all it's possibilities, sometimes you get this feeling... "I would like to have more!". The first thing to do is to ask in the mailinglist if it is already possible. The next great thing would be to create what you think is lacking and give it back to the community so it could be part of the project in the future. If you are not that gifted yet, you could present your ideas here. Other enthusiastic Paparazzi developers could read this and think: "YEAH, now that is a really cool idea and I will start working on it right away!". Therefore, since everyone can improve a part of the project, note here what you would like to see added or improved in the software.

Ground Station Suggestions

  1. Integration with modue for OpenJAUS, see for already available code http://code.google.com/p/openjaus/ (Suggested by OpenUAS)
  2. Support for stanag 4586 compliance, see http://www.innuvativesystems.com/stanag_4586_primer.html (Suggested by OpenUAS)
  3. Support for standard map files like GeoTiff, .tab and .map. Using the .xml method manually is rather time consuming and frustrating when you already have standard georeferenced images.
  4. Divide the flight plan into 3 separate files (Suggested by Jeremy)
    • Takeoff/Landing - flight plan blocks describing the complex routines and using altitudes and waypoints from the User file
    • Generic - a file that users should never need to edit, containing circles, rectangles, figure-8's, and surveys that appear on command when GCS buttons are pressed. Altitude/locations could be relative to the User file
    • User - Here we can specify fixed or dynamic Home point and add complex routines or simply save certain basic routines.
    • (NOTE: All of this is already possible, investigate time in discovering what paparazzi already can do now e.g. see Flight Plan Procedures)
  5. The possibility to use multiple ground modem connected to a single ground station. The RSSI could be use to dynamically choose which currently has the best signal. This would allow the use of different antennas on each of the modems or have antenna pointing in different directions(?Possibly more hardware related)
  6. PFD - the horizon and the sky shouldn't move only the main line. Because we are on the ground and we really need to see the roll angle of the UAS and not the real PFD like on a real airplane. And we could also see, the pitch angle, to see if the UAS is climbing or going down. Another way this could be done is to use a 3D model of the plane like procerus does on there ap. For those unfamiliar with this it is like you are in the view point of like 5m behind the plane. This might give the user just enough of a model to help fly back under manual control or at least have a better understanding of the orientation. This idea is good one but it should not replace the current pfd but rather be an option to use in the gcs. (NOTE: Already possible, via Papgets it is possible to add all kinds of such types of information. Also for a 3D plane view this is already possible, just bind you output to FlightGear)
  7. Language packs for the GCS - English, French, German, Italian, Spanish, Portuguese, ... (azoreanuav(at)gmail.comI would like to make the portuguese pack, but I neet help how to do it.)
  8. Flashing via modems - (NOTE: Already possible)

Airborne Software Suggestions

Add your ideas here what you would like to see added or improved in the airborne software

Stability

  • Auto-tuning of gains
    It would make paparazzi very user friendly if the airframe could tune itself. It should be possible to set the gains on the ground to some generic value and let the autopilot do the tuning in the air. The autopilot would give step functions on different inputs (actuators, target values) and measure the response of the airframe. One at a time, of course. Based on this response measurement the autopilot can tune the control gains itself. For safety reasons this auto-tuning function would run only on safe flight altitude.

Navigation

  • Flight plan stage sensing
    Carrot should continue past the waypoint toward the next point, but the point should not be officially acknowledged until the plane has passed it. This way we can have smooth, intelligent navigation while still considering waypoint triggers such as still-photo, sensor drop, or throttle off.

NOTE: Can already be done by setting the approaching_time attribute. This value helps to decide when the target is reached. It can be set to 0 to go over the target waypoint. see Flightplan documentation

Other

  1. Revised autopilot modes (Jeremy)
    • I propose a restructuring of the modes as follows - create 3 top-level modes: Man, Stab,and Auto, each with an appended autonomous sub-mode (i.e. Man/Climb, Stab/Kill, Auto/Landing, etc.) This will give the operator much more information and a much better indication of what the plane will do when switched to autonomous mode in a concise manner. Furthermore, I see an advantage in having simple behaviors like Climb, Landing, etc. be defined as sub-modes so that operator is always alerted of changes such as Descent or can easily configure trim, gains, and payload options in the airframe file (i.e. if mode = Landing then retract camera, turn off video system, use landing trim, etc.)
    • Sub-modes
    • Ground - The default boot mode. In this mode the throttle is locked at 0% or not armed at all (no PWM signal), stability is disabled (servos locked in neutral position), and video power is off, but flight plan blocks are processed. This will improve safety and aid in lost plane retreival as the servos, and video will not drain the battery if landing detection is implemented. Ground mode should exit only if Takeoff is manually triggered.
    • Takeoff - 3 possible triggers: GCS button, GPIO button, or R/C throttle. Checks for error modes and desired climb, then arms/unlocks throttle, initates "Takeoff" flight plan block, and instantly deroutes to Climb mode. Deroutes to Descent mode without unlocking throttle if not OK. Takeoff could simply be a flag rather than a "mode".
    • Climb - Triggered anytime "aggressive climb" is active
    • Descent - Triggered anytime "aggressive descent" is active
    • Nav - Normal level flight
    • Landing - Same as Nav but using the "Landing" flight plan block and any airframe gains/trims/payload options as defined in airframe.xml
    • Kill - Triggered manually - locks throttle at 0% and uses pitch/roll settings from Airframe.xml.
  2. Error sub-modes
    • No GPS - A temporary mode using pitch/roll settings from airframe.xml
    • Home - Triggered by distance in Auto mode or by distance/RC loss in Stab mode (after n seconds, as defined in airframe.xml). Exits upon manual block/mode change requests from the GCS and cannot be re-initiated for 30 seconds.
  3. Continually broadcast last known location
    • AP should continue to broadcast the last known GPS coordinate in the event of GPS loss. (i.e. upside-down crashed plane should continue to send last known position in case it was out of data range prior to the crash.)
    • (NOTE: Possible by adding for example a module that grabs current coordinates at e.g. .1 Hz and if in flightplan <while cond="!GpsFixValid()"/> send whatever you want)
  4. Ability to upload waypoints in flight
    • I know this has been discussed a few times but it would be nice to at least have the option to upload waypoints and blocks and be able to change blocks in flight. This is risky but most Autopilot's do have this feature now and it would be nice if the user could make this decision.
    • (NOTE: A possible current solution is by adding duplicate waypoints very close and if needed move these while in flight.)
  5. Radio Control of UAS through Data Link
    • This simply means that instead of hacking an RC receiver to output it to the autopilot board why not hook your RC transmitter up through your computer and use the data link for RC. This would be nice especially with all the new RC range issues the 2 layer tiny 2.11 has brought on. Also it would be nice because RC interference would be eliminated. Please comment on this and tell me what you think
    • (NOTE: Already possible)
    • (Response: Sort of possible. The only work that has been done in this direction is by Martin and was done with a Joystick which only worked in Auto1 mode (setting the set points for the AP). This is not a full solution. What i am proposing is that the RC Radio is plugged into the GCS directly and then sends the command (PPM) signals directly to the AP. This would allow for the user to control the aircraft in manual and AUTO1. Consult any commercial AP and you will notice that this is the one glaring feature which is missing from PPRZ. In addition adding this feature would allow for longer range FPV flying. Please correct me (with links) if i am wrong.
  1. Precision Surveying
    • It would be nice to have a survey function that could survey a sector and also be told what coordinates to begin the survey on. Another useful feature would be to have the plane sense when it is done surveying the whole area so it could move to the next block. I know that the entering the survey can be done in a roundabout method by defining a waypoint at the entry point and then going to it but defining it in the survey function would allow for more precise survey since that first sweep would already be defined and then would not be affected by if the plane went into the survey function at weird spot or something.
    • (NOTE: Already possible, see the Polygon Survey and use it smartly

Current Code and Build

If you have any suggestions to improve the current:

  • Sourcecode
  • Build process
  • Code repository
  • Tools used

...give your suggestions here. Better still, start working on what you can, and add your information to the Wiki and start a discussion in the mailing list.

IVY

  1. Make Paparazzi compatible with IVY-C from SVN at this moment 3.11
  2. Make Paparazzi compile and compatible with with IVY-Ocaml library from SVN at this moment 1.1.11

From Old TODO

add date/time of generation in generated code

add an irc client to morphix - preconfigured for paparazzi channel

make clean doesn't delete boa config

make a "single node" mode where boa isn't needed and serve file:// URL force ivybus to 127 in single node default to that mode

                                                                                1. obsolete ? ##############

dans flybywire chop servo ne depends pas du servo

pour les missions possibilit� de "transformer" (rotation Z, translation XYZ) une mission

possibilitite de faire la meme chose pour une partie des waypoints (on en a une partie pour les evolutions et une partie pour le circuit d'atterissage. On deplace ceux du circuit d'atterissage pour qu'il colle a la piste. et on deplace ceux des evolution pour etre en face du jury :)


On stocke la/les transformations et on peut avoir des missions communes muret/ricou des declarations de points locales aux blocs et des transformations par blocs

faire medit avec visu3d

proposer d'ajouter un waypoint en relatif par rapport a un autre - et en coordonnees polaires (dist, QDM)

l'interface du captureur de video - c'est aussi visu3d . Il a une liste de textures (photos) et on peut les transformer. La description est sauv�es dans un fichier xml et peut etre recharg�e. les photos vont dans var/photos dans visu3d, il faudrait pouvoir pivoter en Z sur la position courante (en tenant compte du zoom )


logger les simus comme les vols - y penser en refaisant receive - code commun

Pour les simus a plusieurs avions, il doit y avoir partage d'un certain nombre d'informations entre les differentes instances des simu (par exemple le vent)

Dans un circle, il faut afficher le QDR - calcul au sol??

Pour les missions, il faudrait pouvoir dire . faire un cercle pendant 180� ou faire un cercle pendant n secondes. Il faudrait donc disposer du temps depuis le block et du de l'angle parcouru depuis le debut du cercle. C'est pour faire un palier en haut de la mont�. Pour laisser le terme accumulateur se recaler avant la descente.

Sujet : procedure automatique d'interuption de vol pour microdrone

-identifier des scenarios:

cause de l'interuption : autonomie, meteo, defaillance systeme

-modeliser la zone d'evolution et les autres contraintres (systemes defaillants, meteo)

(dans un meeting, on veut a tout prix eviter le public, les routes etc...)

- initialisation - iteratif ?

integrer les gazs pour estimer l'autonomie restante

Sujet Drone Thales

Les eleves (1A ou 2A) construisent un avion et apprennent a le faire voler d'ici juillet.

commande PCB commande composants radiospare/melexys/coronis/ublox labo pour assembler (labo micro onde ?)

commande garat (avion, moteur, servos, batteries, radiocommande etc....) achat de petit outillage (dremel, fer a souder etc...) assemblage au labo drone

cours de pilotages sur le twinstar

On leur donne les petits projets pendant l'ann�e sur Paparazzi.


mettre les projets enac sur la page web enac


Pourquoi on ne laisse pas message.xml modifiable, pour les taux de telemesure par exemple.

on split les Makefiles


manque gerbmerge dans les dependance??? ha non ca n'existe pas... a packager !

> - Pitch should more be in degree than in radian in flight plan files. >It could be in the future version of Paparazzi. > > > - It's strange MIN_HEIGHT_CARROT and MAX_HEIGHT_CARROT are in the >code. Shouldn't it be in a conf file so as to change it ? > - In the same way, MIN_SPEED_FOR_TAKEOFF should be in the airframe conf file ?