Depending on the trim of the remote control, it can be impossible to arm/disarm the quad, since you might not be able to give the required input. Or, it might happen that disarming takes place unintentionally if trim is applied in the other direction.

We cannot get the remote's trim values on MAVRIC, right?

Hi guys,

The default gain for the vertical component of the GPS in the position estimation (Pos_kp_pos2) seems to be 0.

In simulation, it does not play very well because the altitude stays within approx 10m around a random altitude that changes at each startup.
When I set back this gain to something else (I tried 1), it works better and the estimated altitude varies as expected (minimum at 400 and no maximum).

@GregoireH @ndousse, any idea where this could come from ?

Thanks!

Hello,
I am not sure on how to say it properly.
But I think the attitude estimation is corrupted by high wind compensiation.
Leading to horrible behaviors in manual & autonomous mode. it start going in a good direction and then goes the opposite way...
Do you have any clue where this happen and how to improve it ?
Thanks

i.e. you can switch directly to all armed modes even if you didn't pass through the arming phase (button 1).

(Moved from #140)
Newer versions of QGC display a warning because the message MISSIONS_COUNT is not answered.

The files i2c_driver.h, i2c_driver_int.h, and i2c_driver_dma.h cannot be included at the same time in a project because of double defined symbols.

The new QGC (v.2.7.1) requires the onboard parameter COM_RC_IN_MODE which indicates how the UAV is controlled:

• 0: RC transmitter
• 1: No control
• 2: Control over mavlink (i.e. Joystick)

c.f. https://pixhawk.org/firmware/parameters

Hello,

I was wondering why I could not use the "Got to implementation" tool of Atmel for mavlink_message_t in a lot of files. And i figured out that we are missing the #include "mavlink_types.h" in most of the file.
It does compile because those files points to some other files which them self include others... up to protocol.h which is the only one to include "mavlink_types.h"

So i was wondering why we were not including each time we need something from an other file.
Normally, thanks to our
#ifndef MAVLINK_STREAM_H_
#define MAVLINK_STREAM_H_
...
#endif
we should not have issues while including from multiples files

So what is the rule to adopt ?
Shall we include anytime we use something out of the file or only when we get a compilation error ?

All the Best

task_return_t is not used in the scheduler.
Also, it forces to include scheduler.h everywhere.

I propose to return a bool in task functions.

We could use travis to keep our documentation up to date.

It is not something complicated to do (the few commands given in the wiki can be turned into a travis script). The only thing to be careful is to call the script only when something is pushed/merged to master, and not the other branches.

In runtime/scheduler.c, the round robin strategy is not properly implemented.
The variable scheduler->task_set->current_schedule_slot is always equal to 0, so the for loop (on this line) always starts from i=0, which is equivalent to FIXED_PRIORITY.

See details in issue #115

Felix developed a mavlink bootloader, this allows to flash an autopilot without usb cable, nor JTAG programmer.

We still have to test it.

While discussing with Simon, from ETH, he told me that we could plot some mavlink messages on the remote.
It could be very nice for:

• GPS location (after crash)
• remaining battery (before crash....)

some preliminar info are there: http://diydrones.com/forum/topics/mavlink-data-displayed-on-opentx-9x-9xr-etc-radio-screen

#103 #104, made me realize we could use callbacks in other places (callback to new sensor value mainly).

There are limitations in the current implementations though:

• The callback function is called directly, and by-passes the scheduler.
  • We have to be careful not to register long functions as callback functions, or tasks will be delayed.
  • Even with short callback functions, we should not register too many for the same event, because they will be called at the same time.
  • There is even a risk of infinite loop if a callback function calls another callback function that ends-up calling the first callback function... no stabilisation = BOOM ;-)
• We need one implementation per type of event (mavlink message / mavlink command / remote event)

So why not adding an Event / Callback mechanism to the scheduler ?
A callback function would be a task. A task could be registered for a specific event.
When this event occurs, the next execution time of the task set to now. Then it is up to the scheduler to decide whether or not to run the task now, or to let the priority to another task.
We could even specify a special priority level for callback, for example higher than for normal periodical calls.

What do you think ?

Hello,

i am almost done with the conf files removed from the Library : #24

I was looking at the dependencies of files from the project folder on the Library.
What shall we do ?

• for task dependency

Some modifications were made but not finished and not correct.
We shall decide whether we go for variable in the init and then a structure in .h (not an ugly variable in .c) or we go for macro #define in conf.
Now it's a mix of both and due to that, it's codded wrongly!
I need a reply from you @jlecoeur, @ndousse and @GregoireH !

