Using the CONFIG.INI feature

[GliderUAV]

Hi all,

The recent trunk versions of Matrixpilot support reading on-board parameters from Flash memory at startup.

I'm using an android smartphone with an OTG cable to change settings in the CONFIG.INI file on an AUAV3 in bootloader mode. The latest trunk version supports this, after enabling filesys_init() in main.c.

At home i can use mavlink (tricky in this version) and view the onboard parameters in Qgroundcontrol. The values in the CONFIG.INI overrule the ones in options.h.

For example:

[ALTITUDE]
throt_max = 0.71
desired_speed = 11.31

  
This config file allows me to change settings in the field, between flights. I use a simpler, one way, and a more battery friendly telemetry type for my flights at the moment, not mavlink.

There is a catch, however: not more than 5 lines, about 170 bytes can be read at most. Making CONFIG.INI bigger will cause a reset. What could be causing this? Are interrupts being handled wrong? Any help would be more than welcome.

All the best,

Kees

[Robert Dickenson]

Hi Kees,

I'm the author of that work and would be happy to offer limited help to in you in taking it further. Sorry I never tested beyond my single bench test configuration, and so was not aware of the issue you are seeing. Please find below quoted what I believe I was using in my ini file, which is clearly way beyond only five lines.

For the moment, and hopefully long term, I have a serious commitment with another project, so will be very limited in what support I can offer here - however I am very pleased to see you running with the new feature, and encourage you to investigate it further.

BTW: there is also support for adding an SD-Socket/Card on the external SPI bus, thus extending the file system capacity enourmously. This is what I was using in most all of my final development work - hence I suspect the problem may lay with the flash I/O driver. The primary advantage to using an SD memory is that my work also included a vision for MP to support integrated flight log recording.

Using the parameter loading support is at least quite safe, as it all happens on bootup and then the filesystem is essentially dormant during flight. However any attempts to use the flight log recording is frought with danger, as the complexity and immaturity of the file system support has certain implications for in-flight autopilot stability. Note, I also did a far amount of work towards having MP better able to cope with potential reboots, but that is even less well developed. All opportunities for future improvement (-;

Best wishes, Robert.

config.ini:

[NETWORK]
address = 192.168.1.34
gateway = 192.168.1.1
subnet = 255.255.255.0
port = 5050
dhcp = 0

uart1 = 0
uart2 = 0
flybywire = 0
mavlink = 0
debug = 0
adsb = 0
logo = 0
cam_tracking = 0
gpstest = 0
pwmreport = 0
xplane = 0
telemetry_extra = 0
round_station = 0

[AIRFRAME]
type = standard
orientation = forwards
#comment=3
String = mies

[STABILISE]
pitch = 1
roll_ail = 1
roll_rud = 0
yaw_ail = 1
yaw_rud = 1

[NAVIGATION]
ail = 1
rud = 1
wind = 0

[INPUT]
ppm = 1
invert = 0
channels = 8
inputs = 5

throttle = 3
aileron = 1
elevator = 2
rudder = 4
mode = 5
cam_pitch = 0
cam_yaw = 0
cam_mode = 0
osd_mode = 0
pass_a = 0
pass_b = 0
pass_c = 0
pass_d = 0

[OUTPUT]
outputs = 4
throttle = 3
aileron = 1
elevator = 2
rudder = 4
aileron2 = 0
cam_pitch = 0
cam_yaw = 0
trigger = 0
pass_a = 0
pass_b = 0
pass_c = 0
pass_d = 0

[REVERSE]
throttle = 0
aileron = 0
elevator = 0
rudder = 0
aileron2 = 0
cam_pitch = 0
cam_yaw = 0
elevon = 0

[MODE]
low = 2600
high = 3400
two_pos = 1

[FAILSAFE]
channel = 3
min = 2020
max = 4040
type = RTL
hold = 0

[MAVLINK]
sysid = 55
name = "Not Defined"
rego = "Not Defined"
pilot = "Not Defined"
url = "http://www.diydrones.com"

[ANALOG]
inputs = 3
amps =
volts
rssi =
min = 0.5
max = 3.3

[TRIGGER]
# none, servo, digital
type = none
# high, low, toggle, repeat
action = high

[ROLL]
rollkp = 0.20
rollkd = 0.05
yawkp = 0.10
yawkd = 0.05
boost = 1.00

[PITCH]
gain = 0.10
pitchkd = 0.04
rudder = 0.20
roll = 0.05
boost = 0.50
invert = 8.0

[YAW]
yawkp = 0.05
yawkd = 0.05
rollkp = 0.06
rollkd = 0.05
mix = 0.00
boost = 1.00

[HOVER]
rollkp = 0.05
rollkd = 0.05
gain = 0.2
pitchkd = 0.25
pitch = 0.0
yawkp = 0.20
yawkd = 0.25
yaw = 0.0
wp = 30.0
radius = 20

[ALTITUDE]
# NONE = 0, FULL = 1, PITCH = 2
stabilised = 1
# NONE = 0, FULL = 1, PITCH = 2
waypoint = 1
height_min = 25.0
height_max = 100.0
margin = 10
throt_min = 0.35
throt_max = 1.0
pitch_min = -15.0
pitch_max = 15.0
pitch_high = -15.0

[RTL]
pitch = 0.0

[DEBUG]
stack = 0

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GliderUAV]

