When doing the f3 port i noticed uart overrun errors if the usart interrupt priority was not set to PIOS_IRQ_PRIO_HIGHEST. I suspect that this may as well be a problem on other targes and probably being silently ignored.

When any baro airspeed module is compiled in, the Airspeed module consumes 100% of available CPU. This may only happen when the AirspeedSettings.AirspeedSensorType is also set to one of the baro sensors.

This is due the module only ever blocking in the code path for GPS airspeed.

The Airspeed module is a mess of #ifdefs which makes it very hard to read. Fixing that at the same time as the 100% CPU issue would be a significant improvement.

Right now all the targets have their port configurations in HwSettings. This should be factored into separate objects for each board.

For our sake and OP we should make sure our GCS is clearly different than theirs and people aren't confused. We should keep attribution to the code base but make sure the application is clearly recognizable as our fork.

So this is a big reorganization fun

• change ground/openpilotgcs to ground/gcs
• rename the app
• create logo
• update the logo / icon present in the app
• make sure to keep copyright to OP but also add ours when appropriate (e.g. in the About GCS dialog)
• change the news feed location
• update the doxygen headers and have a big doxygen cleanup

please add any other things I'm missing. Also while we are reorganizing files I think the UAVO generator templates should move to shared/

Do we want to update the vendor on the plugin spec files since we are sourcing these plugins with our distributions?

We should break down all the board IDs
CC/CC3D
Revo
RevoMini
Freedom
Quanton
F3Discovery
F4Discovery
and update the make/board files appropriately.

For pull requests builder as well as for portable release builders.

All the

#define PIOS_WDG_ACTUATOR        0x0001
#define PIOS_WDG_STABILIZATION   0x0002
#define PIOS_WDG_ATTITUDE        0x0004
#define PIOS_WDG_MANUAL          0x0008
#define PIOS_WDG_SENSORS         0x0010
#define PIOS_WDG_AUTOTUNE        0x0020
#define PIOS_WDG_SYSTEM          0x0040

should go to a common directory

Add to the 6 point calibration code to measure the cross coupling between the accels and gyros.

Now that we #121 has split up the hwsettings appropriately we can use #79 to get the appropriate HwSettings object and then have a generic configuration page which just lists those options.

https://help.github.com/articles/dealing-with-line-endings

The code needs cleanup. Also there seem to be reliability issues on mac?

Currently it looks like there only comes debug binaries out of it.
Please provide a way to trigger a release build from the main Makefile for integration into
automated builds.

So it would nice to be able to do

make androidgcs_install

and have it call

adb install -r build/androidgcs/bin/androidgcs-{release,debug}.apk

based on the debug/release build selection.

The current USB filter implementation enables only one PID or PID/VID monitoring. Also understand why it is used in the Uploader gadget instead of simply listening for a device insertion.

Currently, logfiles only have a small amount of information about the GCS and UAVO structure that was used to generate the log. It would be nice to include all the UAVO information required to read the file into a header.

Probably the fastest and easiest way to do this is to structure the logfile like an xml file, where the UAVOs are in the beginning and then the data section is just the binary UAVTalk stream.

We could also consider some approach like with kml/kmz, where the entire file is generated as an xml file, where every UAVTalk packet is exported into an XML entry.

Current state of the DiscoveryF3 port is that it assumes usb to be permanently active.
This leads to
a) bootloader always waiting on startup
b) no telemetry connection other than usb possible

When https://github.com/PhoenixPilot/PhoenixPilot/pull/103 is finished,
create a naked DiscoveryF3 target without external device assignments.

@solidgoldbomb do we really need this? The FlyingF3 runs just fine when there is nothing attached to the board.

I think we should remove all branches except "next" from the main repo and encourage all to use the github fork mechanism. Currently someon who forks gets all the branch clutter from the main repo in his fork "for free".

Currently there is a nice setup wizard written by m-thread but it is already broken on CopterControl since the introduction of 6 point calibration. It doesn't work at all for any of the other platforms. We should either find someone willing to maintain this and keep it functional for the majority of targets or remove it from the welcome screen by default.

So speak up if you are interested.

Currently each PiOS port has its own implementation of pios_dsm which shares like 99% of the code.
Than can easily be refactured into PiOS/Common.

Currently, uavos support only uint8 and int8 types. The addition of a char type would be nice, as it allows for signaling to the UAVO browser that a scalar or an array of scalars should be displayed as characters, and not the decimal ASCII value. For instance, the FirmwareIAPObj displays a long string of numbers, which in reality should resolve to a long string of characters.

