inspirati / gentlenav Goto Github PK

For completeness, we should include this in the upcoming release.

A few variables (such as GPSvelocity) were accidentally changed from ints to 
longs.

We can save some memory space by switching them back to ints, in those cases 
were longs are not needed.

I think we should pull out the following code into a library (libmatrix?  
libdonut?)

 - radio in, servo out
 - gps code
 - DCM code
 - navigation code
 - utility code to do things like sending telemetry

We'll have to decide what the interface to this library should look like.  It 
should be able to be 
fairly simple.

Then MatrixPilot will mostly be made up of code that configures the library, 
the main state 
machine, code to control the surfaces based on the rmat and waypoints, and code 
to send out 
telemetry data.

Then the Helicopter code could either be integrated with MatrixPilot, or could 
be built as another 
small program that uses the same big library.

Update Copyright lines in code header blocks

Suggested priority levels from Bill:

analog2digital.c:41:      _ADCInterrupt(void)   Priority 6
background.c:35:          _T1Interrupt(void)    Priority 5
radioIn.c:47:             _IC7Interrupt(void)   Priority 6
radioIn.c:71:             _IC8Interrupt(void)   Priority 6
radioIn.c:95:             _IC2Interrupt(void)   Priority 6
radioIn.c:119:            _IC1Interrupt(void)   Priority 6
radioIn.c:149:            _INT0Interrupt(void)  Priority 7  - measure edges of 
pulses
servoOut.c:69:            _PWMInterrupt(void)   Priority 4
servoOut.c:189:           _T4Interrupt(void)    Priority 7  - send pulses high 
and low
serialIO.c:114:           _U1RXInterrupt(void)  Priority 5
serialIO.c:200:           _U1TXInterrupt(void)  Priority 5
gpsParseCommon.c:57:      _U2RXInterrupt(void)  Priority 5 (setup in 
gpsParseUbx.c)
                                                Priority 5 (setup in gpsParseStd.c )
gpsParseCommon.c:90:      _T3Interrupt(void)    Priority 3

and there will be a new one to handle the formatting of the telemetry:

???                       _T5Interrupt(void)    Priority 1


Also suggested is moving servo output to the ADC interrupt.  We'd then just 
compute but not set 
the servo values in the pwm interrupt, and then in the ADC interrupt, have it 
choose based on 
mode whether to do a straight passthrough (manual mode) or use the computed 
values 
(stabilized/waypoint/rtl modes).

r824 has compilation error, while compiling, build failed with error "cannot 
find -legacy-libc Link step failed."

Maybe by adding a Flag that lets you set a waypoint relative to the current 
location instead of relative to the origin.

What steps will reproduce the problem?

In the function _U1TXInterrupt(void)
change:

<code>
if (txchar) { U1TXREG = txchar; }
<\code>

to:

<code>
while (txchar && (U1STAbits.UTXBF == 0)) {
U1TXREG = txchar;
txchar = udb_serial_callback_get_char_to_send(); }
<\code>

Also, in the function udb_init_USART(void)
change:

<code>
U1STA  = 0b0000010100010000;
<\code>

to:

<code>
U1STA  = 0b1000010100010000 ;
<\code>

This is setting the UTXISEL bit so it would be the same as simply adding the 
line U1STAbits.UTXISEL=1; after the current r713 version.

What is the expected output? What do you see instead?
same thing but lower cpu usage

What version of the product are you using? On what operating system?
r713

Currently RTL mode just navigates back to relative point 0,0 with the throttle 
off.

I'd like to allow the following RTL options:
 - Allow configuring RTL mode to just continue following the main waypoint set
 - Allow configuring RTL mode to use a separate waypoint set

Add Flap input and output channels.
Add code to allow mixing a flap value into ailerons when FLAPERONS are enabled.
Possibly add an F_FLAPS flag to allow automating the addition of a configurable 
flap value for specific flight legs.

Step 1: (Pete)
   Update MavLink branch to include all the latest trunk changes.
   Then reassign to ben.

Step 2: (Ben)
   Review, and then merge the MavLink branch into trunk, and test.

Based on input from Ric

- Copy relevant wiki pages into MP30 versions 

- describe each board type
- all new features: OSD, PPM, Logo, ...
- Add a page describing all compatible extra hardware
   - mag, spektrum, OSD, PPM, OpenLog, XBee, Remzibi, Extra Servos