Hi Robert,

Thanks for your reply.

I like those hidden treasures in MP!

I've already started experimenting with uSd card support, but only on a UDB5. I did not realize the support was also for the AUAV3. I intend to solder a uSD to SD adapter as a quick alternative to a uSD breakout board. It would be cool if I could still edit files on that card with my smartphone, as if it where on the Auav3 flashmemory.

Cheers,

Kees

Op zondag 13 maart 2016 11:31:13 UTC+1 schreef Ansuz:

[GliderUAV]

Robert,

I hooked up a uSD to a Auav3 board:
   - connections:
  AUAV3      uSD
  
  SDI3      DO
  GND       VSS
  SCK3      SCK
  ICSP-p2 3.3v VDD
  SDO3      DI
  SS3       CS
 - I tried a 2Gb FAT and a 32Gb FAT32 formatted uSD card
 - I copied a config.ini file to it
 - I renamed the config.ini file on the onboard Flash to config_.ini
 - onboard paramaters did not change, so the file is not read from uSD.

 How should I tell the board to use the uSD, not the onboard flash?
 - should i #define USE_SD_INTERFACE_WITH_SPI in FSconfig.ini (this results in compilation errors) ?

Best wishes, Kees

Op zondag 13 maart 2016 20:53:26 UTC+1 schreef GliderUAV:

[Robert Dickenson]

Hi Kees, yes, 'USE_SD_INTERFACE_WITH_SPI' sounds about right. If you cannot sought out the compilation failure in rather short order, let me know and i'll endeavour to take a look. Can't do so right now as i'm on a machine which does not have the required build tools available.

Best wishes, Robert.

On 18 March 2016 at 00:18, GliderUAV <kees....@upcmail.nl> wrote:

Op zaterdag 12 maart 2016 09:04:26 UTC+1 schreef GliderUAV:

--

[GliderUAV]

Hi Robert,

The only way i can see to enable SD via SPI is to change  Microchip\HardwarePofile.h :

from:
#ifdef AUAV3
#define USE_AT45D_FLASH
//#define USE_SD_INTERFACE_WITH_SPI

to:
#ifdef AUAV3
//#define USE_AT45D_FLASH
#define USE_SD_INTERFACE_WITH_SPI

this results in:
..\Microchip\MDD-File-System\SD-SPI.c: In function 'MDD_SDSPI_InitIO':
..\Microchip\MDD-File-System\SD-SPI.c:439: error: 'SD_CD_TRIS' undeclared (first use in this function)
..\Microchip\MDD-File-System\SD-SPI.c:439: error: (Each undeclared identifier is reported only once
..\Microchip\MDD-File-System\SD-SPI.c:439: error: for each function it appears in.)
..\Microchip\MDD-File-System\SD-SPI.c:442: error: 'SD_WE_TRIS' undeclared (first use in this function)
..\Microchip\MDD-File-System\SD-SPI.c:445: error: 'SD_CS_ANSEL' undeclared (first use in this function)

same result for UDB5, with this setting:
#ifdef AUAV3
..
#else
//#define USE_EEPROM_FLASH
#define USE_SD_INTERFACE_WITH_SPI

..\Microchip\MDD-File-System\SD-SPI.c: In function 'MDD_SDSPI_InitIO':
..\Microchip\MDD-File-System\SD-SPI.c:442: error: 'SD_WE_TRIS' undeclared (first use in this function)
..\Microchip\MDD-File-System\SD-SPI.c:442: error: (Each undeclared identifier is reported only once
..\Microchip\MDD-File-System\SD-SPI.c:442: error: for each function it appears in.)

i can't find the cause of this, will you have a look? 

i use the latest version of trunk (SVN reports revision 2537)

Thanks,

Kees

Op donderdag 17 maart 2016 17:43:42 UTC+1 schreef Ansuz:

[GliderUAV]

Hi all,

Because the config.ini feature does work with onboard flash, and can be accessed by smartphone, i decided to go back and look at that again. The only issue is the size limit. I noticed the AT45D and the mpu6000 share SPI1. So i modified the code to read the config file first, and only then run MPU6000_init16(&heartbeat);. That worked, all lines were read.