This is not a showstopper for the FlyingF3 port but it would be nice to have that one complete.

See comments here https://github.com/PhoenixPilot/PhoenixPilot/pull/79#discussion_r2383050

currently the connect info structure has information about the particular connection type which isn't ideal abstraction. The link above has a suggestion how to enhance this so it will work for all drivers and present a cleaner interface.

Are there Open Source schematics & a BOM available for the new Freedom board?

Currently, there is no struct field concept in UAVOs (aside from the UAVO itself). It would be handy to be able to define arrays of structs. This will come in particularly handy for geofencing (and possibly waypoints), where memory overhead considerations force us to define multiple points per UAVO.

More specifically extend the UAVO XML representation like this;


<struct_field name='"X" type="int16_t"/>
<struct_field name="Y" type="int16_t"/>
<struct_field name="Z" type="int16_t"/>

This would then need to generate a sub structure in the C code
struct geofence_point {
int16_t x;
int16_t y;
int16_t z;
};
struct Geofence {
struct geofence_point[40];
}

This would also be very useful for the mixer where we could have


<struct_field name='"curve1" type="uint8"/>
<struct_field name='"curve2" type="uint8"/>
<struct_field name="roll" type="int16_t"/>
<struct_field name="pitch" type="int16_t"/>
<struct_field name="yaw" type="int16_t"/>

We have previously done navigation with various versions of the code pre-fork. We need to demonstrate navigation on next. At a minimum this should include navigation between 4 waypoints. In an ideal world it would involve landing.

As discussed here http://www.rcgroups.com/forums/showpost.php?p=23475295&postcount=9

PIOS_I2C seems to be a little overambitious on checking conditions to end. For FreeRTOS

semaphore_success &= (xSemaphoreTake(i2c_adapter->sem_ready, timeout) == pdTRUE);

checks that it has terminated but then teh non FreeRTOS check

while (!i2c_adapter_fsm_terminated(i2c_adapter)) ;

runs too.

While at it all the differences between the F1/F4 implementation should be reconciled.

Lilvinz said he uses a portable build for windows for his discovery work which sounds like an improvement.

This is required to have the DiscoveryF3 port run standalone.
There is working code for internal settings but it still has problems:
a) very slow
b) seems to halt the core or something similar which can lead to unwanted side effects
like ESC misbehavior because of PWM output spikes

Ok e3e3059
Bad 32c9a6b

It would be good to extend Edouard's board plugin mechanism with a dynamic plugin that generates as much of the board specific information as possible at run time. These should also be pulled from a common location whenever possible. Some things this should be easy

• Board ID / type
• VID / PID
• Board name
• Image of the board

some might be harder