In navigation, the member state is not const, and the mav mode is set to ARMED_OFF in case of a critical landing. Also state->in_the_air seems to be used as a kind of global variable to avoid circular includes between navigation and waypoint_handler.

@lis-epfl/mavric-lis

When an upgrade in the Library requires changes in the project, we usually list the changes by commenting the pull request.

The problem is it is difficult and borring to guess which of the closed pull requests broke your project.

It would be nice to embed the info direclty in the commits, possibly with an explicit flag in the beginning (like [BAZINGAA] My commit message ).
By simply looking up the latest commits, you could spot which one requires changes.

Hi guys,

I noticed very weird calls to print_util_putnum in gps_ublox.c
(see here https://github.com/lis-epfl/MAVRIC_Library/blob/master/hal/avr32/gps_ublox.c#L1302 )
This is strange because print_util_putnum tries to translate numbers in human readable format, does the GPS expect to receive a series of ASCII characters for each number?

Hopefully, I checked and all the values sent to the autopilot are not significatively converted by the function before being sent (ie all 16bits numbers where between 0 and 9!).
Even stranger, and this is where I start to wonder how it has ever worked, print_util_putnum prefixes positive numbers with a space (to align them with negative number on a console output)
( see https://github.com/lis-epfl/MAVRIC_Library/blob/master/util/print_util.c#L183 )
It means that the GPS receives all expected values, but separated by a ' ' character (decimal 32).
In any case, even if the GPS requires data to be sent in ASCII and separated by spaces, I think this is a bad idea to rely on the way numbers are formatted for console output.

I am really wondering if the GPS expects all this? I cannot test here because I do not have a GPS at hand. Can anyone try to compile the branch dev_cpp and plug a GPS in? I replaced the calls to put_num by direct calls to uart.
(see https://github.com/lis-epfl/MAVRIC_Library/blob/dev_cpp/drivers/gps_ublox.cpp#L1249 )

It happens already in the 14channels branch

I propose an easy and clean way to register simple callbacks which are triggered as a remote control button is switched.
IT can be used as follows:
remote_callback_register(remote, my_cb_function, my_structure, remote_channel);
As the value of remote_channel changes, the function my_cb_function(my_structure, new_value); is called.

This allows to register callback without modifying the MAVRIC_Library. Furthermore, it is structured and clean. Furthermore, is "synchronized" with remote_update function, which avoids polling to often or not often enough

We only build the test project using gcc (linux project). We could add two additional travis targets for avr32 and stm32 projects. To do this the compilers have to be downloaded (we already download a newer version of gcc), before compiling.

Hello,

you should be aware that the update of Mavlink message, thanks to @jlecoeur will have an impact on your project.
Do remember to change the compilation tool to use mavric instead of maveric,
And for windows users, don't forget to also add common folder to the cproj file if you want to be able to search for those files.

Blame @jlecoeur ??? :-)

All the Best

IMU calibration files need to be updated to fit the new code on branch dev_cpp (see pull request #85)

The calibration files are stored in this folder https://github.com/lis-epfl/MAVRIC/tree/dev_cpp/LEQuad/src/config/MAVcalib (watch out, this is on branch dev_cpp).

The first one (MAV001) is done in commit lis-epfl/MAVRIC@f1505b2, but all the others need to be done. The original config is left commented at the end of the file.

All what is needed is to copy/paste the content of MAV001 in the other calibration files, and to set the biases to the correct value (= old_bias_value / scale ).

related to pull request #95

To be considered

Several modules lack of debug print message at the end of their init function.

Filling this gap would allow better debugging when a module fails its initialization

The formula used now in the module pid_controller is:

out = clip_min_max ( Kp * ( error 
                           + Ki_post * clip_i( accumulator + Ki_pre * error * dt )
                           + clip_d( Kd * (error - previous_error) * dt ) 
                           )
                   )

This has four main issues:

• when the P gain is changed, I and D gains are affected
• when the P gain is changed, the accumulator does not fit the system anymore. Example with the students of mobile robots working on altitude stabilization, some groups had Kp * Ki_post * accumulator = -0.3 for hover, but when Kp was set lower for less aggressive control, the quad would just skyrocket for a few minutes until the accumulator discharge...
• in the integral part, one of the three parameters is redundant (Ki_post, Ki_pre, clip_i),
• in the integral part, it would be useful to limit the charging rate of the accumulator.

What I propose:

out = clip_min_max ( clip_p( Kp * error) 
                   + clip_i( accumulator + clip_i_pre( Ki * error * dt ) )
                   + clip_d( Kd * (error - previous_error) * dt )
                 )

the parameters would be:

• clip_min, clip_max: extreme values for the output
• K_p : proportional gain
• clip_p : saturation value (symetric +/-) for proportional term
• K_d : derivative gain
• clip_d : saturation value (sym. +/-) for derivative term
• K_i : integrator gain
• clip_i : saturation value (sym. +/-) for integral term
• clip_i_pre : maximum charging rate for the accumulator (sym. +/-)

Let me know what you think @lis-epfl/mavric-lis , once we agree on something, I can do the changes.

Data_logging uses the function snprintf to concatenate strings. Functions of stdio.h are very big and we managed to avoid them most of the time.

When I try to remove the 4 snprintf calls, the space occupied by the program is reduced by 10% !

I propose to implement a short function to concatenate the file names in data_logging, and remove #include <stdio.h>

Any volunteer ?
That is an "easy-fix", why not @kornat 👍 !

Our message definition file mavric.xml should be cleaned.

Only few messages are used (and are redundant with new messages in common.xml):

• ROLL_PITCH_YAW_SPEED_THRUST_SETPOINT
• ROLL_PITCH_YAW_THRUST_SETPOINT
• ROLL_PITCH_YAW_SPEED_THRUST_SETPOINT

Some seem related to myCopter, but are unused:

• SET_QUAD_SWARM_ROLL_PITCH_YAW_THRUST
• SET_QUAD_SWARM_LED_ROLL_PITCH_YAW_THRUST

The ones about radar are unused but we can keep:

• RADAR_TRACKED_TARGET
• RADAR_VELOCITY_HIST
• RADAR_RAW_DATA

The others... I don't know

I suggest to add the relative to header files into the include directive (e.g. #include libs/.../.../...hpp)

This has the following advantages:

• Adding headers does not require modifying the Makefile -> less project changes & less dependency between MAVRIC and MAVRIC_Library versions
• Remove risk of ambiguities with header names

What do you think?

Since we take the min of the frequencies of to neighbouring servo frequencies, an odd number of servos will result in a undefined frequency. Furthermore, only creating MAX_SERVO_COUNT/2 frequencies means that one frequency is missing if the number of servos is odd.
Fix for this is coming up.

Furthermore, we iterate for(i=0; i < MAX_SERVO_COUNT; i++) => we use servos that have not been initialized. I think we should only iterate up to servos->servos_count or initialize even unused servos to zero to avoid undefined behaviour.

Students made significant work on the autopilot this semester. Namely @dtsbourg worked on throw recovery #153 and @Spyroth on adapting the code to fixed wing.

The issue is that our branches now look like this:

----o--master
    |------o-----v1.5.0
    |------o-----o------o-----o------o-----o-----throw_recovery
    |------o-----o------o-----o------o-----o-----quad_to_wing
    |------o-----o-----(...far far away...)------o-----o-----o-----dev_cpp
                                                 |-----o-----o----fat_fs_data_logging_cpp
                                                 |-----o-----o----cpp_navigation_internal_state

• the last commit on master was 27Oct,
• we have release 1.5.0 with one commit backported from dev_cpp (to speed up telemetry)
• cpp port (cross platform hal #85) is 295 commits ahead of master and still in test

So the question is when and where do we merge this work.

edit: @GregoireH here is a notification for you

Hello

Aren't we missing an acknowledge in the waypoint message handler, to tell QGroundControl that the autopilot received it properly.
It seams confusing that it always time out when you send waypoints to the autopilot.

Hi @mdouglas90,

The branch master is currently giving some warnings.
Could you please have a look at your code in data_logging.c to remove those?

I've already created a branch called dataLoggingWarningFix and fixed already two warnings with missing prototypes.

Hello,

I just added a note on how to log from an SD card or from QGroundControl software.
If someone wants to review it and/or add some pictures to illustrate and make it even more appealing it would be great.
Otherwise you can point your students to look at it !!

Best

Dear @lis-epfl/mavric-lis,
I am currently looking into proposing to Dario to create a webpage for MAV'RIC framework. I need your advice on the name of the domain. This is a few available domain:

• mavric.org
• mav-ric.org
• mavric-autopilot.org

Let me know your opinion and other ideas!

Dear MAV'RIC,

Please note that the RX and TX of the GPS plug is inverted...

Therefore, even if you have the fix blue LED flashing on the GPS, it doesn't mean that your position is corrected by the GPS.

You should check wheter your position is corrected after you have a fix. If this is not the case, the yellow and green cable of the GPS should be inverted.

On GitHub, the tabulations are completely messed up:

even if in the original file, it is perfectly aligned:

A potential solution would be to replace the tabs by a given number of spaces (e.g. 3).
QGroundControl uses this formatting and the visualization on GitHub works fine.

What do you think @lis-epfl/mavric-lis ?

Hi,
In order to make the Library more modular, the modules should be separated from mavlink. We should be able to use any kind of communication protocol.

I propose a new structure for each module. I implemented it on the remote.c and servos.c modules.

The question remains where do we declare the memory for these structure?

• either in central-data, but basically, it increases the number of structure
• or in mavlink_telemetry, where we define a mavlink_telemetry_t with pointers to these new structure, the only issue being that each time you add a new module, you should add it this structure.

What do you think?
@jlecoeur

In stabilisation_copter.c and simulation.c, the project-specific file conf_platform.h is required to assign each motor a direction and a servo pin. The issue is that the library does not compile by itself.

This has been marked as TODO for a year (since Oct2014). What do we do with this @ndousse ?

Potential solution are the modules servo_mix*, which I used on LEQuad and Ywing, but that never made it to stabilisation copter.

@lis-epfl/mavric-lis
It is possible to build avr32-gcc from source (also for MAC OS)

I had issue with an update of glibc on my machine, the pre-compiled avr32-gcc was not working anymore.

I found the solution with this repository:
https://github.com/denravonska/avr32-toolchain

Happy to hear if someone can have it work on MAC OS :-)

Hello,

When you set a mission and fly for a while in waypoint navigation, everything is find.
But if you land and try to redo the experiments it will actually follow the mission where it ended.
Meaning that it may try to go to the last waypoint of your mission directly and remain there instead of reseting the mission and starting again.

I am not sure whether this reset mission shall be done each time you quite waypoint nav for another mode. As if something goes strange you may want to hover for a while to check what is going on, and then follow the mission. But maybe if you switch back to stabilize mode you should reset the mission.

Looking forward hearing from you before working on its implementation,
Best

It seems that only channels 0-6 of mavric are correctly connected to the remote control.
In both remote.channels and remote.sat.channels, only channels 0-6 can be controlled with the remote control (TURNIGY 9XR Pro). The remaining channels remain at 0.

Could this be due to a bug in spektrum_satellite.c:
https://github.com/lis-epfl/MAVRIC_Library/blob/master/hal/avr32/spektrum_satellite.c#L146

or does the problem lie at the remote control side?

See my comment on #23

Bug present in the src folder.
The simulation biaises are set to the hardcoded value of the imu structure when simulation_init calls simulation_calib_set.

for (i = 0;i < 3;i++)
    {
        //we take in sim the inverse of the imu scale_factor to limit number of division
        //while feeding raw_sensor.data[i]
        sim->calib_gyro.scale_factor[i]         = 1.0f/sim->imu->calib_gyro.scale_factor[i];
        sim->calib_accelero.scale_factor[i]     = 1.0f/sim->imu->calib_accelero.scale_factor[i];
        sim->calib_compass.scale_factor[i]      = 1.0f/sim->imu->calib_compass.scale_factor[i];

        sim->calib_gyro.bias[i]                 = sim->imu->calib_gyro.bias[i];
        sim->calib_accelero.bias[i]             = sim->imu->calib_accelero.bias[i];
        sim->calib_compass.bias[i]              = sim->imu->calib_compass.bias[i];

        sim->calib_gyro.orientation[i]          = sim->imu->calib_gyro.orientation[i];
        sim->calib_accelero.orientation[i]      = sim->imu->calib_accelero.orientation[i];
        sim->calib_compass.orientation[i]       = sim->imu->calib_compass.orientation[i];
    }

but when we read the values from flash in main.cpp, we overwrite the value of the imu structure with what is present in flash. Therefore the two structure are not consistent.

One big milestone for MAVRIC will be the moment the hal will be truly platform independent (ie able to run on avr32, linux and stm32).

Proposed folder organization

First I think we should separate the chip drivers, which are not platform specific, from the peripheral drivers, which is the real hal.

+
├── hal
│   ├── common
│   │   ├── [...]
│   │   ├── High level peripheral interface (.h files), ex: uart.h, spi.h...
│   │   └── Common features based on lower level peripherals (.h and .c files), ex: SD over SPI
│   ├── avr32
│   │   ├── [...]
│   │   └──Low level peripheral implementation for avr32 (.h and .c files)
│   ├── stm32
│   │   ├── [...]
│   │   └──Low level peripheral implementation for stm32 (.h and .c files)
│   └── linux
│       ├── [...]
│       └── Low level peripheral implementation for linux (.h and .c files)
└──drivers
   ├── [...]
   ├── Chip drivers, using the hal interfaces from hal/common (.h and .c files)
   └── example: bmp085.c uses hal/common/i2c.h (but not hal/avr32/i2c.h)

Then I see two possibilities to link the low-level and high level peripheral files

First solution

Using function pointers.
A high level interface is created in boardsupport.h, and initialized using a low-level function in boardsupport.c

High level

hal/common/uart.h:

typedef uart_t
{
   uint8_t (*write)(uint8_t);
   uint8_t (*read)(uint8_t);
}

Low level

hal/avr32/avr32_uart.c:

avr32_uart_init(uart_t* uart, avr32_uart_conf_t config)
{
    // interface functions
    uart->write = &avr32_uart_write;
    uart->read = &avr32_uart_write;
}

Second solution

Depending on the files which are compiled, a low level implementation is chosen

High level

hal/common/uart.c:

uint8_t uart_write(uint8_t byte)
{
    lld_uart_write(byte);   // lld for low level driver
}

uint8_t uart_read(uint8_t byte)
{
    lld_uart_read(byte);   // lld for low level driver
}

Low level

hal/avr32/lld_uart.c:

uint8_t lld_uart_write(uint8_t byte)
{
    avr32_uart_write(byte);
}

uint8_t lld_uart_read(uint8_t byte)
{
    avr32_uart_read(byte);
}

The first one seems easier to handle. The good point is that you do not need to add code in the LIbrary to add a new uart, just instantiate and initialize a new object in the project folder. However, we have to ensure that all pointers are initialized by the low level drivers. The compiler cannot help here, if a feature is not implemented on a specific hardware, then it is possible to have a NULL pointer for the corresponding function.

The second solution is safer in the sense that it will not compile if the low level driver does not implement one of the functions. However by looking at the code, it is impossible to tell which function is called: there will be several implementations with the same function name. Also, it needs a way to choose the uart: either separate function (uart1_read(), uart2_read(), ...), or a parameter uart_read(uint8_t uart_id, uint8_t byte), in both case more code is needed for more peripheral.

Peripheral initialization

In both cases, it is not clear where to put the initialization.

• in the high level files
  • clean and common interface
  • more work
• in the low level drivers
  • faster
  • easier to extend
  • messier

@lis-epfl/mavric-lis What do you think?

Dear @GregoireH and @jlecoeur,

I implemented the Sonar in the complementary filter today. (in mixForExperiments branch, together with all pull request done lately).

Here are some results and reflexion:

Actually, the vertical velocity given by the GPS is not so bad! In opposite, the barometer has quite some delay compared to the sonar. I already reduced the LPF gain of the velocity to reduce the delay.
Proposition: reduce the gain of the barometer and increase the gain of the velocity.

In position_estimation_correction, we interpolate the consecutive position from the GPS to estimate the velocity. Following this result, we see that it gives worst result than the velocity given directly by the GPS
Proposition: we use directly the velocity from the GPS in the position estimation

For the position, the baro and sonar are better than the GPS

We are currently limited to 7 channels for spektrum satellites. Implementing the DSMX protocol should fix this

QGC introduced (silently) a way to avoid sending all parameters in the beginning.
The idea is to compute a hash over all parameter names and their values and to send it to QGC.
(QGC actually sends a request for the onboard parameter _HASH_CHECK).
If the _HASH_CHECK reveals no changes for the onboard parameters, they do not have to be sent and the parameters of the last session are loaded in QGC.

Here's the pull request of QGC: mavlink/qgroundcontrol#1965
Here's some thing from ardupilot: ArduPilot/ardupilot#3070
And here for PX4/Firmware: PX4/PX4-Autopilot#2982

Note: This is not required, it would just save some communication in the beginning

As it was discussed in pull request #89
Sometimes, logging takes way too much computational time.
Which leads to some hudge delay in the stabilization loop !! (140ms delay compare to a period of this task of 4ms => we miss 35 stabilization loops...)

We should spend sometime spoting the issue and improving this.
Otherwise we will have to go back to something like writing bytes on the SD card, which is not that user friendly compare to having a Fat fs system file manager.

Best