The problem now is the speed; it takes about 60 seconds to read a full config.ini file, like the one Robert posted here before. In flight, a reboot would spell disaster... I noticed the code looks up specific values in flashmemory one at a time, opening, seeking and reading the file about 50 times. 

Any tips on improving the speed? I'm considering writing code to read and process the file one item at a time, so the file will only be read once.

Thanks,

Kees

Op vrijdag 18 maart 2016 20:44:22 UTC+1 schreef GliderUAV:

[Robert Dickenson]

Those defines are mostly commented out further down in HardwareProfile.h

I did most of my work with the SD-Card support on a UDB4 board, with the SD-Socket connected via several soldered on kynar wires. You'll need to configure these defines to suit which pins you're using for the card-detect and card-select lines. This will probably require a little development work.

Those access times are concerning. I had no such issues during my work with the SD support. I'd start by trying various SD-cards - they are certainly not all created equal.

In terms of in-flight resets, there is also some very alpha code present to better handle such situations. One thing to look into is the setjmp/longjmp implementation, as well the the exception handlers and what they do.

Some years ago Andrius reported a serious issue with in flight reboot handling, which was the aileron waggles. Despite the UDB restarting fast enough and just fine, those waggles caused the airframe to wobble so violently that the battery was shaken loose, which then led to new problems...

[GliderUAV]

Robert,

Thanks, that helped me along.

- First the good news;  i got the SD card working on the UDB5 board. It read the fullsize config.ini file in about 5 sec (2Gb FAT16 card)
- after reading your description i understand you soldered the wires to the PIC-chip pins directly? Nice! I used the standard board connections instead (already occupied on yours?).
- what registers/pins should i define for Auav3?

- CD (card detect) and WE (write protect/enable) are not used?
- what are your thoughts on the AT45D (Auav3 onboard flash) hardware? Too slow, only to be used for bootloading, not for config.ini?
  And if an SD card is connected to an Auav3, could that be used for bootloading as well as config.ini? I really like accessing the file using the usb port, is that possible?
  (i don't want to drop my uSd card in the grass when it's cold...). This could speedup bootloading, too.
  I noticed minini.c has the ini_browse() function, do you think this could be used to speed up the reading?  There might be conflicts with the MPU6000, that needs attention.
- about rebooting, i assume the config will be read then too, so should not take more than one second. Or, reading should be timesliced,
allowing IMU and servohandling to start right away.
- i'm planning to code to use the config.ini for a "four servo wing" mixer, for that i'll be needing an even bigger ini file.
- the atached patchfile shows the changes i made to connect SD cards to the standard SPI connectors for both the UDB5 and the AUAV3 boards.
 

Hope you can help me to get SD working on Auav3 as well.

All the best,

Kees

Op donderdag 31 maart 2016 02:59:12 UTC+2 schreef Ansuz:

[Robert Dickenson]

I think I soldered the SD-Socket via kynar wires directly to the board simply because I had an iron on hard, and didn't care to try joining kynar wires into pin headers.

The only time I worked with an SD-Card on the AUAV3, I had a commercial socket which I connected to the SPI-3 bus. I never connected card-detect or write-protect, so in the code I must have had these hardcoded to return appropriate values at all times. Looking at my old UDB4 board with a few broken wires, it looks like I ended up with these lines disconnected also. If you wish to use them, simply choose some otherwise unused inputs and configure correctly. I don't know that uSD cards actually support write protect, and card detect is a little redundant as you can assume if the card will not initialise, it's either not present or broken, same result either way.

The AT45D was designed into the AUAV3 as an alternative option for the EEPROM which is featured on the UDB4/5 boards. We never realised replacement library algorithms to make it behave like the E2, mostly because it doesn't support individual byte erase operations. I therefore moved to a filesystem based approach with a vision to ultimately being able to read/write configuration files to it via MAVLink-FTP. Then it became useful as a bootloader mechanism with with you seem familiar. So long as configuration files plus a HEX image can fit on the device at the same time, it should be able to support both features concurrently. Although only a tiny filesystem by comparison with what the SD-Cards provide, it should always be big enough for this. The downside at the time was that it was never going to support much in terms of logfile capacity.

The filesystem library I used does not readily support multiple mass-storage devices, so if the SD-Card option is selected, then that's where the configuration (ini) files must go as well. Then the AT45D is solely used for the bootloader feature. The bootloader could of couse be modified to use the external SD-Card, however there doesn't seem to be much point in going there.