- Describe compatible software tools: flan, WaypointEditor, UDBLogoEditor, HKGCS

- Add and seed a FAQ

Can i ask what must i go if i have no 3-way switch transmitter. Do i need to 
buy a new one because it is costly and i already have a transmitter. Can the 3 
modes still work if i use only a 2 way switch? How do i control the mode if it 
is able to work? Please advice. Thanks!

Joseph from Singapore

Add RTL options to: after entering RTL, stay in RTL mode until mode switch is 
manually moved.  But manual override should still start working as soon as 
TX-RX connection returns.

This should be added to svn so we can get more testers trying it out.

Because I was in China, it is difficult to buy the gps UBLOX

I only have the LS20033(MT3329) GPS 

What will trigger the issue: disconnecting the GPS after initial GPS lock:

Every once in a while, someone reports the following symptom: roll and pitch 
oscillations in stabilized mode while the plane is motionless on the ground. 
Recently, "eagleeye" reported the symptom. Sid was the first to observe it in 
the earliest version of MatrixPilot. Over the course of the project, I have run 
into it myself once in a while.

A long time ago, I figured out the basic mechanism that produces the effect: 
whenever the yaw error fails to get updated, a constant yaw error feeds into 
the integrator of the PI yaw feedback controller, and ramps the yaw rate 
adjustment to infinity. This causes the plane to think it is in a terrific flat 
spin, and it causes an error in the DCM computations that I have termed 
"coning", in which the plane also thinks it has rolled and pitched as well. 
Basically, the computations get entirely wrong.

We have gradually fixed the various ways the yaw error could "get stuck", but I 
see that there is a mechanism that we have missed: if the UDB loses 
communications with the GPS entirely, there will be two problems:

1. The logic for detecting loss of GPS lock will fail.
2. The DCM computations will produce gibberish, so stabilization will fail.

Fix this regression as reported by Ric.

This could start out as a directory in svn, and then also get added to the 
wiki...

Should we keep versioned documentation on the wiki?

If so, we should move the current docs to a 2.0 area, and then copy those to a 
2.5 area, and only 
then update them.

We should integrate the HIL simulation code into trunk as a compile-time option.

In just about all recent versions of MatrixPilot, gyro and accelerometer 
offsets are recorded a few seconds after the first set of wags are completed.

It would be better if they were recorded just before the wags start.

The recommended fix is to increase the time delay before the wags start, to 
greater than 10 seconds. I suggest 12 seconds, to provide a margin.

This could be a fun community-building opportunity, and could encourage 
list-members to ask 
each other for, and offer advice on setting up planes.

Maybe we should have a separate SERIAL_INPUT on/off setting like this:

#define SERIAL_OUTPUT_FORMAT           SERIAL_NONE
#define SERIAL_INPUT                                0

Hi All,

I wanted to know if I hook up a 868MHz XBee will it work with the UAV V3? 

And does the telemetry allow for the airspeed to be sent to the Ground station? 
I see the variable name air_speed_3DIMU. So I assume it does send this?

I am using the Matrix Pilot v3.0 on a delta wng airframe.

When using PPM input, we should be able to use IN 1 and IN 2 as analog inputs 
for things like battery voltage or RSSI.

This could then be added to telemetry and/or added into the OSD.

What gentlenav hardware is open source it? Where can I down to gentlenav eagle? 
Because I am in more remote countries, to purchase non-
Often inconvenient, so as make their own PCB

improve navigation and stabilization with feed-forward terms for expected 
dPitch, dRoll, and dYaw.

This could help maintain tighter control during a slow takeoff/landing, while 
avoiding oscillation at 
higher speeds.

Dead reckoning will allow the UDB to keep better track of its current location, 
independent of the 
refresh rate of the GPS.

Add customizable telemetry for Remzibi OSD (SERIAL_REMZIBI). The Remzibi OSD 
device supports 
overlay of additional information ('telemetry') by using custom NMEA sentences. 
Adding the support 
for sending these from the UDB.

This feature is made up of three main components:
 - Output of positional data, controlled by a flag in options.h (the UDB should send out its position 
(lat, long, altitude) and an identifier)
 - Parsing of received positional data from other planes, with a configurable filter (we only parse for 
a specified identifier)
 - Option in the camera_viewport field of the waypoints to target a specified UDB, by identifier. When 
this viewport is defined, the camera target will be set to the parsed position 
of the UDB matching 
the identifier.

Develop a serial bootloader (and accompanying cross-platform PC client) for the 
UDB firmware. The 
bootloader needs to program the dsPIC on the UDB with a HEX file (Intel HEX 
format created by 
MPLAB tool chain).

If possible, design the firmware so that the bootloader linked code and 
non-bootloader linked code 
can be easily switched, based on developer (user) preference.

I will start developing this for the new UDB (v3?) but based on feedback and 
comments below, I'm 
willing to also develop a boot loader for the current ('redboard') series of 
UDB.

We'll need to at least update the following:

 - The pin mappings will need to depend on the board type

 - radioIn.c will need to be updated to offer a larger number of real PWM inputs when available

 - servoOut.c will need to be updated to allow outputting to a larger number of real PWM outputs 
when available

 - no hardware switches on the new board

 - other things I'm forgetting?

This will allow the plane to control all control surfaces more efficiently, and 
will involve reworking 
the entire control layer of the code including yawControl.c, rollControl.c, 
pitchControl.c, and 
possibly altitudeControl.c, servoMix.c, and parts of servoOut.c.

Bill and Ben may want to coordinate and work on this one together.

Add support for Remzibi OSD (SERIAL_REMZIBI) without the need for a UBlox GPS. 
This can be 
accomplished by recreating the NMEA sentences Remzibi requires (RMC and GGA) 
from the data 
available.

We need to move some files around inside MatrixPilot.

 - The source files should move to a new src directory.

 - We should look again at splitting options.h and waypoints.h into 3 files, and offer a repository of 
airframes.h files for different planes.

 - We should add common open source text files: AUTHORS, README, INSTALL, COPYING, etc...

Explicit and/or implicit ellipsoid waypoint legs, and code (likely intertwined 
with dead reckoning and 
Mahoney-esque control) to tighten up the UDB's ability to keep close to the 
defined waypoint 
course.

Just a quick note to remoind us to improve the comments around #define 
BOARD_TYPE so that the comments explain to new users how to decide whether they 
have a UDB2 or UDB3 (both boards are red). Joseph Lai defined the wrong board 
because he had a Red board., and the result was that his rudder moved instead 
of the elevator. Changing the definition of board type from UDB2 to UDB3  fixed 
his problem.

Allow choosing either 2 or 4 Hz when using a ublox gps.

Fix the accelerometer problem with HILSIM

We already have this code.  It just needs to be integrated into trunk.  We 
should also probably 
rename the existing Standard GPS type to SIRF to be more accurate.

Setting this flag on the first waypoint will have the following effect:

Navigation is disabled for this waypoint leg.  The plane will remain in 
stabilized mode until a 
configurable number of seconds has passed.  A timer will start when the 
throttle value rises above 0.  
When the timer hits the configured duration, we will move on to the next 
waypoint which will then 
perform navigation.

This will allow cleaner autonomous takeoffs.

Need to implement a circular buffer for the serial link. Besides making the 
best use of available 
resources, this also needs to address the case where the serial end index is 
updated durring a call to 
sprintf in serial_output (causing the serial interrupt handler to ignore 
remaining data in the buffer)

Integrate a barometric altitude sensor to allow for much tighter altitude 
control.  This will be 
especially useful for:
 - automated landings
 - hovering helicopters and quadcopters
 - vertical hovering of fixed-wing planes
 - flying low around the SparkFun building next year

Add the ability for the UDB to navigate towards a moving target (say, another 
plane being filmed).

The requirements and specifications of this enhancement still need to be 
defined before any work 
can begin.

I think the code would be easier to read if the camera targeting options all 
started with a common 
prefix, like maybe CAM_.  Otherwise options with names like PITCH_SERVO_THROW 
are not obviously 
camera related.

This is to add support for OpenServo modules 
(http://www.sparkfun.com/commerce/product_info.php?products_id=9014) into 
MatrixPilot. The 
communication with the Open Servo module uses I2C and the initial development 
will support only 
setting the servo position.

What steps will reproduce the problem?
1. If you disconnect the GPS after intial GPS lock

What happens is that the input to the yaw drift correction becomes frozen as 
a consequence. This continuosly ramps the integrator in the PI feedback loop.

This ultimately causes extremely large errors in roll and pitch estimation.