• Interface to configuring the hw options (see also https://github.com/PhoenixPilot/PhoenixPilot/issues/85)
• UI for the above (QML?)
• Which output pins are on which setting (output settings rate)

The ability to easily know when an alarm is set for the GCS is critical. To make it more obvious two things should be added:

1. an option for a reduced gadget display that can be put on all the workspaces which has a color/label indicating the highest warning label
2. if Qt can support it, an option to make the alarms float over GCS semi-transparently where there is an alarm

Currently its disabled at pios_config.h but enabling and using it in hwsettings just leads to watchdog reset.

Currently, if a UAVO is changed but only in the UAVO browser, the background turns green. When the user clicks send or save the background turns white. It would be a nice feature if the background turned white only when the user clicked save, and turned another color when the send button was used.

Note, this should not be seen as an attempt to know if the flight controller has saved, or otherwise received the UAVO change request. The goal of this is a to be a purely visual feedback to remind the user what state s/he has requested.

In uavtalk.cpp this check

if (rxObj == NULL && rxType != TYPE_OBJ_REQ)

can result in a crash if the object is null but it is not that transaction type. In this case

rxObj->isSingleInstance()

triggers an exception error.

Replacing it with just the null check fixes the crash, but I'm thinking in the case where the object is null we want to send a NAK back through telemetry to the FC. This needs testing to make sure it is safe on the hardware side.

... does not work if there is any sensor missing. So e.g. on the FlyingF3 board we
cant measure sensore noise because it doesnt have a baro.

The GCS should be able to support multiple telemetry protocols, as long as those protocols can be nicely mapped to our UAVObject paradigm since it is central to the PhoenixPilot architecture.

This support can be built on top of the recent work on multiple board support, by extending it to mention what board model suports what protocol(s).

This also means that we need to implement a mechanism to tell the GCS explicitly what protocol to use when opening a hardware device - or to have protocol plugins provide an "autodetect" function to make the process automated. Please comment on this...

Currently the USB Monitor can only monitor one address. This should be extended to handle a QList of addresses (or some other mechanism) so Quantom can use it's own addresses (for example).

This issue is a component of https://github.com/PhoenixPilot/PhoenixPilot/issues/91
and also https://github.com/PhoenixPilot/PhoenixPilot/pull/122

We need to make sure that while rebranding the GCS all copyright is properly maintained. There's also one place in the about dialog where it should list both above ground labs and openpilot and didn't. Please list any other similar bugs here.

Here are the test builds: https://groups.google.com/forum/?pli=1#!topic/phoenixpilot/mfwikNUZ5-I

This really doesn't belong here but I want to capture some notes in case @lilvinz wants to help with this.

This affects the F3 and F4 CPUs only. The F1 doesn't have an FPU.

Summary

• OpenOCD does not currently provide proper register decode of threads that have used the FPU.
• FreeRTOS uses a feature of the M4 CPU to allow it to use lazy stacking of FPU registers only when absolutely necessary. This is a huge win for efficiency.
• Threads that use the FPU often show up as having a PC of 0x00000000 (or possibly any other random PC depending on the contents of floating-point register s22.
• Backtraces don't work for the threads using the FPU which makes debugging difficult.

Stack when FPU is NOT active:

SP -> r4
+ 4   r5
+ 8   r6
...   r7
      r8
      r9
      r10
      r11
      LR_svc == 0xfffffffd
      r0
      r1
      r2
      r3
      r12
      LR
      RA (PC)
      xSPR

Stack when FPU is active:

SP -> r4
+ 4   r5
+ 8   r6
...   r7
      r8
      r9
      r10
      r11
      LR_svc == 0xffffffed  (the 0x10 bit being cleared indicates FPU active)
      s16
      s17
      s18
      s19
      s20
      s21
      s22
      s23
      s24
      s25
      s26
      s27
      s28
      s29
      s30
      s31
      r0
      r1
      r2
      r3
      r12
      LR
      RA (PC)
      xSPR

Notes

• The LR register is banked. There is a different LR depending on which CPU mode you are in [http://en.wikipedia.org/wiki/ARM_architecture#Registers]
• When in SVC mode, the LR holds the EXC_RETURN value. The 0x10 bit tracks whether the FPU is active.
• OpenOCD uses a fixed stack definition for each CPU.
  • See: rtos_standard_stackings.c::rtos_standard_Cortex_M3_stack_offsets[]
• FreeRTOS decoding in OpenOCD chooses a single stacking.
  • See FreeRTOS.c::FreeRTOS_params_list[]
• OpenOCD FreeRTOS code would have to change to use one of two possible stack decodes.
  • Changes would be in: FreeRTOS.c::FreeRTOS_get_thread_reg_list()

References

• Arm v7-M Architecture Reference Manual: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0403c/index.html
• See section B1.5.8 in ARM v7-M Architecture Reference Manual for an explanation of the EXC_RETURN value.
• See also "Lazy context save of FP state" in the same manual.

What i currently see is that the uart vcp bridge code just uses the constant baudrate from hw_defs.
It should use ComUsbBridgeSpeed from ModuleSettings UAVO.

Because of the tricks I got up to when moving waypoints to stop circular calculations adding a waypoint on the map doesn't update the NED location.

As this will be one of the reference platforms the pinout has to be chosen wisely.
After this has been done, the pinout.txt has to be changed as well as the hardware definitions file.
Thats what this task is.

There are a number of drivers in PiOS/Common which use the StdPeriph functions for GPIO access.

PIOS_GPIO exists but possibly(?) isn't used and the little that's there was built for a different purpose. If it's not being used it could be replaced and given a new API, one to be used by the PiOS/Common drivers rather than modules in userspace.

Thoughts on replacing pios_gpio?

Affected drivers are:

• pios_bmp085
• pios_hcsr04
• pios_hmc5843
• pios_hmc5883
• pios_sbus
• pios_video
• pios_wavplay
• pios_dsm (once it is re-factored into PiOS/Common)

Based on work by Lilvinz (thanks!), bring in F3 Discovery board support into our project. DiscoveryF4 support will also be included if possible, as a non-reference board.