I never looked at the ini_browse function. I did on several occasions think that the entire use of .ini files was a tad 'yesterday', however of all the alternatives I investigated, none seemed as simple to adopt as the .ini support library we have now. And keeping in mind it was only intended for loading parameters at startup, or explicitly writing them when commanded via QGC, whatever its performance was seemed adequate. It would be prudent to adopt a means to avoid reloading parameters in the event of an inflight reboot. I believe the variables are already linked into a section so as not to be zeroed out by the standard C startup code, so they should be persistent across a restart.

Once you have a working SD-Card connection configuration worked out and tested, please submit your work as a pull request. I'd be great to have these features made more mature for any future users.

On the UDB4 (which I mostly used during SD-Card support development) the SPI busses are by default unused. On the UDB5 I recommend the SPI2 bus should always remain reserved for the MPU6000 only. SPI1 bus was optionally used for the On Screen Display (OSD) system, however there seems to be better ways to achieve that functionality these days. Therefore I would suggest selecting SPI1 for use with the SD-Card. The AUAV3 has a third SPI bus available, which I what I used with that board.

Thanks and regards, Robert.

[GliderUAV]

Hi Robert,

Thanks for your answer.

Made some progress, reading from SD card on the Auav3 is working.

The only changes, apart from selecting 'USE_SD_INTERFACE_WITH_SPI' is to comment out a few things in SD-SPI.c:

void MDD_SDSPI_InitIO (void)
{
//    SD_CD_TRIS = INPUT;            //Card Detect - input
    SD_CS = 1;                     //Initialize Chip Select line
    SD_CS_TRIS = OUTPUT;           //Card Select - output
//    SD_WE_TRIS = INPUT;            //Write Protect - input

//#if defined (__dsPIC33E__) || defined (__PIC24E__)
#if defined (__PIC24E__)

Both UDB5 (SPI1) and Auav3 (SPI3) will compile and work with this change. (See pictures)

Sadly, the issue with the filesize remains the same, about 250 bytes max size for a config.ini file. I tried two uSd cards (1Gb Fat16 and 2Gb Fat16), with the same results. Couldn't get FAT32 cards to work,   

The UDB5 board can read a fullsize ini file. I could look at how it handles reboots. if I had a method to trigger some sort of warm restart.

Regards,

Kees.

Op zaterdag 2 april 2016 05:02:50 UTC+2 schreef Ansuz:

[Robert Dickenson]

I have previously used the console command 'crash' which uses recursion to invoke a stack overflow exception, and then somewhere in the exception handling code, you should find a warm restart being performed.

Your diagrams are very neat - it would be nice to see them linked to in the draft wiki pages on the SD-Card option.

Thanks and regards, Robert.

[GliderUAV]

Hi Robert,

Glad you like my diagrams, use them as you see fit. The wiki has some words missing btw.

- configured the console
- copied mavlink\libFlashFS\config,ini to 2GB FAT16 SD card
- changed altit.AltHoldThrottleMax = 0.456700
- added a DPRINT for this value in config.c
- board was rebooting  repeatedly
- applied my fix for reading ini file before MPU6000_init16..
- performed a hard reset
- after a few seconds:
MatrixPilot 20:20:23 Apr  6 2016 @ 16 mips
filesys_init()
File system initalised
- after 25 sec after the hard reset:
altit.AltHoldThrottleMax = 0.456700
- after 41 sec after the hard reset:
turns.FeedForward = 0.800000
- after 51 sec after the hard reset:
init_states()
startS()
calib_finished

typed crash <enter>

- after 51 sec after the warm reset:
MatrixPilot 20:20:23 Apr  6 2016 @ 16 mips
S/W Reset: trap_flags 0008, trap_source 00012f84, osc_fail_count 0
filesys_init()
File system initalised
altit.AltHoldThrottleMax = 0.456700
turns.FeedForward = 0.800000
init_states()
startS()
calib_finished
init_finishedS
ent_calibrateS

- note the S?W Reset is neatly reported 

So, as it stands now, i don't plan to use this. 

All the best,

Kees

Op zondag 3 april 2016 02:31:24 UTC+2 schreef Ansuz:

[Robert Dickenson]

have you tried various sd-cards? - i wonder if the type of card you have my not be a very 'high performer' in single bit mode

[GliderUAV]

Hi Robert,

Here are some boot times with different uSD cards using the same setup (UDB5):

-2 Gb  Sandisk    60 sec
-2 Gb  MicroSd taiwan   57 sec
-1 GB  Sandisk          53 sec
-2 Gb  Sandisk    57 sec

all are FAT16, FAT32 will not read:

MatrixPilot 16:15:05 Apr  7 2016 @ 16 mips
filesys_init()
fs_init() return zero
filesys_format
File system initialisation failed

turns.FeedForward = 0.800000
init_states()
startS()
calib_finished

Cheers,

Kees

Op woensdag 6 april 2016 23:57:50 UTC+2 schreef Ansuz: