air - User contributions [en]

Proj-2013-2014-Python-STM32F4

2016-02-06T15:25:14Z

RICM4-prj14-grp9:

= Introduction =
[[Python_sur_STM32F4]]

= Team =
*Tutors : Olivier Richard
*Members : [[User:Ye XIA|Ye XIA]] , [[User:Xinxiu TAO|Xinxiu TAO]]

= Objectives =

= Software Requirements Specification (SRS) =
The SRS document:
* [[Proj-2013-2014-Python-STM32F4:SRS]]

= Points à traiter =
* Modidification des Makefile
utilisation de arm-none-eabi-g++ et des bonnes options
https://launchpad.net/gcc-arm-embedded

* support STL
Voir https://github.com/andysworkshop/stm32plus
à voir aussi
uSTL http://msharov.github.io/ustl/

* Lib C
Voir newlib et newlib-nano
https://launchpad.net/gcc-arm-embedded

<pre>
from gcc-arm-embedded source
https://launchpadlibrarian.net/160487135/readme.txt

* C Libraries usage *

This toolchain is released with two prebuilt C libraries based on newlib:
one is the standard newlib and the other is newlib-nano for code size.
To distinguish them, we rename the size optimized libraries as:

libc.a --> libc_s.a
libg.a --> libg_s.a

To use newlib-nano, users should provide additional gcc link time option:
--specs=nano.specs

Nano.specs also handles two additional gcc libraries: libstdc++_s.a and
libsupc++_s.a, which are optimized for code size.

For example:
$ arm-none-eabi-gcc src.c --specs=nano.specs $(OTHER_OPTIONS)

This option can also work together with other specs options like
--specs=rdimon.specs

Please be noticed that --specs=nano.specs is a linker option. Be sure
to include in linker option if compiling and linking are separated.

** additional newlib-nano libraries usage

Newlib-nano is different from newlib in addition to the libraries' name.
Formatted input/output of floating-point number are implemented as weak symbol.
If you want to use %f, you have to pull in the symbol by explicitly specifying
"-u" command option.

-u _scanf_float
-u _printf_float

e.g. to output a float, the command line is like:
$ arm-none-eabi-gcc --specs=nano.specs -u _printf_float $(OTHER_LINK_OPTIONS)

For more about the difference and usage, please refer the README.nano in the
source package.
</pre>

* Garbage Collection
Voir tinygc http://tinygc.sourceforge.net/
à voir aussi celui de micropython

* libprce
Voir T-Rex is a minimalistic regular expression http://tiny-rex.sourceforge.net/ http://sourceforge.net/projects/tiny-rex/

= Progress=
project start : 13/01/2014

== Week 1 (13/01 - 19/01) ==
* Project discovery
* Research of related projects

== Week 2 (20/01 - 26/01) ==
* STM32 develop environment

'''Add USB device'''
Create a new udev rule in /etc/udev/rules.d/45-usb-stlink-v2.rules:
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="660", GROUP="plugdev"
To reboot :
$ sudo service udev restart

'''Download the GNU/ARM toolchain'''
Download the Linux current installation tarball from
https://launchpad.net/gcc-arm-embedded/+download
$ tar -xvjf gcc-arm-none-eabi-xxxxxxxxxxxxxxxxxx-linux.tar.bz2
Add the fallowing to your ~/.bashrc
export PATH=$PATH:~/xxxxxxx/gcc-arm-none-eabi-xxxxxxxxx/bin
$ source ~/.bashrc
To check :
$ arm-none-eabi-gcc --version
If you get an error message “bash : ... file does not exist”.
Maybe it is caused by the difference between 32bit and 64bit system. Try :
$ sudo apt-get install ia32-libs*

'''Download and Build STLINK'''
STLINK is for programming and debugging firmware.
you'll first need to install a couple of packages:
$ sudo apt-get install autoconf pkg-config libusb-1.0 git
Retrieve a copy of the STLINK source:
$ git clone https://github.com/texane/stlink.git
Build the code following the instructions in the README, with:
$ ./autogen.sh
$ ./configure
$ make
As a sanity check, look in ~/st-link and you should see st-util, st-flash, etc...
You may check if the board could be connected by execute st-util.
If it does not work please confirm if the rule you added in the first step corresponds your system.

'''Refer to link''' : http://www.wolinlabs.com/blog/linux.stm32.discovery.gcc.html

* Try the official examples of ST on the cards
To avoid using the commercial software IDE and understand better, We decided to develop on Linux for this project.
During the tries, for certain examples, we've got different results on STM32F407 and STM32F401.
We choose STM32F407 as the hardware for the following developement.

== Week 3 (27/01 - 02/02) ==
* Test Project MicroPython
* Test Project Shedskin

* STM32 hardware
[[File:PythonSurSTM32_Hardware_1.png|800px]]

[[File:PythonSurSTM32_Hardware_2.png|800px]]

== Week 4 (02/02 - 09/02) ==
* STM32 breakdown situation & solution

'''Cause Reason'''
After
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;
GPIOC->MODER = 0x04000000;
GPIOC->ODR ^= (1 << 13);
is used (compiled and burned successfully)

'''Status'''
'''1)''' $st-flash write timer_gpio_out.bin 0x8000000
2012-02-09T23:25:54 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:25:54 WARN src/stlink-common.c: unknown chip id! 0
stlink_sram_flash() == -1
make: *** [write] Error 255

'''2)''' hold the Reset button while:
$./st-util
2012-02-25T16:00:42 INFO src/stlink-common.c: Loading device parameters....
2012-02-25T16:00:42 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2012-02-25T16:00:42 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

'''3)''' $st-flash erase
2012-02-09T23:28:01 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:01 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Mass erasing

'''4)''' If I hold the Reset button while erasing:
ahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
2012-02-09T23:28:28 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:28 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-09T23:28:28 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0 bytes (0 KiB) in pages of 256 bytes
Mass erasing

'''5)''' If I hold the Reset button while flashing:
dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
../../flash/flash write lcd.bin 0x08000000
2012-02-10T14:13:21 INFO src/stlink-common.c: Loading device parameters....
2012-02-10T14:13:21 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-10T14:13:21 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2012-02-10T14:13:21 INFO src/stlink-common.c: Attempting to write 7332 (0x1ca4) bytes to stm32 address: 134217728 (0x8000000)
2012-02-10T14:13:21 WARN src/stlink-common.c: pecr.pelock not clear (0x7)
2012-02-10T14:13:21 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
stlink_fwrite_flash() == -1
make: *** [write] Error 255

'''Solution'''
'''1)''' hold the Reset button while:
$ st-util
2013-03-23T15:51:17 INFO src/stlink-common.c: Loading device parameters....
2013-03-23T15:51:17 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2013-03-23T15:51:17 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
Chip ID is 00000410, Core ID is 1ba01477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

'''2)''' Next you will need to launch gdb (in a new terminal) from the tools directory
and make use of the compiled binary that you pulled created earlier during the "make all".
$ tools/arm-2011.03/bin/arm-none-eabi-gdb -q build/fw_coptercontrol/fw_coptercontrol.elf
Reading symbols from
/home/xxx/OpenPilot/build/fw_coptercontrol/fw_coptercontrol.elf...done.
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x0800010c in ?? ()
(gdb) bt
#0 0x0800010c in ?? ()
#1 0xffffffff in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) i r
r0 0x0 0
r1 0xa5a5a5a5 2779096485
r2 0x0 0
r3 0x200002d4 536871636
r4 0x20000cd0 536874192
r5 0xa5a5a5a5 2779096485
r6 0xa5a5a5a5 2779096485
r7 0xa5a5a5a5 2779096485
r8 0xa5a5a5a5 2779096485
r9 0xa5a5a5a5 2779096485
r10 0xa5a5a5a5 2779096485
r11 0xa5a5a5a5 2779096485
r12 0xa5a5a5a5 2779096485
sp 0x20000938 0x20000938
lr 0xffffffff 4294967295
pc 0x800010c 0x800010c
fps 0xaddeadde 2917051870
cpsr 0x1000000 16777216
(gdb) c
Continuing.

Hit CTRL+C to test breakpoints and use l to see line numbers

(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x080039a0 in nmeaProcessGPRMC (GpsData=0xa5a5a5a5, gpsDataUpdated=<value optimized out>, param=0x20000cd0,
nbParam=<value optimized out>) at ../Modules/GPS/NMEA.c:559
559 GpsData->Heading = NMEA_real_to_float(param[8]);
(gdb) l

I quitted the gdb when i found that the board worked again. Again you can easily verify the firmware.

There are some situations solved by erasing or flashing while holding the reset button(black), but it does not work in our issue.

'''Refer to link''' :
http://forums.openpilot.org/topic/20173-regrouping-on-various-stm32f4discovery-swd-debugging-for-oplink-revo-cc3d/

* Test of STM32 printf
Refer to link : http://vedder.se/2012/07/usb-serial-on-stm32f4/

We have tried the program for the STM32F4 Discovery that uses the USB-CDC class to show up as an virtual serial port.
It has routed the write system call to use this port, so the stdio printf function will print directly to this serial port.
After have uploaded the program to the STM32F4 discovery and plug in a micro-USB cable to the port next to the audio jack.
The serial port should show up as /dev/ttyACM0 on most GNU/Linux distributions, such as Ubuntu.
Start a serial port terminal, such as gtkterm (sudo apt-get install gtkterm on Debian/Ubuntu), and open ttyACM0.
As the following shot-screen :
[[File:PythonSurSTM32_printf_shotscreen.png|800px]]

== Week 5 (10/02 - 17/02) ==

* SRS document [[Proj-2013-2014-Python-STM32F4:SRS]]
* build and learn Project STM32Plus

== Week 6-8 (17/02 - 10/03) ==
* The first version of the program
We have finished the first version of the program. In order to trait the text easier, we have made the choice of using TCL script language.
The file structrue of the project is shown as bellow:
[[File:PythonSurSTM_file_struct.png|900px]]
'''py2stm.tcl''' : executable file, the main program of the project;
'''print''' : directory, the library and .o files corresponding to realise printf function;
'''shedskin_lib''' : directory, the modified library of shedskin;
'''defaut''' : necessary files for compiling and executing on STM (link file, the file who realise the functions of low level, etc)

'''Needed Library & Program''' : STM32Plus, Arm-gcc, STLink. These paths are all defined at the beginning of the file '''py2stm.tcl'''.
With the help of this program, from a python source code, we could translate, generate project,
and download the compiled project to the card only with one command.

The program work flow is shown as the following:
[[File:PythonSurSTM_flow_chart.png|400px]]
To support arm-g++ compiling, we have modified the library of shedskin. We have deleted the corresponding code of GC and PCRE.
Instead of using GC, we have included the library of STM32Plus to support the fonctions of malloc, std::string, etc.

The usage of the program is shown bellow:
[[File:PythonSurSTM_usage.png|900px]]

an example:
[[File:PythonSurSTM_compile.png|900px]]
In the make file, we will compile the corresponding files of ShedSkin library, the needed low level functions,
and link the stm32plus library. When we choose Deubg Mode, we will also need to link the STM Common library.

With the option -b, the compiled program for stm will be burned to the card when finishing compile.
[[File:PythonSurSTM_burn.png|900px]]

When there's a error (the python file doesn't exist)
[[File:PythonSurSTM_no_file.png|900px]]

With the option -d, the function printf will be supported in the generated project.
We have defined some low level functions in the file print/syscall.c to support printf, and we have done an redirection of the USB.
The content of the printf will be sent to the USB, so users could use gtkterm to open the port ttyACM0 to have look at it and debug.
The device will be found after the burn as following:
[[File:PythonSurSTM_dev.png|900px]]

With the help of gtkterm ( or other visual tools ), we could choose the port ttyACM0, and see the content of the printf:
[[File:PythonSurSTM_gtkterm.png|900px]]

To support the fonction printf, we have used arm-gcc and arm-g++ in the same time.
The reason is that, most of the examples of STM32 are in C ( STM official examples included ), In this project,
the code translated by shedskin is in CPP, so we have to face up to the difficulty of using arm-gcc and arm-g++.
We have used extern "C" {...} to compile the printf corresponding CPP code.
If not, the linker will not be able the find the reference of the calling of C functions.

For this function, during the executing of the program, we will not copy the source code of the printf to the generated project,
we compile the printf corresponding fonctions only once, the .o files will be in the directory of py2stm/print.
We think these functions are diffrent to the copied low level functions, they are not part of the genereated project,
so we compile only once and we reuse them when linking.

For the reason of the redirection of USB, every time after we download the program to the card,
we could not download normally for another time. In this case, we could run stlink/st-util when
clicking the reset button of the card, then we will be able to download again.
[[File:PythonSurSTM_stlink.png|900px]]

== Week 9-11 (10/03 - 31/03) ==

'''Debug'''
We have fixed some bugs of no-existed head files, not found function definitions.
We have resorved the problem of exception and print in the source files.

'''Evaluation'''

We have tried all the examples in the project Shedskin, we have get the evaluation result:
For 117 files (.py) :
0,1,2,3,4,5,6,7,8,9,10,11,12,13,15,16,18,19,20,21,22,23,24,25,26,28,31,32,33,36,38,40,43,44,45,
46,50,52,53,54,55,56,59,60,64,69,71,75,76,77,78,79,81,82,83,84,86,88,89,93,94,95,97,98,99,100,102,
103,104,105,106,107,108,109,110,111,112,113,114,115,118,119,120,123,124,126,127,129,130,132,133,
134,137,138,139,140,141,142,143,144,146,147,148,152,155,156,157,158,161,162,167,168,170,175,176,183,187
We have finished the compilation.

For 10 fichiers (.py):
122,131,135,150,159,160,163,164,172,173
We could not finish the compilation for the reason of the using of system time.

For 14 files (.py):
29,30,37,125,128,136,151,153,154,165,166,171,190,195
We could not finish the compilation for the reason of the using of iostream of files.

For 13 fichiers (.py):
39,51,177,180,181,182,184,192,193,194,196,198,199
Shedskin could not support their translation.

For 12 files (.py):
169,174,179,185,186,188,189,191,197,200,201,202
We could not finish the compilation for different reasons.

== Week 12 (31/03 - 07/04) ==
Report Writing

[[Media:PythonSurSTM_Rapport.pdf|Report]]

[[Media:PythonSurSTM_Soutenance.pdf|PowerPoint]]

Proj-2013-2014-Python-STM32F4

2016-02-06T15:24:10Z

RICM4-prj14-grp9:

= Introduction =
[[Python_sur_STM32F4]]

= Team =
*Tutors : Olivier Richard
*Members : [[User:Ye XIA|Ye XIA]] , [[User:Xinxiu TAO|Xinxiu TAO]]

= Objectives =

= Software Requirements Specification (SRS) =
The SRS document:
* [[Proj-2013-2014-Python-STM32F4:SRS]]

= Points à traiter =
* Modidification des Makefile
utilisation de arm-none-eabi-g++ et des bonnes options
https://launchpad.net/gcc-arm-embedded

* support STL
Voir https://github.com/andysworkshop/stm32plus
à voir aussi
uSTL http://msharov.github.io/ustl/

* Lib C
Voir newlib et newlib-nano
https://launchpad.net/gcc-arm-embedded

<pre>
from gcc-arm-embedded source
https://launchpadlibrarian.net/160487135/readme.txt

* C Libraries usage *

This toolchain is released with two prebuilt C libraries based on newlib:
one is the standard newlib and the other is newlib-nano for code size.
To distinguish them, we rename the size optimized libraries as:

libc.a --> libc_s.a
libg.a --> libg_s.a

To use newlib-nano, users should provide additional gcc link time option:
--specs=nano.specs

Nano.specs also handles two additional gcc libraries: libstdc++_s.a and
libsupc++_s.a, which are optimized for code size.

For example:
$ arm-none-eabi-gcc src.c --specs=nano.specs $(OTHER_OPTIONS)

This option can also work together with other specs options like
--specs=rdimon.specs

Please be noticed that --specs=nano.specs is a linker option. Be sure
to include in linker option if compiling and linking are separated.

** additional newlib-nano libraries usage

Newlib-nano is different from newlib in addition to the libraries' name.
Formatted input/output of floating-point number are implemented as weak symbol.
If you want to use %f, you have to pull in the symbol by explicitly specifying
"-u" command option.

-u _scanf_float
-u _printf_float

e.g. to output a float, the command line is like:
$ arm-none-eabi-gcc --specs=nano.specs -u _printf_float $(OTHER_LINK_OPTIONS)

For more about the difference and usage, please refer the README.nano in the
source package.
</pre>

* Garbage Collection
Voir tinygc http://tinygc.sourceforge.net/
à voir aussi celui de micropython

* libprce
Voir T-Rex is a minimalistic regular expression http://tiny-rex.sourceforge.net/ http://sourceforge.net/projects/tiny-rex/

= Progress=
project start : 13/01/2014

== Week 1 (13/01 - 19/01) ==
* Project discovery
* Research of related projects

== Week 2 (20/01 - 26/01) ==
* STM32 develop environment

'''Add USB device'''
Create a new udev rule in /etc/udev/rules.d/45-usb-stlink-v2.rules:
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="660", GROUP="plugdev"
To reboot :
$ sudo service udev restart

'''Download the GNU/ARM toolchain'''
Download the Linux current installation tarball from
https://launchpad.net/gcc-arm-embedded/+download
$ tar -xvjf gcc-arm-none-eabi-xxxxxxxxxxxxxxxxxx-linux.tar.bz2
Add the fallowing to your ~/.bashrc
export PATH=$PATH:~/xxxxxxx/gcc-arm-none-eabi-xxxxxxxxx/bin
$ source ~/.bashrc
To check :
$ arm-none-eabi-gcc --version
If you get an error message “bash : ... file does not exist”.
Maybe it is caused by the difference between 32bit and 64bit system. Try :
$ sudo apt-get install ia32-libs*

'''Download and Build STLINK'''
STLINK is for programming and debugging firmware.
you'll first need to install a couple of packages:
$ sudo apt-get install autoconf pkg-config libusb-1.0 git
Retrieve a copy of the STLINK source:
$ git clone https://github.com/texane/stlink.git
Build the code following the instructions in the README, with:
$ ./autogen.sh
$ ./configure
$ make
As a sanity check, look in ~/st-link and you should see st-util, st-flash, etc...
You may check if the board could be connected by execute st-util.
If it does not work please confirm if the rule you added in the first step corresponds your system.

'''Refer to link''' : http://www.wolinlabs.com/blog/linux.stm32.discovery.gcc.html

* Try the official examples of ST on the cards
To avoid using the commercial software IDE and understand better, We decided to develop on Linux for this project.
During the tries, for certain examples, we've got different results on STM32F407 and STM32F401.
We choose STM32F407 as the hardware for the following developement.

== Week 3 (27/01 - 02/02) ==
* Test Project MicroPython
* Test Project Shedskin

* STM32 hardware
[[File:PythonSurSTM32_Hardware_1.png|800px]]

[[File:PythonSurSTM32_Hardware_2.png|800px]]

== Week 4 (02/02 - 09/02) ==
* STM32 breakdown situation & solution

'''Cause Reason'''
After
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;
GPIOC->MODER = 0x04000000;
GPIOC->ODR ^= (1 << 13);
is used (compiled and burned successfully)

'''Status'''
'''1)''' $st-flash write timer_gpio_out.bin 0x8000000
2012-02-09T23:25:54 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:25:54 WARN src/stlink-common.c: unknown chip id! 0
stlink_sram_flash() == -1
make: *** [write] Error 255

'''2)''' hold the Reset button while:
$./st-util
2012-02-25T16:00:42 INFO src/stlink-common.c: Loading device parameters....
2012-02-25T16:00:42 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2012-02-25T16:00:42 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

'''3)''' $st-flash erase
2012-02-09T23:28:01 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:01 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Mass erasing

'''4)''' If I hold the Reset button while erasing:
ahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
2012-02-09T23:28:28 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:28 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-09T23:28:28 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0 bytes (0 KiB) in pages of 256 bytes
Mass erasing

'''5)''' If I hold the Reset button while flashing:
dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
../../flash/flash write lcd.bin 0x08000000
2012-02-10T14:13:21 INFO src/stlink-common.c: Loading device parameters....
2012-02-10T14:13:21 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-10T14:13:21 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2012-02-10T14:13:21 INFO src/stlink-common.c: Attempting to write 7332 (0x1ca4) bytes to stm32 address: 134217728 (0x8000000)
2012-02-10T14:13:21 WARN src/stlink-common.c: pecr.pelock not clear (0x7)
2012-02-10T14:13:21 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
stlink_fwrite_flash() == -1
make: *** [write] Error 255

'''Solution'''
'''1)''' hold the Reset button while:
$ st-util
2013-03-23T15:51:17 INFO src/stlink-common.c: Loading device parameters....
2013-03-23T15:51:17 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2013-03-23T15:51:17 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
Chip ID is 00000410, Core ID is 1ba01477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

'''2)''' Next you will need to launch gdb (in a new terminal) from the tools directory
and make use of the compiled binary that you pulled created earlier during the "make all".
$ tools/arm-2011.03/bin/arm-none-eabi-gdb -q build/fw_coptercontrol/fw_coptercontrol.elf
Reading symbols from
/home/xxx/OpenPilot/build/fw_coptercontrol/fw_coptercontrol.elf...done.
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x0800010c in ?? ()
(gdb) bt
#0 0x0800010c in ?? ()
#1 0xffffffff in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) i r
r0 0x0 0
r1 0xa5a5a5a5 2779096485
r2 0x0 0
r3 0x200002d4 536871636
r4 0x20000cd0 536874192
r5 0xa5a5a5a5 2779096485
r6 0xa5a5a5a5 2779096485
r7 0xa5a5a5a5 2779096485
r8 0xa5a5a5a5 2779096485
r9 0xa5a5a5a5 2779096485
r10 0xa5a5a5a5 2779096485
r11 0xa5a5a5a5 2779096485
r12 0xa5a5a5a5 2779096485
sp 0x20000938 0x20000938
lr 0xffffffff 4294967295
pc 0x800010c 0x800010c
fps 0xaddeadde 2917051870
cpsr 0x1000000 16777216
(gdb) c
Continuing.

Hit CTRL+C to test breakpoints and use l to see line numbers

(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x080039a0 in nmeaProcessGPRMC (GpsData=0xa5a5a5a5, gpsDataUpdated=<value optimized out>, param=0x20000cd0,
nbParam=<value optimized out>) at ../Modules/GPS/NMEA.c:559
559 GpsData->Heading = NMEA_real_to_float(param[8]);
(gdb) l

I quitted the gdb when i found that the board worked again. Again you can easily verify the firmware.

There are some situations solved by erasing or flashing while holding the reset button(black), but it does not work in our issue.

'''Refer to link''' :
http://forums.openpilot.org/topic/20173-regrouping-on-various-stm32f4discovery-swd-debugging-for-oplink-revo-cc3d/

* Test of STM32 printf
Refer to link : http://vedder.se/2012/07/usb-serial-on-stm32f4/

We have tried the program for the STM32F4 Discovery that uses the USB-CDC class to show up as an virtual serial port.
It has routed the write system call to use this port, so the stdio printf function will print directly to this serial port.
After have uploaded the program to the STM32F4 discovery and plug in a micro-USB cable to the port next to the audio jack.
The serial port should show up as /dev/ttyACM0 on most GNU/Linux distributions, such as Ubuntu.
Start a serial port terminal, such as gtkterm (sudo apt-get install gtkterm on Debian/Ubuntu), and open ttyACM0.
As the following shot-screen :
[[File:PythonSurSTM32_printf_shotscreen.png|800px]]

== Week 5 (10/02 - 17/02) ==

* SRS document [[Proj-2013-2014-Python-STM32F4:SRS]]
* build and learn Project STM32Plus

== Week 6-8 (17/02 - 10/03) ==
* The first version of the program
We have finished the first version of the program. In order to trait the text easier, we have made the choice of using TCL script language.
The file structrue of the project is shown as bellow:
[[File:PythonSurSTM_file_struct.png|900px]]
'''py2stm.tcl''' : executable file, the main program of the project;
'''print''' : directory, the library and .o files corresponding to realise printf function;
'''shedskin_lib''' : directory, the modified library of shedskin;
'''defaut''' : necessary files for compiling and executing on STM (link file, the file who realise the functions of low level, etc)

'''Needed Library & Program''' : STM32Plus, Arm-gcc, STLink. These paths are all defined at the beginning of the file '''py2stm.tcl'''.
With the help of this program, from a python source code, we could translate, generate project,
and download the compiled project to the card only with one command.

The program work flow is shown as the following:
[[File:PythonSurSTM_flow_chart.png|400px]]
To support arm-g++ compiling, we have modified the library of shedskin. We have deleted the corresponding code of GC and PCRE.
Instead of using GC, we have included the library of STM32Plus to support the fonctions of malloc, std::string, etc.

The usage of the program is shown bellow:
[[File:PythonSurSTM_usage.png|900px]]

an example:
[[File:PythonSurSTM_compile.png|900px]]
In the make file, we will compile the corresponding files of ShedSkin library, the needed low level functions,
and link the stm32plus library. When we choose Deubg Mode, we will also need to link the STM Common library.

With the option -b, the compiled program for stm will be burned to the card when finishing compile.
[[File:PythonSurSTM_burn.png|900px]]

When there's a error (the python file doesn't existe)
[[File:PythonSurSTM_no_file.png|900px]]

With the option -d, the function printf will be supported in the generated project.
We have defined some low level functions in the file print/syscall.c to support printf, and we have done an redirection of the USB.
The content of the printf will be sent to the USB, so users could use gtkterm to open the port ttyACM0 to have look at it and debug.
The device will be found after the burn as following:
[[File:PythonSurSTM_dev.png|900px]]

With the help of gtkterm ( or other visual tools ), we could choose the port ttyACM0, and see the content of the printf:
[[File:PythonSurSTM_gtkterm.png|900px]]

To support the fonction printf, we have used arm-gcc and arm-g++ in the same time.
The reason is that, most of the examples of STM32 are in C ( STM official examples included ), In this project,
the code translated by shedskin is in CPP, so we have to face up to the difficulty of using arm-gcc and arm-g++.
We have used extern "C" {...} to compile the printf corresponding CPP code.
If not, the linker will not be able the find the reference of the calling of C functions.

For this function, during the executing of the program, we will not copy the source code of the printf to the generated project,
we compile the printf corresponding fonctions only once, the .o files will be in the directory of py2stm/print.
We think these functions are diffrent to the copied low level functions, they are not part of the genereated project,
so we compile only once and we reuse them when linking.

For the reason of the redirection of USB, every time after we download the program to the card,
we could not download normally for another time. In this case, we could run stlink/st-util when
clicking the reset button of the card, then we will be able to download again.
[[File:PythonSurSTM_stlink.png|900px]]

== Week 9-11 (10/03 - 31/03) ==

'''Debug'''
We have fixed some bugs of no-existed head files, not found function definitions.
We have resorved the problem of exception and print in the source files.

'''Evaluation'''

We have tried all the examples in the project Shedskin, we have get the evaluation result:
For 117 files (.py) :
0,1,2,3,4,5,6,7,8,9,10,11,12,13,15,16,18,19,20,21,22,23,24,25,26,28,31,32,33,36,38,40,43,44,45,
46,50,52,53,54,55,56,59,60,64,69,71,75,76,77,78,79,81,82,83,84,86,88,89,93,94,95,97,98,99,100,102,
103,104,105,106,107,108,109,110,111,112,113,114,115,118,119,120,123,124,126,127,129,130,132,133,
134,137,138,139,140,141,142,143,144,146,147,148,152,155,156,157,158,161,162,167,168,170,175,176,183,187
We have finished the compilation.

For 10 fichiers (.py):
122,131,135,150,159,160,163,164,172,173
We could not finish the compilation for the reason of the using of system time.

For 14 files (.py):
29,30,37,125,128,136,151,153,154,165,166,171,190,195
We could not finish the compilation for the reason of the using of iostream of files.

For 13 fichiers (.py):
39,51,177,180,181,182,184,192,193,194,196,198,199
Shedskin could not support their translation.

For 12 files (.py):
169,174,179,185,186,188,189,191,197,200,201,202
We could not finish the compilation for different reasons.

== Week 12 (31/03 - 07/04) ==
Report Writing

[[Media:PythonSurSTM_Rapport.pdf|Report]]

[[Media:PythonSurSTM_Soutenance.pdf|PowerPoint]]

Proj-2013-2014-Python-STM32F4

2016-02-06T15:23:41Z

RICM4-prj14-grp9:

= Introduction =
[[Python_sur_STM32F4]]

= Team =
*Tutors : Olivier Richard
*Members : [[User:Ye XIA|XIA Ye]] , [[User:Xinxiu TAO|TAO Xinxiu]]

= Objectives =

= Software Requirements Specification (SRS) =
The SRS document:
* [[Proj-2013-2014-Python-STM32F4:SRS]]

= Points à traiter =
* Modidification des Makefile
utilisation de arm-none-eabi-g++ et des bonnes options
https://launchpad.net/gcc-arm-embedded

* support STL
Voir https://github.com/andysworkshop/stm32plus
à voir aussi
uSTL http://msharov.github.io/ustl/

* Lib C
Voir newlib et newlib-nano
https://launchpad.net/gcc-arm-embedded

<pre>
from gcc-arm-embedded source
https://launchpadlibrarian.net/160487135/readme.txt

* C Libraries usage *

This toolchain is released with two prebuilt C libraries based on newlib:
one is the standard newlib and the other is newlib-nano for code size.
To distinguish them, we rename the size optimized libraries as:

libc.a --> libc_s.a
libg.a --> libg_s.a

To use newlib-nano, users should provide additional gcc link time option:
--specs=nano.specs

Nano.specs also handles two additional gcc libraries: libstdc++_s.a and
libsupc++_s.a, which are optimized for code size.

For example:
$ arm-none-eabi-gcc src.c --specs=nano.specs $(OTHER_OPTIONS)

This option can also work together with other specs options like
--specs=rdimon.specs

Please be noticed that --specs=nano.specs is a linker option. Be sure
to include in linker option if compiling and linking are separated.

** additional newlib-nano libraries usage

Newlib-nano is different from newlib in addition to the libraries' name.
Formatted input/output of floating-point number are implemented as weak symbol.
If you want to use %f, you have to pull in the symbol by explicitly specifying
"-u" command option.

-u _scanf_float
-u _printf_float

e.g. to output a float, the command line is like:
$ arm-none-eabi-gcc --specs=nano.specs -u _printf_float $(OTHER_LINK_OPTIONS)

For more about the difference and usage, please refer the README.nano in the
source package.
</pre>

* Garbage Collection
Voir tinygc http://tinygc.sourceforge.net/
à voir aussi celui de micropython

* libprce
Voir T-Rex is a minimalistic regular expression http://tiny-rex.sourceforge.net/ http://sourceforge.net/projects/tiny-rex/

= Progress=
project start : 13/01/2014

== Week 1 (13/01 - 19/01) ==
* Project discovery
* Research of related projects

== Week 2 (20/01 - 26/01) ==
* STM32 develop environment

'''Add USB device'''
Create a new udev rule in /etc/udev/rules.d/45-usb-stlink-v2.rules:
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="660", GROUP="plugdev"
To reboot :
$ sudo service udev restart

'''Download the GNU/ARM toolchain'''
Download the Linux current installation tarball from
https://launchpad.net/gcc-arm-embedded/+download
$ tar -xvjf gcc-arm-none-eabi-xxxxxxxxxxxxxxxxxx-linux.tar.bz2
Add the fallowing to your ~/.bashrc
export PATH=$PATH:~/xxxxxxx/gcc-arm-none-eabi-xxxxxxxxx/bin
$ source ~/.bashrc
To check :
$ arm-none-eabi-gcc --version
If you get an error message “bash : ... file does not exist”.
Maybe it is caused by the difference between 32bit and 64bit system. Try :
$ sudo apt-get install ia32-libs*

'''Download and Build STLINK'''
STLINK is for programming and debugging firmware.
you'll first need to install a couple of packages:
$ sudo apt-get install autoconf pkg-config libusb-1.0 git
Retrieve a copy of the STLINK source:
$ git clone https://github.com/texane/stlink.git
Build the code following the instructions in the README, with:
$ ./autogen.sh
$ ./configure
$ make
As a sanity check, look in ~/st-link and you should see st-util, st-flash, etc...
You may check if the board could be connected by execute st-util.
If it does not work please confirm if the rule you added in the first step corresponds your system.

'''Refer to link''' : http://www.wolinlabs.com/blog/linux.stm32.discovery.gcc.html

* Try the official examples of ST on the cards
To avoid using the commercial software IDE and understand better, We decided to develop on Linux for this project.
During the tries, for certain examples, we've got different results on STM32F407 and STM32F401.
We choose STM32F407 as the hardware for the following developement.

== Week 3 (27/01 - 02/02) ==
* Test Project MicroPython
* Test Project Shedskin

* STM32 hardware
[[File:PythonSurSTM32_Hardware_1.png|800px]]

[[File:PythonSurSTM32_Hardware_2.png|800px]]

== Week 4 (02/02 - 09/02) ==
* STM32 breakdown situation & solution

'''Cause Reason'''
After
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;
GPIOC->MODER = 0x04000000;
GPIOC->ODR ^= (1 << 13);
is used (compiled and burned successfully)

'''Status'''
'''1)''' $st-flash write timer_gpio_out.bin 0x8000000
2012-02-09T23:25:54 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:25:54 WARN src/stlink-common.c: unknown chip id! 0
stlink_sram_flash() == -1
make: *** [write] Error 255

'''2)''' hold the Reset button while:
$./st-util
2012-02-25T16:00:42 INFO src/stlink-common.c: Loading device parameters....
2012-02-25T16:00:42 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2012-02-25T16:00:42 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

'''3)''' $st-flash erase
2012-02-09T23:28:01 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:01 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Mass erasing

'''4)''' If I hold the Reset button while erasing:
ahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
2012-02-09T23:28:28 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:28 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-09T23:28:28 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0 bytes (0 KiB) in pages of 256 bytes
Mass erasing

'''5)''' If I hold the Reset button while flashing:
dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
../../flash/flash write lcd.bin 0x08000000
2012-02-10T14:13:21 INFO src/stlink-common.c: Loading device parameters....
2012-02-10T14:13:21 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-10T14:13:21 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2012-02-10T14:13:21 INFO src/stlink-common.c: Attempting to write 7332 (0x1ca4) bytes to stm32 address: 134217728 (0x8000000)
2012-02-10T14:13:21 WARN src/stlink-common.c: pecr.pelock not clear (0x7)
2012-02-10T14:13:21 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
stlink_fwrite_flash() == -1
make: *** [write] Error 255

'''Solution'''
'''1)''' hold the Reset button while:
$ st-util
2013-03-23T15:51:17 INFO src/stlink-common.c: Loading device parameters....
2013-03-23T15:51:17 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2013-03-23T15:51:17 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
Chip ID is 00000410, Core ID is 1ba01477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

'''2)''' Next you will need to launch gdb (in a new terminal) from the tools directory
and make use of the compiled binary that you pulled created earlier during the "make all".
$ tools/arm-2011.03/bin/arm-none-eabi-gdb -q build/fw_coptercontrol/fw_coptercontrol.elf
Reading symbols from
/home/xxx/OpenPilot/build/fw_coptercontrol/fw_coptercontrol.elf...done.
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x0800010c in ?? ()
(gdb) bt
#0 0x0800010c in ?? ()
#1 0xffffffff in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) i r
r0 0x0 0
r1 0xa5a5a5a5 2779096485
r2 0x0 0
r3 0x200002d4 536871636
r4 0x20000cd0 536874192
r5 0xa5a5a5a5 2779096485
r6 0xa5a5a5a5 2779096485
r7 0xa5a5a5a5 2779096485
r8 0xa5a5a5a5 2779096485
r9 0xa5a5a5a5 2779096485
r10 0xa5a5a5a5 2779096485
r11 0xa5a5a5a5 2779096485
r12 0xa5a5a5a5 2779096485
sp 0x20000938 0x20000938
lr 0xffffffff 4294967295
pc 0x800010c 0x800010c
fps 0xaddeadde 2917051870
cpsr 0x1000000 16777216
(gdb) c
Continuing.

Hit CTRL+C to test breakpoints and use l to see line numbers

(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x080039a0 in nmeaProcessGPRMC (GpsData=0xa5a5a5a5, gpsDataUpdated=<value optimized out>, param=0x20000cd0,
nbParam=<value optimized out>) at ../Modules/GPS/NMEA.c:559
559 GpsData->Heading = NMEA_real_to_float(param[8]);
(gdb) l

I quitted the gdb when i found that the board worked again. Again you can easily verify the firmware.

There are some situations solved by erasing or flashing while holding the reset button(black), but it does not work in our issue.

'''Refer to link''' :
http://forums.openpilot.org/topic/20173-regrouping-on-various-stm32f4discovery-swd-debugging-for-oplink-revo-cc3d/

* Test of STM32 printf
Refer to link : http://vedder.se/2012/07/usb-serial-on-stm32f4/

We have tried the program for the STM32F4 Discovery that uses the USB-CDC class to show up as an virtual serial port.
It has routed the write system call to use this port, so the stdio printf function will print directly to this serial port.
After have uploaded the program to the STM32F4 discovery and plug in a micro-USB cable to the port next to the audio jack.
The serial port should show up as /dev/ttyACM0 on most GNU/Linux distributions, such as Ubuntu.
Start a serial port terminal, such as gtkterm (sudo apt-get install gtkterm on Debian/Ubuntu), and open ttyACM0.
As the following shot-screen :
[[File:PythonSurSTM32_printf_shotscreen.png|800px]]

== Week 5 (10/02 - 17/02) ==

* SRS document [[Proj-2013-2014-Python-STM32F4:SRS]]
* build and learn Project STM32Plus

== Week 6-8 (17/02 - 10/03) ==
* The first version of the program
We have finished the first version of the program. In order to trait the text easier, we have made the choice of using TCL script language.
The file structrue of the project is shown as bellow:
[[File:PythonSurSTM_file_struct.png|900px]]
'''py2stm.tcl''' : executable file, the main program of the project;
'''print''' : directory, the library and .o files corresponding to realise printf function;
'''shedskin_lib''' : directory, the modified library of shedskin;
'''defaut''' : necessary files for compiling and executing on STM (link file, the file who realise the functions of low level, etc)

'''Needed Library & Program''' : STM32Plus, Arm-gcc, STLink. These paths are all defined at the beginning of the file '''py2stm.tcl'''.
With the help of this program, from a python source code, we could translate, generate project,
and download the compiled project to the card only with one command.

The program work flow is shown as the following:
[[File:PythonSurSTM_flow_chart.png|400px]]
To support arm-g++ compiling, we have modified the library of shedskin. We have deleted the corresponding code of GC and PCRE.
Instead of using GC, we have included the library of STM32Plus to support the fonctions of malloc, std::string, etc.

The usage of the program is shown bellow:
[[File:PythonSurSTM_usage.png|900px]]

an example:
[[File:PythonSurSTM_compile.png|900px]]
In the make file, we will compile the corresponding files of ShedSkin library, the needed low level functions,
and link the stm32plus library. When we choose Deubg Mode, we will also need to link the STM Common library.

With the option -b, the compiled program for stm will be burned to the card when finishing compile.
[[File:PythonSurSTM_burn.png|900px]]

When there's a error (the python file doesn't existe)
[[File:PythonSurSTM_no_file.png|900px]]

With the option -d, the function printf will be supported in the generated project.
We have defined some low level functions in the file print/syscall.c to support printf, and we have done an redirection of the USB.
The content of the printf will be sent to the USB, so users could use gtkterm to open the port ttyACM0 to have look at it and debug.
The device will be found after the burn as following:
[[File:PythonSurSTM_dev.png|900px]]

With the help of gtkterm ( or other visual tools ), we could choose the port ttyACM0, and see the content of the printf:
[[File:PythonSurSTM_gtkterm.png|900px]]

To support the fonction printf, we have used arm-gcc and arm-g++ in the same time.
The reason is that, most of the examples of STM32 are in C ( STM official examples included ), In this project,
the code translated by shedskin is in CPP, so we have to face up to the difficulty of using arm-gcc and arm-g++.
We have used extern "C" {...} to compile the printf corresponding CPP code.
If not, the linker will not be able the find the reference of the calling of C functions.

For this function, during the executing of the program, we will not copy the source code of the printf to the generated project,
we compile the printf corresponding fonctions only once, the .o files will be in the directory of py2stm/print.
We think these functions are diffrent to the copied low level functions, they are not part of the genereated project,
so we compile only once and we reuse them when linking.

For the reason of the redirection of USB, every time after we download the program to the card,
we could not download normally for another time. In this case, we could run stlink/st-util when
clicking the reset button of the card, then we will be able to download again.
[[File:PythonSurSTM_stlink.png|900px]]

== Week 9-11 (10/03 - 31/03) ==

'''Debug'''
We have fixed some bugs of no-existed head files, not found function definitions.
We have resorved the problem of exception and print in the source files.

'''Evaluation'''

We have tried all the examples in the project Shedskin, we have get the evaluation result:
For 117 files (.py) :
0,1,2,3,4,5,6,7,8,9,10,11,12,13,15,16,18,19,20,21,22,23,24,25,26,28,31,32,33,36,38,40,43,44,45,
46,50,52,53,54,55,56,59,60,64,69,71,75,76,77,78,79,81,82,83,84,86,88,89,93,94,95,97,98,99,100,102,
103,104,105,106,107,108,109,110,111,112,113,114,115,118,119,120,123,124,126,127,129,130,132,133,
134,137,138,139,140,141,142,143,144,146,147,148,152,155,156,157,158,161,162,167,168,170,175,176,183,187
We have finished the compilation.

For 10 fichiers (.py):
122,131,135,150,159,160,163,164,172,173
We could not finish the compilation for the reason of the using of system time.

For 14 files (.py):
29,30,37,125,128,136,151,153,154,165,166,171,190,195
We could not finish the compilation for the reason of the using of iostream of files.

For 13 fichiers (.py):
39,51,177,180,181,182,184,192,193,194,196,198,199
Shedskin could not support their translation.

For 12 files (.py):
169,174,179,185,186,188,189,191,197,200,201,202
We could not finish the compilation for different reasons.

== Week 12 (31/03 - 07/04) ==
Report Writing

[[Media:PythonSurSTM_Rapport.pdf|Report]]

[[Media:PythonSurSTM_Soutenance.pdf|PowerPoint]]

Proj-2014-2015-iRock

2015-03-31T11:42:39Z

RICM4-prj14-grp9: /* Problèmes rencontrés */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.

==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif était d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous avons réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled. De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible). Les fonctions de cryptage ont été mise en place mais un problème persiste. Un message cryptée sur une carte A est bien décrypté sur cette même carte A. Par contre si il est envoyé sur une carte B pour y être décrypté, cela ne marche pas malgré que le message reçu sur la carte B soit identique au message envoyé par la carte A.

==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...).Dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.

==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon.

===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet au niveau de l'économie d'énergie et du respect des normes européennes.

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-31T11:40:27Z

RICM4-prj14-grp9: /* Problèmes rencontrés */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.

==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif était d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous avons réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled. De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)

==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...).Dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.

==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon.

===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet au niveau de l'économie d'énergie et du respect des normes européennes.

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-31T11:39:07Z

RICM4-prj14-grp9: /* Problèmes rencontrés */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.

==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif était d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous avons réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled. De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)

==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...).Dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.

==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon.

===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-31T11:29:14Z

RICM4-prj14-grp9: /* Objectif: */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.

==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif était d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous avons réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled. De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)

==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon.

===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-31T11:28:30Z

RICM4-prj14-grp9: /* Problèmes rencontrés */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.

==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif était d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous avons réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled. De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)

==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-31T11:27:53Z

RICM4-prj14-grp9: /* Objectif: */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.

==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif était d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous avons réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-31T11:26:37Z

RICM4-prj14-grp9: /* Partie capteur et acquisition de données */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.

==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-30T20:45:54Z

RICM4-prj14-grp9:

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
===Technologie utilisée===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.

Proj-2014-2015-iRock

2015-03-30T20:38:51Z

RICM4-prj14-grp9: /* Introduction */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum""": http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimètre). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accéléromètres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoi un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduino
===Technologie utiliseé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Proj-2014-2015-iRock

2015-03-30T20:30:11Z

RICM4-prj14-grp9: /* Conclusion générale/ Perspective d'évolution */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum""": http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimètre). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accéléromètres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoi un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduino
===Technologie utiliseé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.

Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

File:Proj-2014-2015-iRock-flyer.pdf

2015-03-30T19:09:34Z

RICM4-prj14-grp9:

Proj-2014-2015-iRock

2015-03-25T08:48:15Z

RICM4-prj14-grp9:

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum""": http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimètre). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accéléromètres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoi un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisée===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduino
===Technologie utiliseé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problèmes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisée===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Proj-2014-2015-iRock

2015-03-25T08:47:34Z

RICM4-prj14-grp9:

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum""": http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimètre). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accéléromètres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoi un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisé===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduino
===Technologie utilisé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problémes rencontrés===
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...)dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon
===Technologie utilisé===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet:

=Conclusion générale/ Perspective d'évolution=

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Proj-2014-2015-iRock

2015-03-25T08:33:43Z

RICM4-prj14-grp9:

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum""": http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie).Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un systéme d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit etre réaliser au millimétre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimètre). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accélérométres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoit un message dés qu'elle est en mouvement).Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium etaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech ,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement concue pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA éffectué, il nous faut choisir nos cartes de capteurs. Nous avons optés pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétométre ou accélérométre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisé===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal probléme rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothéque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus ,aprés présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son cout, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduinos
===Technologie utilisé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problémes rencontrés===
Le principale probléme rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5à% ,...)dés que nous branchions la mbed LoRA en plus, larte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s'avére que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et ecriture des scrypts python pour transmettre les données de la mbed de recption au pc de reception (par le port serial), du pc recepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une achine Amazon
===Technologie utilisé===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problémes rencontrés dans cette partie. On utilise un systeme de requette html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets json à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initales du projet:

=Conclusion générale/ Perspective d'évolution=

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Proj-2014-2015-iRock

2015-03-25T08:30:25Z

RICM4-prj14-grp9: /* Links */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière geotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015
*'''Diagrammes UML''': http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
*'''Scrum""": http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combiné à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie).Notre objectif est aussi de minimiser le cout de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un systéme d'export en fichier Excel à été mis en place ,pour avoir accés simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit ete réaliser au milimétre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimétre).Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ juste que nous devions utiliser la technologie LoRA pour les communications.Mais plusieurs cartes embarqué pouvait permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisé fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accélérométres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoit un message dés qu'elle est en mouvement).Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium etaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech ,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement concue pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA éffectué, il nous faut choisir nos cartes de capteurs. Nous avons optés pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétométre ou accélérométre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisé===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal probléme rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothéque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus ,aprés présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son cout, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduinos
===Technologie utilisé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problémes rencontrés===
Le principale probléme rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5à% ,...)dés que nous branchions la mbed LoRA en plus, larte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s'avére que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et ecriture des scrypts python pour transmettre les données de la mbed de recption au pc de reception (par le port serial), du pc recepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une achine Amazon
===Technologie utilisé===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problémes rencontrés dans cette partie. On utilise un systeme de requette html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets json à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initales du projet:

=Conclusion générale/ Perspective d'évolution=

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Projets 2014-2015

2015-03-25T08:25:47Z

RICM4-prj14-grp9: /* Projet Semestre S10 */

<<[[Projets 2013-2014]] [[Projets|^Projets^]] [[Projets 2015-2016]]>>

=RICM=
==RICM3==

==RICM4==

* '''Evaluation à mi-parcours le lundi 2 mars''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: vous creusez la question, vous contactez l'auteur du code si il y a lieux, vous faites un rapport de bug ('''Attention:''' ca se prépare !), vous soumettez un patch, vous contactez l'enseignant ou la personne suivant le projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle
indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par ricm4_2014_2015.

* '''Vous devez utiliser un logiciel de gestion de version''' pour vos développements comme [http://en.wikipedia.org/wiki/Git_%28software%29 git ] et nous vous conseillons d'utiliser le site [https://github.com github] pour l'hébergement de votre dépôt public.

* Les document public (exemple sur github) doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

{|class="wikitable alternance"
|+ Affectation des projets RICM4 2014-2015
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[Projet de monoski intelligent]]
| Blondet, Torck
| Didier Donsez, Pascal Jay, David Eon
| [[Proj-2014-2015-MonoskiIntelligent| '''Fiche''']] [[Proj-2014-2015-MonoskiIntelligent/SRS| '''SRS''']]==== Sprint 5 ====
----
Sprint Duration
===== Sprint goals =====

===== Sprint Backlog =====
[[Proj-2014-2015-MonoskiIntelligent/UML| '''Diagrammes UML''']] [[Proj-2014-2015-MonoskiIntelligent/Scrum| '''Scrum''']] ([https://waffle.io/quentin74/monoski Waffle])
| [https://github.com/quentin74/application-monoski '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 2
| [[Smart Classroom]]
| Darrigol, Badamo, Damotte, Leonard
| Didier Donsez, Vivien Quema, Jérome Maisonnasse
| [[Proj-2014-2015-SmartClassroom| '''Fiche''']] [[Proj-2014-2015-SmartClassroom/SRS| '''SRS''']] [[Proj-2014-2015-SmartClassroom/UML| '''Diagrammes UML''']] [[Proj-2014-2015-SmartClassroom/Scrum| '''Scrum''']]
| [https://github.com/AlanDamotte/auth '''github''']
| [[Media:Proj-2014-2015-SmartClassroom/Rapport|rapport]] - [[Media:Proj-2014-2015-SmartClassroom-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassroom-flyer.pdf|flyer]] [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 3
| [[RobAIR]] et [[STM32 Nucleo]]
| Hammerer, Michel, Klipffel, Viallet **
| Didier Donsez
| [[Projet-2014-2015-RobAIR| '''Fiche''']] [[Projet-2014-2015-RobAIR/SRS| '''SRS''']] [[Projet-2014-2015-RobAIR/UML| '''Diagrammes UML''']] [[Projet-2014-2015-RobAIR/Scrum| '''Scrum''']]
| [https://github.com/teiroy/RobAIR '''github''']
| [[Media:Projet-2014-2015-RobAIR/Rapport|rapport]] - [[Media:Projet-2014-2015-RobAIR-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] [[Media:Projet-2014-2015-RobAIR-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 4
| [[IDS|Interactive Digitale Signage]]
| Adam, Zhang
| Didier Donsez
| [[Proj-2014-2015-Interactive_Digitale_Signage| '''Fiche''']] [[Projet-2014-2015-Interactive_Digitale_Signage/SRS| '''SRS''']] [[Projet-2014-2015-Interactive_Digitale_Signage/UML| '''Diagrammes UML''']] [[Projet-2014-2015-Interactive_Digitale_Signage/Scrum| '''Scrum''']]
| [https://github.com/zhangzhengmeng/ProjetIDS2015.git '''github''']
| [[Media:Proj-2014-2015-Interactive_Digitale_Signage/Rapport|rapport]] - [[Media:Proj-2014-2015-Interactive_Digitale_Signage-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-Interactive_Digitale_Signage-flyer.pdf|flyer]] [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 5
| [[Régie vidéo autonome et mobile multi-caméra]]
| Zominy, Bodard, Qian
| Didier Donsez, Thierry C.
| [[Proj-2014-2015-RegieVideoAutonomeEtMobileMulticamera| '''Fiche''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/SRS| '''SRS''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/Scrum| '''Scrum''']]
| [https://github.com/kurisuter/Regie-video-autonome-'''github''']
| [[Media:Projet-2014-2015-RegieVideoAutonomeEtMobileMulticamera/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 6
| OpenHAB Extended GUI ([[IFTTT]] et à la [[Node-RED]] ou [[Flowhub]] pour [[OpenHAB]], Découverte [[UPnP]] des équipements)
| Toussaint, Saussac
| Didier Donsez
| [[Proj-2014-2015-OpenHAB-ExtendedGUI| '''Fiche''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/SRS| '''SRS''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/UML| '''Diagrammes UML''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/Scrum| '''Scrum''']]
| [https://github.com/saussact/projet '''github''']
| [[Media:Proj-2014-2015-OpenHAB-ExtendedGUI/Rapport|rapport]] - [[Media:Proj-2014-2015-OpenHAB-ExtendedGUI-transparents.pdf|transparents]] - [[Media:PProj-2014-2015-OpenHAB-ExtendedGUI-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 7
| [[CannonBall de voitures autonomes|CannonBall de voitures autonomes, Edition 2015]]
| Le-Jean, Mammar, Pelloux-Prayer, Rodrigues
| Didier Donsez & Vivien Quema
| [[Project-2014-2015-CannonBall| '''Fiche''']][[Project 2014-2015-CannonBall/SRS| '''SRS''']][[Project 2014-2015-CannonBall/UML| '''UML''']][[Project 2014-2015-CannonBall/Scrum| '''Scrum''']][[Project 2014-2015-CannonBall/DesignPatterns| '''DesignPatterns''']]
| [https://github.com/malek0512/2014_2015_ricm4_cannon_ball '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 8
| [[Navigation et Montre connectée]]
| Hamdani, Mesnier, Yao
| Jacques Lemordant
| [[Proj-2014-2015-Montreconnectée| '''Fiche''']] [[Proj-2014-2015-Montreconnectée/SRS| '''SRS''']] [[Proj-2014-2015-Montreconnectée/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Montreconnectée/Scrum| '''Scrum''']][[Proj-2014-2015-Montreconnectée/DesignPattern| '''DesignPattern''']]
| [https://github.com/vince0508/MontreConnectee '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 9
| [[Python sur ESP8266]]
| Libralesso, Soldano
| Olivier Richard
| [[Project-2014-2015-ESP8266| '''Fiche''']] - [[Proj-2014-2015-ESP8266/SRS| '''SRS''']] - [[Proj-2014-2015-ESP8266/UML| '''UML diagrams''']] - [[Proj-2014-2015-ESP8266/Scrum| '''Scrum''']]
| [https://github.com/librallu/RICM4Projet/ '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast] - [http://librallu.github.io/RICM4Projet/ '''website''']
|-

!scope="row"| 10
| [[Serious Game: Handicap, parole et geste v2]]
| Aissanou, Codazzi, Guo
| Olivier Richard
| [[Proj-2014-2015-SeriousGamev2| '''Fiche''']][[Proj-2014-2015-SeriousGamev2/SRS| '''SRS''']][[Proj-2014-2015-SeriousGamev2/Scrum| '''Scrum''']] [[Projet-2014-2015-SeriousGamev2/Diagrammes| '''Diagrammes UML''']]
| [https://github.com/wizardkeven/SeriousGameV2 '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 11
| [[Plateforme d'expérimentation mini-datacentre]] Système
| Fotsing, Morison
| Olivier Richard
| [[Proj-2014-2015-Mini_DataCenter_Systeme| '''Fiche''']][[Proj-2014-2015-Mini_datacenter_Systeme_SRS| '''SRS''']] [[Proj-2014-2015-Mini_datacenter_Systeme_scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:ProjetMini_DataCenter_Systeme/Rapport|rapport]] - [[Media:ProjetMini_DataCenter_Systeme-transparents.pdf|transparents]] - [[Media:ProjetMini_DataCenter_Systeme-flyer.pdf|flyer]]- [[Media:ProjetMini_DataCenter_Systeme-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 12
| [[Plateforme d'expérimentation mini-datacentre]] Portail
| Rossi, Eudes
| Olivier Richard
| [[Proj-2014-2015-Mini_datacenter_portail| '''Fiche''']] [[Proj-2014-2015-Mini_datacenter_portail_SRS| '''SRS''']] [[Proj-2014-2015-Mini_datacenter_portail_scrum| '''Scrum''']] [[Proj-2014-2015-Mini_datacenter_portail_uml| '''UML''']]
| [https://github.com/EudesRobin/webui-oardocker '''github''']
| [[Media:Projet_Projet_Mini_datacenter_portail/Rapport|rapport]] - [[Media:Projet_Mini_datacenter_portail-transparents.pdf|transparents]] - [[Media:Projet_Mini_datacenter_portail-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

|}

* [[Projet de monoski intelligent]] (RICM4 et 3I4 et Matériaux) pour le [http://www.defi-foly-laclusaz.com/ défi Foly 2015] : Didier Donsez, Pascal Jay, David Eon (2 élèves)
* [[Smart Classroom]] (avec ENSIMAG) Didier Donsez, Vivien Quema, Jérome Maisonnasse (4 élèves)
* Robot [[RobAIR]] à base de [[STM32 Nucleo]] (+ cartes additionnelles MEMS BLE4) et de téléphones [[Firefox OS]]. Didier Donsez (4 élèves)
* [[StartAIR]] (Fabrice Dubost) (2 élèves)
* [[IDS|Interactive Digitale Signage]] avec [[Reveal.js]], [[Kinect]], [[WebRTC]], [[Node.js]], [[Open Data]], [[NFC]], [[Miracast]] [http://blueimp.github.io/Bootstrap-Image-Gallery/ Bootstrap Gallery]... (Didier Donsez) (2 élèves)
* [[Régie vidéo autonome et mobile multi-caméra]] (Didier Donsez, Thierry C.) (2 élèves)
* Interface HTML5 à la [[IFTTT]] et à la [[Node-RED]] ou [[Flowhub]] pour [[OpenHAB]] (2 élèves)
* [[Intégration d'Espruino à RIOT OS]] sur [[STM32 Nucleo]]: Application à la robotique [[RobAIR]] (Didier Donsez) (2 élèves)
* [[Inventaire Forestier]] sous Android (3I4 ou 5, RICM4) Emmanuel Promayon (2 élèves)
* [[Navigation indoor basé iBeacons]], Jacques Lemordant (2 élèves)
* [[Navigation et Montre connectée]], Jacques Lemordant (2 élèves)
* [[Projets Sitra avec la région Rhône-Alpes]], Jacques Lemordant (2 élèves)
* [[CannonBall de voitures autonomes|CannonBall de voitures autonomes, Edition 2015]] Didier Donsez & Vivien Quema (piste [[Star War Drone Race]]) (2 élèves)
* [[Python sur ESP8266]] Olivier Richard (2 élèves)
* [[Serious Game: Handicap, parole et geste v2]], edition 2015, Olivier Richard (2 élèves)
* [[Plateforme d'expérimentation mini-datacentre]] édition 2015, Olivier Richard (2 élèves)

==RICM5==
===Projet Semestre S10===
Démarrage : Lundi 26/01 à 8H00-12H00, P257 (Rendez-vous devant la salle AIR)

Soutenance : Mercredi 25/03 à 9H00-12H00, Salle à confirmer

{|class="wikitable alternance"
|+ Affectation des projets RICM5 2014-2015
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[iRock]] :Plateforme Ubilitics pour la surveillance des risques naturelles (déploiement grande échelle de capteurs [[LoRa]] sur le terrain pour l'observation de glissement de terrain) .
| Peyre, Guo, Ginoux, Boey
| Didier Donsez & Denis Jongmans & Georges-Pierre Bonneau
| [[Proj-2014-2015-iRock| '''Fiche''']] [[Proj-2014-2015-iRock/SRS| '''SRS''']] [[Proj-2014-2015-iRock/UML| '''Diagrammes UML''']] [[Proj-2014-2015-iRock/Scrum| '''Scrum''']]
| [https://github.com/fpeyre/IRock_2015'''github''']
| [[Media:Proj-2014-2015-iRock-Rapport|rapport]] - [[Media:Proj-2014-2015-iRock-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-iRock-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-iRock-poster.pdf|poster]] - [[Proj-2014-2015-iRock-media.pdf|Video ou Screencast]]
|-

!scope="row"| 2
| Plateforme Ubilitics pour [[SmartCampus 2015]] : (déploiement grande échelle de capteurs [[LoRa]]) (voir [[OpenBAS]]).
| Sambe, Husson, Labat, Fréby, Barbier
| Didier Donsez & Vivien Quema
| [[Proj-2014-2015-SmartCampus2015| '''Fiche''']] [[Proj-2014-2015-SmartCampus2015/SRS| '''SRS''']] [[Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel| '''Diagrammes UML''']] [[Proj-2014-2015-SmartCampus2015#Organisation_du_projet| '''Scrum''']]
| [https://github.com/nexucis/SmartCampus '''github''']
| [[Media:Proj-2014-2015-SmartCampus2015-Rapport|rapport]] - [[Media:Proj-2014-2015-SmartCampus2015-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartCampus2015-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-SmartCampus2015-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 3
| [[Extensions XBMC Sujet 2015]]
| Valentin, Bobo, Legros, Gabin Teulon (DUT1 R&T)
| Nicolas Palix
| [[Extensions_XBMC_Sujet_2015| '''Fiche''']] [[Proj-2014-2015-Ext_XBMC/SRS| '''SRS''']] [[Proj-2014-2015-Ext_XBMC/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Ext_XBMC/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-Ext_XBMC/Rapport|rapport]] - [[Media:Proj-2014-2015-Ext_XBMC-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-Ext_XBMC-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-Ext_XBMC-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 4
| [[Smart Classroom]] : tables tactiles en mode [[Tiled Display]], Murs interactifs, Robots de Téléprésence, ...
| Benyounes, Fall, Tiamiou, Perruche, Quentin Fombaron (DUT1 R&T), Lucas Reygrobellet (DUT1 R&T)
| Didier Donsez & Vivien Quema & Jérome Maisonnasse
| [[Proj-2014-2015-SmartClassRoom| '''Fiche''']] [[Proj-2014-2015-SmartClassRoom/SRS| '''SRS''']] [[Proj-2014-2015-SmartClassRoom/UML| '''Diagrammes UML''']] [[Proj-2014-2015-SmartClassRoom/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-SmartClassRoom-Rapport|rapport]] - [[Media:Proj-2014-2015-SmartClassRoom-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassRoom-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-SmartClassRoom-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 5
| Défi H 2015 : Rééducation de la main
| Mariage, Perea, Clerc-Ghérardi, Arredondo (TIS5)
| Didier Donsez & Alessandro Semere & Nicolas Vuillerme + Pierre-Yves Thomas (tuteur Sogeti)
| '''Sur DropBox''' : [[HandTrainer| '''Fiche''']] [[HandTrainer-SRS| '''SRS''']] [[Proj-2014-2015-ReducMain/UML| '''Diagrammes UML''']] [[Proj-2014-2015-ReducMain/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-ReducMain-Rapport|rapport]] - [[Media:Proj-2014-2015-ReducMain-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassRoom-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-ReducMain-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

|}

Rappel: les séances de MPI (Management de Projet Innovant) auront lieu les jours suivants (salles sur ADE) :
* Mardi 27/01 après-midi (Stéphanie Diligent)
* Lundi 2/02 matin (Emmanuelle Tréhoust)
* Lundi 9/02 matin (Emmanuelle Tréhoust)
* Lundi 23/02 matin (Stéphanie Diligent)
* Mardi 17/03 matin (Stéphanie Diligent+Emmanuelle Tréhoust)

Remarque: il y à 3 étudiants PEIP D de l'IUT 1 R&T qui participeront aux projets.

===Projet Biométrie===
Démarrage : Lundi 26/01 à 8H00-9H45

Voir Laurent Besacier & François Portet

=3I=
==3I3==

==3I4==

==3I5==
* Carte d'extension Semtech [[LoRa]] pour [[Arduino]] et [[STM32 Nucleo]] (Didier Donsez)

===Projet Semestre 10===
Démarrage : 26/01/2015
Soutenance: 26/03/2015

{|class="wikitable alternance"
|+ Affectation des projets 3I5 2014-2015
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
!scope="col"| Docs.
|-

!scope="row"| 1
| [[Projet Cannonball - Intégration d'une caméra auto-directive| '''Projet Cannonball''']] : Intégration d'une caméra auto-directive.
| Alwan, Laurent, Cottin Bizonne
| Alina Voda & Ahmad Farhat
| [[Fiche de suivi Projet Cannonball 2015| '''Fiche de suivi''']]
| [https://github.com/Jerome-Laurent/CannonBall-Nucleo-STM32F401 '''github''']
| [[Media:Rapport_Cannonball2015.pdf‎|Rapport]] - [[Media:Poster_Project_Cannonball.pdf|Poster]] - [https://www.youtube.com/watch?v=44PW_EM8MZ0| Vidéo ]

|}

=M2PGI=
* Extensions à [[SmartCampus]]

=Bachelor Summer Program=

=Année A définir=
* [[GeoDiff]] Production, visualisation, fusion de variations (diff) sur de l'information géocodée : Nicolas Palix
* [[Smart campus augmenté et contributif]]
* [[Intégration OpenHAB / OpenTele]]
* [[Client MQTT pour OBD]] sur Android
* [[Sommeilomètre]] (Michael Perin, Didier Donsez)
* [[Open DynDNS]]
* [[IllumiRoom]]
* [[Emergency mobile app]] Nicolas Palix pour TIS, PRI et RICM
* [[OwnPOI]] ownCloud plugin and osmand plugin to share POI and favorite positions. Nicolas Palix.
* [[OwnList]] ownCloud plugin and Android app to share a TODO list. Nicolas Palix.
* [[floatingimage UPnP feed]] Nicolas Palix
* [[XBMC Reflexive Remote]] Dynamic remote control for XBMC. Nicolas Palix.
* [http://intgat.tigress.co.uk/rmy/uml/index.html Zerofree] Portage de zerofree pour d'autres systèmes de fichiers que ext2/3/4 (notamment Unix FS). Voir également la page [http://packages.qa.debian.org/z/zerofree.html QA de Debian]. Nicolas Palix.
* [[Bracelet électronique de monitoriing de l'alcoolémie]]
* [[Oxymètre DIY]]
* [[PinSound]]
* [[Extension du support STM32Fx-Discovery dans libopencm3]] : Olivier Richard
* [[Arduino et libopencm3]] : Olivier Richard
* [[Data Acquisition System et Stm32f4-Discovery]] : Olivier Richard
* [[Distributed Data Storage System]] : Olivier Richard
* [[Dashboard based on w2ui]]
* [[Environnement logiciel pour FabLab]] : Olivier Richard
* [[Environnement logiciel pour le Live Programming]] : Olivier Richard
* [[VirtualPinball]]
* Tondeuse dessinatrice
* [[ImmersiveDog]] Nicolas Glade, Didier Donsez
* Projet avec [[OpenROV]] ???? : Didier Donsez
* [[Sphero]] malin (Michael Périn) (2 etudiants)
* [[Drone paramoteur]] ???
* [[IRock : Surveillance Géotechnique LoRa|iRock]]: Plateforme Ubilitics pour la surveillance des risques naturelles (déploiement grande échelle de capteurs [[LoRa]] sur le terrain pour l'observation de glissement de terrain) en commun avec Geotech (à confirmer) : Didier Donsez & Denis Jongmans
* [[Optimisation de l'énergie pour cyclotouriste électrique]]
* [[SmartSelfService|Smart Self-Service 2015]] Didier Donsez & Vivien Quema
* [[Station Météo LoRa]] : contribution au projet [[LoRA-Fabian]] (Didier Donsez)

=Réserve (boite à idées)=

# [[Tag et Paint Ball en réalité augmentée]] (Michaël Périn)
# [[Passe moi ton fichier]] (Michaël Périn)
# [[Extensions à Fab Server]] (Jean-Michel Molenaar) sous reserve (CM ou SR)
# [[Table multijeux de café 2.0]]
# [[ GPIO_Qemu_RasPI| Emulation des GPIO dans QEMU pour le carte Raspberry Pi]] (Olivier Richard)
# [[ Qemu et STM32F0-Discovery ]] (Olivier Richard)
# [[Serrure à clé MIDI multifactorielle]] (Didier Donsez)
# [[Table interactive musicale]] (Didier Donsez)
# [[iMailbox]] (Didier Donsez)
# [[AmILight]] (eclairage d'ambience intelligent) (Didier Donsez)
# [[PDAmeetPDA]] (synchronisation d'agenda) (Michaël Périn)
# [[1 000 000 VMs]] (expérimentation d'application distribuée à très grande échelle) (Olivier Richard) (2-3 RICM4)
# [[Multiple Kinect]] (utilisation simultanée de plusieurs Kinect) (Olivier Richard) (RICM ou 3I)
# [[Kinect musicale]] (Didier Donsez) (RICM)
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# Ocaml on AVR (Arduino)
# Ocaml on Cortex-M3
# [[Arduino on STM32 Discovery]]
# [[Reverse Geocache Puzzle Box]]
# [[OSGi ME]] (Didier Donsez)
# [[Affichage Etudiant à Polytech]]
# Synthèse 3D + motion capture Kinect
# Logiciel d'[[apprentissage du calcul]] sur tablette Android (reconnaissance de chiffres manuscrits)
# Plancher de verre (saint gobain) à la [http://www.wat.tv/video/mickael-jackson-billie-jean-oewj_2ey2h_.html Mickael Jackson dans Billie Jean] ! woo
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# [[CNC]]
# [[Idées en Vrac]]
# Scheme Everywhere (Olivier Richard) (2-3 RICM4-SR)
# [[Projet Station Météo]]
# Ocaml on AVR (Arduino)
# [[Table interactive musicale]] (Didier Donsez)
# [[AmILight]] (eclairage d'amnbience intelligent) (Didier Donsez)
# [[Cube pointeur]] d'activité ingénieur
# [http://www.instructables.com/id/Puppeteer-Motion-Capture-Costume/ Puppeteer Motion-Capture Costume]
# [[Musical Staircase]] @ Polytech (Didier Donsez, 1 RICM4 + 1 3I4)
# [[Total Recall]] (Didier Donsez)
# [[SoundMachine]]
# [[IGN-OSM|Importation de données IGN publiques dans OSM]]
# [[Speed-limit-OSM|Analyse de traces GPX pour déterminer les limitations de vitesse]]
# [[Multi perceptual cameras]] (Didier Donsez)
# [[Photomaton 3D]] (Didier Donsez)
# [[ArduCopter]]
# [[Parking Intelligent]]

File:Proj-2014-2015-iRock-transparents.pdf

2015-03-25T08:24:20Z

RICM4-prj14-grp9:

Proj-2014-2015-iRock

2015-03-25T08:20:34Z

RICM4-prj14-grp9: /* Triangulation */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière geotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' :
*''' Répertoire Github''':
*'''Diagrammes UML''':
*'''Scrum""":

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combiné à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie).Notre objectif est aussi de minimiser le cout de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un systéme d'export en fichier Excel à été mis en place ,pour avoir accés simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit ete réaliser au milimétre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimétre).Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ juste que nous devions utiliser la technologie LoRA pour les communications.Mais plusieurs cartes embarqué pouvait permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisé fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accélérométres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoit un message dés qu'elle est en mouvement).Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium etaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech ,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement concue pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA éffectué, il nous faut choisir nos cartes de capteurs. Nous avons optés pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétométre ou accélérométre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisé===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal probléme rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothéque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus ,aprés présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son cout, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduinos
===Technologie utilisé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problémes rencontrés===
Le principale probléme rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5à% ,...)dés que nous branchions la mbed LoRA en plus, larte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s'avére que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et ecriture des scrypts python pour transmettre les données de la mbed de recption au pc de reception (par le port serial), du pc recepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une achine Amazon
===Technologie utilisé===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problémes rencontrés dans cette partie. On utilise un systeme de requette html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets json à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
===Technologie utilisé===
Python
===Problèmes rencontrés===
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initales du projet:

=Conclusion générale/ Perspective d'évolution=

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Proj-2014-2015-iRock

2015-03-25T08:03:15Z

RICM4-prj14-grp9: /* Serveur */

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière geotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' :
*''' Répertoire Github''':
*'''Diagrammes UML''':
*'''Scrum""":

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combiné à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie).Notre objectif est aussi de minimiser le cout de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un systéme d'export en fichier Excel à été mis en place ,pour avoir accés simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit ete réaliser au milimétre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimétre).Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ juste que nous devions utiliser la technologie LoRA pour les communications.Mais plusieurs cartes embarqué pouvait permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisé fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accélérométres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoit un message dés qu'elle est en mouvement).Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium etaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech ,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement concue pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA éffectué, il nous faut choisir nos cartes de capteurs. Nous avons optés pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétométre ou accélérométre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisé===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal probléme rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothéque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus ,aprés présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son cout, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduinos
===Technologie utilisé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problémes rencontrés===
Le principale probléme rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5à% ,...)dés que nous branchions la mbed LoRA en plus, larte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s'avére que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et ecriture des scrypts python pour transmettre les données de la mbed de recption au pc de reception (par le port serial), du pc recepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une achine Amazon
===Technologie utilisé===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
Pas de problémes rencontrés dans cette partie. On utilise un systeme de requette html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets json à envoyer au serveur (notamment le fait que les string doivent etre entourré de "

==Triangulation==
===Objectif:===
===Technologie utilisé===
===Problémes rencontrés===
=Conclusion générale/ Perspective d'évolution=

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Proj-2014-2015-iRock

2015-03-25T05:53:17Z

RICM4-prj14-grp9: Une fois le choix de la carte pour LoRA éfféctué, il nous faut choisir no

= Introduction =

Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences en géotechnique et en informatique, notamment en visualisation de données.

= Team =

Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière geotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier.
Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat).
Le coordinateur pour ce projet sera Peyre Flavien.

Département : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Links =
* '''Notre SRS''' :
*''' Répertoire Github''':
*'''Diagrammes UML''':
*'''Scrum""":

= Objectifs=
==Partie capteur et acquisition de données==

Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combiné à d'autres cartes embarquées bardée de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation.Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie).Notre objectif est aussi de minimiser le cout de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
==Partie visualisation / stockage des données==

Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un systéme d'export en fichier Excel à été mis en place ,pour avoir accés simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)

==Partie triangulation / localisation des IRock==
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit ete réaliser au milimétre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimétre).Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique

=Architecture générale=

==IRock==
===Objectif:===
Cette partie est la base de notre projet.Nous savions au départ juste que nous devions utiliser la technologie LoRA pour les communications.Mais plusieurs cartes embarqué pouvait permettre d'utiliser cette technologie. Un autre objectif été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
La première carte utilisé fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accélérométres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoit un message dés qu'elle est en mouvement).Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium etaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser
Enfin nous avons utilisé les cartes mbed LoRA de semtech ,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement concue pour Arduino sur STM32.
Une fois le choix de la carte pour LoRA éffectué, il nous faut choisir nos cartes de capteurs. Nous avons optés pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétométre ou accélérométre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

===Technologie utilisé===
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
===Problèmes rencontrés===
Le principal probléme rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothéque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled.De plus ,aprés présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible)
==Relais==
===Objectif:===
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité , le vent et pluviométrie.la carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son cout, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduinos
===Technologie utilisé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problémes rencontrés===
Le principale probléme rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5à% ,...)dés que nous branchions la mbed LoRA en plus, larte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s'avére que vers la fin du projet ,nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
==Serveur==
===Objectif:===
===Technologie utilisé===
===Problémes rencontrés===
==Triangulation==
===Objectif:===
===Technologie utilisé===
===Problémes rencontrés===
=Conclusion générale/ Perspective d'évolution=

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 26th - Janurary 30th) ==
*Project discovery
*Technologies and sensors discovery
*Meeting with tutors and tearchers to define the project

Proj-2014-2015-iRock

2015-03-25T05:00:51Z

RICM4-prj14-grp9: /* Project objectives */

Proj-2014-2015-iRock

2015-03-25T04:44:38Z

RICM4-prj14-grp9: /* Links */

File:IRockExcel.png

2015-03-23T18:14:10Z

RICM4-prj14-grp9:

Proj-2014-2015-iRock/SRS

2015-03-23T13:50:58Z

RICM4-prj14-grp9: /* 5.2 Sources */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the IRock project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data. He want have files of data to reuse it

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard internet browser
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*The area where rock are left must stay the same

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers (discovery board)
** Mbed compiler to debug and flash micro-controllers (nucleo board)
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend
* Add a system to dowload the Excel File from an internet browser

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* SmartCampus 2015 group for LoRA

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:49:56Z

RICM4-prj14-grp9: /* 4. Product evolution */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the IRock project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data. He want have files of data to reuse it

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard internet browser
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*The area where rock are left must stay the same

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers (discovery board)
** Mbed compiler to debug and flash micro-controllers (nucleo board)
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend
* Add a system to dowload the Excel File from an internet browser

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:48:53Z

RICM4-prj14-grp9: (

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the IRock project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data. He want have files of data to reuse it

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard internet browser
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*The area where rock are left must stay the same

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers (discovery board)
** Mbed compiler to debug and flash micro-controllers (nucleo board)
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:47:22Z

RICM4-prj14-grp9: /* 2.5 Assumptions and dependencies */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the IRock project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data. He want have files of data to reuse it

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard internet browser
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*The area where rock are left must stay the same

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:46:29Z

RICM4-prj14-grp9: /* 2.4 General constraints */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the IRock project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data. He want have files of data to reuse it

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard internet browser
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:45:50Z

RICM4-prj14-grp9: /* 2.3 User characteristics */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the IRock project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data. He want have files of data to reuse it

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:44:18Z

RICM4-prj14-grp9: /* 1.5 Overview of the remainder of the document */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the IRock project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:43:22Z

RICM4-prj14-grp9: /* 1.4 References */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:42:50Z

RICM4-prj14-grp9: /* 1.4 References */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[IRock Sujet 2015]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T13:42:09Z

RICM4-prj14-grp9: /* 1.2 Scope of the product */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* We can calculate the position of sensor by triangulation with signal radio strength

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[Extensions XBMC Sujet 2015]]
*Last year project : [[Extensions XBMC Sujet 2014]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=5. Appendices=
==5.1. SRS structure==
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
'''References:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Projets 2014-2015

2015-03-23T10:17:14Z

RICM4-prj14-grp9: /* Projet Semestre S10 */

<<[[Projets 2013-2014]] [[Projets|^Projets^]] [[Projets 2015-2016]]>>

=RICM=
==RICM3==

==RICM4==

* '''Evaluation à mi-parcours le lundi 2 mars''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: vous creusez la question, vous contactez l'auteur du code si il y a lieux, vous faites un rapport de bug ('''Attention:''' ca se prépare !), vous soumettez un patch, vous contactez l'enseignant ou la personne suivant le projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle
indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par ricm4_2014_2015.

* '''Vous devez utiliser un logiciel de gestion de version''' pour vos développements comme [http://en.wikipedia.org/wiki/Git_%28software%29 git ] et nous vous conseillons d'utiliser le site [https://github.com github] pour l'hébergement de votre dépôt public.

* Les document public (exemple sur github) doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

{|class="wikitable alternance"
|+ Affectation des projets RICM4 2014-2015
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[Projet de monoski intelligent]]
| Blondet, Torck
| Didier Donsez, Pascal Jay, David Eon
| [[Proj-2014-2015-MonoskiIntelligent| '''Fiche''']] [[Proj-2014-2015-MonoskiIntelligent/SRS| '''SRS''']]==== Sprint 5 ====
----
Sprint Duration
===== Sprint goals =====

===== Sprint Backlog =====
[[Proj-2014-2015-MonoskiIntelligent/UML| '''Diagrammes UML''']] [[Proj-2014-2015-MonoskiIntelligent/Scrum| '''Scrum''']] ([https://waffle.io/quentin74/monoski Waffle])
| [https://github.com/quentin74/application-monoski '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 2
| [[Smart Classroom]]
| Darrigol, Badamo, Damotte, Leonard
| Didier Donsez, Vivien Quema, Jérome Maisonnasse
| [[Proj-2014-2015-SmartClassroom| '''Fiche''']] [[Proj-2014-2015-SmartClassroom/SRS| '''SRS''']] [[Proj-2014-2015-SmartClassroom/UML| '''Diagrammes UML''']] [[Proj-2014-2015-SmartClassroom/Scrum| '''Scrum''']]
| [https://github.com/AlanDamotte/auth '''github''']
| [[Media:Proj-2014-2015-SmartClassroom/Rapport|rapport]] - [[Media:Proj-2014-2015-SmartClassroom-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassroom-flyer.pdf|flyer]] [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 3
| [[RobAIR]] et [[STM32 Nucleo]]
| Hammerer, Michel, Klipffel, Viallet **
| Didier Donsez
| [[Projet-2014-2015-RobAIR| '''Fiche''']] [[Projet-2014-2015-RobAIR/SRS| '''SRS''']] [[Projet-2014-2015-RobAIR/UML| '''Diagrammes UML''']] [[Projet-2014-2015-RobAIR/Scrum| '''Scrum''']]
| [https://github.com/teiroy/RobAIR '''github''']
| [[Media:Projet-2014-2015-RobAIR/Rapport|rapport]] - [[Media:Projet-2014-2015-RobAIR-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] [[Media:Projet-2014-2015-RobAIR-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 4
| [[IDS|Interactive Digitale Signage]]
| Adam, Zhang
| Didier Donsez
| [[Proj-2014-2015-Interactive_Digitale_Signage| '''Fiche''']] [[Projet-2014-2015-Interactive_Digitale_Signage/SRS| '''SRS''']] [[Projet-2014-2015-Interactive_Digitale_Signage/UML| '''Diagrammes UML''']] [[Projet-2014-2015-Interactive_Digitale_Signage/Scrum| '''Scrum''']]
| [https://github.com/zhangzhengmeng/ProjetIDS2015.git '''github''']
| [[Media:Proj-2014-2015-Interactive_Digitale_Signage/Rapport|rapport]] - [[Media:Proj-2014-2015-Interactive_Digitale_Signage-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-Interactive_Digitale_Signage-flyer.pdf|flyer]] [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 5
| [[Régie vidéo autonome et mobile multi-caméra]]
| Zominy, Bodard, Qian
| Didier Donsez, Thierry C.
| [[Proj-2014-2015-RegieVideoAutonomeEtMobileMulticamera| '''Fiche''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/SRS| '''SRS''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/Scrum| '''Scrum''']]
| [https://github.com/kurisuter/Regie-video-autonome-'''github''']
| [[Media:Projet-2014-2015-RegieVideoAutonomeEtMobileMulticamera/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 6
| OpenHAB Extended GUI ([[IFTTT]] et à la [[Node-RED]] ou [[Flowhub]] pour [[OpenHAB]], Découverte [[UPnP]] des équipements)
| Toussaint, Saussac
| Didier Donsez
| [[Proj-2014-2015-OpenHAB-ExtendedGUI| '''Fiche''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/SRS| '''SRS''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/UML| '''Diagrammes UML''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/Scrum| '''Scrum''']]
| [https://github.com/saussact/projet '''github''']
| [[Media:Proj-2014-2015-OpenHAB-ExtendedGUI/Rapport|rapport]] - [[Media:Proj-2014-2015-OpenHAB-ExtendedGUI-transparents.pdf|transparents]] - [[Media:PProj-2014-2015-OpenHAB-ExtendedGUI-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 7
| [[CannonBall de voitures autonomes|CannonBall de voitures autonomes, Edition 2015]]
| Le-Jean, Mammar, Pelloux-Prayer, Rodrigues
| Didier Donsez & Vivien Quema
| [[Project-2014-2015-CannonBall| '''Fiche''']][[Project 2014-2015-CannonBall/SRS| '''SRS''']][[Project 2014-2015-CannonBall/UML| '''UML''']][[Project 2014-2015-CannonBall/Scrum| '''Scrum''']][[Project 2014-2015-CannonBall/DesignPatterns| '''DesignPatterns''']]
| [https://github.com/malek0512/2014_2015_ricm4_cannon_ball '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 8
| [[Navigation et Montre connectée]]
| Hamdani, Mesnier, Yao
| Jacques Lemordant
| [[Proj-2014-2015-Montreconnectée| '''Fiche''']] [[Proj-2014-2015-Montreconnectée/SRS| '''SRS''']] [[Proj-2014-2015-Montreconnectée/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Montreconnectée/Scrum| '''Scrum''']][[Proj-2014-2015-Montreconnectée/DesignPattern| '''DesignPattern''']]
| [https://github.com/vince0508/MontreConnectee '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 9
| [[Python sur ESP8266]]
| Libralesso, Soldano
| Olivier Richard
| [[Project-2014-2015-ESP8266| '''Fiche''']] - [[Proj-2014-2015-ESP8266/SRS| '''SRS''']] - [[Proj-2014-2015-ESP8266/UML| '''UML diagrams''']] - [[Proj-2014-2015-ESP8266/Scrum| '''Scrum''']]
| [https://github.com/librallu/RICM4Projet/ '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast] - [http://librallu.github.io/RICM4Projet/ '''website''']
|-

!scope="row"| 10
| [[Serious Game: Handicap, parole et geste v2]]
| Aissanou, Codazzi, Guo
| Olivier Richard
| [[Proj-2014-2015-SeriousGamev2| '''Fiche''']][[Proj-2014-2015-SeriousGamev2/SRS| '''SRS''']][[Proj-2014-2015-SeriousGamev2/Scrum| '''Scrum''']] [[Projet-2014-2015-SeriousGamev2/Diagrammes| '''Diagrammes UML''']]
| [https://github.com/wizardkeven/SeriousGameV2 '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 11
| [[Plateforme d'expérimentation mini-datacentre]] Système
| Fotsing, Morison
| Olivier Richard
| [[Proj-2014-2015-Mini_DataCenter_Systeme| '''Fiche''']][[Proj-2014-2015-Mini_datacenter_Systeme_SRS| '''SRS''']] [[Proj-2014-2015-Mini_datacenter_Systeme_scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:ProjetMini_DataCenter_Systeme/Rapport|rapport]] - [[Media:ProjetMini_DataCenter_Systeme-transparents.pdf|transparents]] - [[Media:ProjetMini_DataCenter_Systeme-flyer.pdf|flyer]]- [[Media:ProjetMini_DataCenter_Systeme-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 12
| [[Plateforme d'expérimentation mini-datacentre]] Portail
| Rossi, Eudes
| Olivier Richard
| [[Proj-2014-2015-Mini_datacenter_portail| '''Fiche''']] [[Proj-2014-2015-Mini_datacenter_portail_SRS| '''SRS''']] [[Proj-2014-2015-Mini_datacenter_portail_scrum| '''Scrum''']] [[Proj-2014-2015-Mini_datacenter_portail_uml| '''UML''']]
| [https://github.com/EudesRobin/webui-oardocker '''github''']
| [[Media:Projet_Projet_Mini_datacenter_portail/Rapport|rapport]] - [[Media:Projet_Mini_datacenter_portail-transparents.pdf|transparents]] - [[Media:Projet_Mini_datacenter_portail-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

|}

* [[Projet de monoski intelligent]] (RICM4 et 3I4 et Matériaux) pour le [http://www.defi-foly-laclusaz.com/ défi Foly 2015] : Didier Donsez, Pascal Jay, David Eon (2 élèves)
* [[Smart Classroom]] (avec ENSIMAG) Didier Donsez, Vivien Quema, Jérome Maisonnasse (4 élèves)
* Robot [[RobAIR]] à base de [[STM32 Nucleo]] (+ cartes additionnelles MEMS BLE4) et de téléphones [[Firefox OS]]. Didier Donsez (4 élèves)
* [[StartAIR]] (Fabrice Dubost) (2 élèves)
* [[IDS|Interactive Digitale Signage]] avec [[Reveal.js]], [[Kinect]], [[WebRTC]], [[Node.js]], [[Open Data]], [[NFC]], [[Miracast]] [http://blueimp.github.io/Bootstrap-Image-Gallery/ Bootstrap Gallery]... (Didier Donsez) (2 élèves)
* [[Régie vidéo autonome et mobile multi-caméra]] (Didier Donsez, Thierry C.) (2 élèves)
* Interface HTML5 à la [[IFTTT]] et à la [[Node-RED]] ou [[Flowhub]] pour [[OpenHAB]] (2 élèves)
* [[Intégration d'Espruino à RIOT OS]] sur [[STM32 Nucleo]]: Application à la robotique [[RobAIR]] (Didier Donsez) (2 élèves)
* [[Inventaire Forestier]] sous Android (3I4 ou 5, RICM4) Emmanuel Promayon (2 élèves)
* [[Navigation indoor basé iBeacons]], Jacques Lemordant (2 élèves)
* [[Navigation et Montre connectée]], Jacques Lemordant (2 élèves)
* [[Projets Sitra avec la région Rhône-Alpes]], Jacques Lemordant (2 élèves)
* [[CannonBall de voitures autonomes|CannonBall de voitures autonomes, Edition 2015]] Didier Donsez & Vivien Quema (piste [[Star War Drone Race]]) (2 élèves)
* [[Python sur ESP8266]] Olivier Richard (2 élèves)
* [[Serious Game: Handicap, parole et geste v2]], edition 2015, Olivier Richard (2 élèves)
* [[Plateforme d'expérimentation mini-datacentre]] édition 2015, Olivier Richard (2 élèves)

==RICM5==
===Projet Semestre S10===
Démarrage : Lundi 26/01 à 8H00-12H00, P257 (Rendez-vous devant la salle AIR)

Soutenance : Mercredi 25/03 à 9H00-12H00, Salle à confirmer

{|class="wikitable alternance"
|+ Affectation des projets RICM5 2014-2015
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[iRock]] :Plateforme Ubilitics pour la surveillance des risques naturelles (déploiement grande échelle de capteurs [[LoRa]] sur le terrain pour l'observation de glissement de terrain) .
| Peyre, Guo, Ginoux, Boey
| Didier Donsez & Denis Jongmans & Georges-Pierre Bonneau
| [[Proj-2014-2015-iRock| '''Fiche''']] [[Proj-2014-2015-iRock/SRS| '''SRS''']] [[Proj-2014-2015-iRock/UML| '''Diagrammes UML''']] [[Proj-2014-2015-iRock/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-iRock-Rapport|rapport]] - [[Media:Proj-2014-2015-iRock-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-iRock-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-iRock-poster.pdf|poster]] - [[Proj-2014-2015-iRock-media.pdf|Video ou Screencast]]
|-

!scope="row"| 2
| Plateforme Ubilitics pour [[SmartCampus 2015]] : (déploiement grande échelle de capteurs [[LoRa]]) (voir [[OpenBAS]]).
| Sambe, Husson, Labat, Fréby, Barbier
| Didier Donsez & Vivien Quema
| [[Proj-2014-2015-SmartCampus2015| '''Fiche''']] [[Proj-2014-2015-SmartCampus2015/SRS| '''SRS''']] [[Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel| '''Diagrammes UML''']] [[Proj-2014-2015-SmartCampus2015#Organisation_du_projet| '''Scrum''']]
| [https://github.com/nexucis/SmartCampus '''github''']
| [[Media:Proj-2014-2015-SmartCampus2015-Rapport|rapport]] - [[Media:Proj-2014-2015-SmartCampus2015-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartCampus2015-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-SmartCampus2015-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 3
| [[Extensions XBMC Sujet 2015]]
| Valentin, Bobo, Legros, Gabin Teulon (DUT1 R&T)
| Nicolas Palix
| [[Extensions_XBMC_Sujet_2015| '''Fiche''']] [[Proj-2014-2015-Ext_XBMC/SRS| '''SRS''']] [[Proj-2014-2015-Ext_XBMC/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Ext_XBMC/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-Ext_XBMC/Rapport|rapport]] - [[Media:Proj-2014-2015-Ext_XBMC-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-Ext_XBMC-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-Ext_XBMC-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 4
| [[Smart Classroom]] : tables tactiles en mode [[Tiled Display]], Murs interactifs, Robots de Téléprésence, ...
| Benyounes, Fall, Tiamiou, Perruche, Quentin Fombaron (DUT1 R&T), Lucas Reygrobellet (DUT1 R&T)
| Didier Donsez & Vivien Quema & Jérome Maisonnasse
| [[Proj-2014-2015-SmartClassRoom| '''Fiche''']] [[Proj-2014-2015-SmartClassRoom/SRS| '''SRS''']] [[Proj-2014-2015-SmartClassRoom/UML| '''Diagrammes UML''']] [[Proj-2014-2015-SmartClassRoom/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-SmartClassRoom-Rapport|rapport]] - [[Media:Proj-2014-2015-SmartClassRoom-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassRoom-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-SmartClassRoom-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 5
| Défi H 2015 : Rééducation de la main
| Mariage, Perea, Clerc-Ghérardi, Arredondo (TIS5)
| Didier Donsez & Alessandro Semere & Nicolas Vuillerme + Pierre-Yves Thomas (tuteur Sogeti)
| '''Sur DropBox''' : [[HandTrainer| '''Fiche''']] [[HandTrainer-SRS| '''SRS''']] [[Proj-2014-2015-ReducMain/UML| '''Diagrammes UML''']] [[Proj-2014-2015-ReducMain/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-ReducMain-Rapport|rapport]] - [[Media:Proj-2014-2015-ReducMain-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassRoom-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-ReducMain-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

|}

Rappel: les séances de MPI (Management de Projet Innovant) auront lieu les jours suivants (salles sur ADE) :
* Mardi 27/01 après-midi (Stéphanie Diligent)
* Lundi 2/02 matin (Emmanuelle Tréhoust)
* Lundi 9/02 matin (Emmanuelle Tréhoust)
* Lundi 23/02 matin (Stéphanie Diligent)
* Mardi 17/03 matin (Stéphanie Diligent+Emmanuelle Tréhoust)

Remarque: il y à 3 étudiants PEIP D de l'IUT 1 R&T qui participeront aux projets.

===Projet Biométrie===
Démarrage : Lundi 26/01 à 8H00-9H45

Voir Laurent Besacier & François Portet

=3I=
==3I3==

==3I4==

==3I5==
* Carte d'extension Semtech [[LoRa]] pour [[Arduino]] et [[STM32 Nucleo]] (Didier Donsez)

=M2PGI=
* Extensions à [[SmartCampus]]

=Bachelor Summer Program=

=Année A définir=
* [[GeoDiff]] Production, visualisation, fusion de variations (diff) sur de l'information géocodée : Nicolas Palix
* [[Smart campus augmenté et contributif]]
* [[Intégration OpenHAB / OpenTele]]
* [[Client MQTT pour OBD]] sur Android
* [[Sommeilomètre]] (Michael Perin, Didier Donsez)
* [[Open DynDNS]]
* [[IllumiRoom]]
* [[Emergency mobile app]] Nicolas Palix pour TIS, PRI et RICM
* [[OwnPOI]] ownCloud plugin and osmand plugin to share POI and favorite positions. Nicolas Palix.
* [[OwnList]] ownCloud plugin and Android app to share a TODO list. Nicolas Palix.
* [[floatingimage UPnP feed]] Nicolas Palix
* [[XBMC Reflexive Remote]] Dynamic remote control for XBMC. Nicolas Palix.
* [http://intgat.tigress.co.uk/rmy/uml/index.html Zerofree] Portage de zerofree pour d'autres systèmes de fichiers que ext2/3/4 (notamment Unix FS). Voir également la page [http://packages.qa.debian.org/z/zerofree.html QA de Debian]. Nicolas Palix.
* [[Bracelet électronique de monitoriing de l'alcoolémie]]
* [[Oxymètre DIY]]
* [[PinSound]]
* [[Extension du support STM32Fx-Discovery dans libopencm3]] : Olivier Richard
* [[Arduino et libopencm3]] : Olivier Richard
* [[Data Acquisition System et Stm32f4-Discovery]] : Olivier Richard
* [[Distributed Data Storage System]] : Olivier Richard
* [[Dashboard based on w2ui]]
* [[Environnement logiciel pour FabLab]] : Olivier Richard
* [[Environnement logiciel pour le Live Programming]] : Olivier Richard
* [[VirtualPinball]]
* Tondeuse dessinatrice
* [[ImmersiveDog]] Nicolas Glade, Didier Donsez
* Projet avec [[OpenROV]] ???? : Didier Donsez
* [[Sphero]] malin (Michael Périn) (2 etudiants)
* [[Drone paramoteur]] ???
* [[IRock : Surveillance Géotechnique LoRa|iRock]]: Plateforme Ubilitics pour la surveillance des risques naturelles (déploiement grande échelle de capteurs [[LoRa]] sur le terrain pour l'observation de glissement de terrain) en commun avec Geotech (à confirmer) : Didier Donsez & Denis Jongmans
* [[Optimisation de l'énergie pour cyclotouriste électrique]]
* [[SmartSelfService|Smart Self-Service 2015]] Didier Donsez & Vivien Quema
* [[Station Météo LoRa]] : contribution au projet [[LoRA-Fabian]] (Didier Donsez)

=Réserve (boite à idées)=

# [[Tag et Paint Ball en réalité augmentée]] (Michaël Périn)
# [[Passe moi ton fichier]] (Michaël Périn)
# [[Extensions à Fab Server]] (Jean-Michel Molenaar) sous reserve (CM ou SR)
# [[Table multijeux de café 2.0]]
# [[ GPIO_Qemu_RasPI| Emulation des GPIO dans QEMU pour le carte Raspberry Pi]] (Olivier Richard)
# [[ Qemu et STM32F0-Discovery ]] (Olivier Richard)
# [[Serrure à clé MIDI multifactorielle]] (Didier Donsez)
# [[Table interactive musicale]] (Didier Donsez)
# [[iMailbox]] (Didier Donsez)
# [[AmILight]] (eclairage d'ambience intelligent) (Didier Donsez)
# [[PDAmeetPDA]] (synchronisation d'agenda) (Michaël Périn)
# [[1 000 000 VMs]] (expérimentation d'application distribuée à très grande échelle) (Olivier Richard) (2-3 RICM4)
# [[Multiple Kinect]] (utilisation simultanée de plusieurs Kinect) (Olivier Richard) (RICM ou 3I)
# [[Kinect musicale]] (Didier Donsez) (RICM)
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# Ocaml on AVR (Arduino)
# Ocaml on Cortex-M3
# [[Arduino on STM32 Discovery]]
# [[Reverse Geocache Puzzle Box]]
# [[OSGi ME]] (Didier Donsez)
# [[Affichage Etudiant à Polytech]]
# Synthèse 3D + motion capture Kinect
# Logiciel d'[[apprentissage du calcul]] sur tablette Android (reconnaissance de chiffres manuscrits)
# Plancher de verre (saint gobain) à la [http://www.wat.tv/video/mickael-jackson-billie-jean-oewj_2ey2h_.html Mickael Jackson dans Billie Jean] ! woo
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# [[CNC]]
# [[Idées en Vrac]]
# Scheme Everywhere (Olivier Richard) (2-3 RICM4-SR)
# [[Projet Station Météo]]
# Ocaml on AVR (Arduino)
# [[Table interactive musicale]] (Didier Donsez)
# [[AmILight]] (eclairage d'amnbience intelligent) (Didier Donsez)
# [[Cube pointeur]] d'activité ingénieur
# [http://www.instructables.com/id/Puppeteer-Motion-Capture-Costume/ Puppeteer Motion-Capture Costume]
# [[Musical Staircase]] @ Polytech (Didier Donsez, 1 RICM4 + 1 3I4)
# [[Total Recall]] (Didier Donsez)
# [[SoundMachine]]
# [[IGN-OSM|Importation de données IGN publiques dans OSM]]
# [[Speed-limit-OSM|Analyse de traces GPX pour déterminer les limitations de vitesse]]
# [[Multi perceptual cameras]] (Didier Donsez)
# [[Photomaton 3D]] (Didier Donsez)
# [[ArduCopter]]
# [[Parking Intelligent]]

Projets 2014-2015

2015-03-23T10:15:58Z

RICM4-prj14-grp9: /* Projet Semestre S10 */

<<[[Projets 2013-2014]] [[Projets|^Projets^]] [[Projets 2015-2016]]>>

=RICM=
==RICM3==

==RICM4==

* '''Evaluation à mi-parcours le lundi 2 mars''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: vous creusez la question, vous contactez l'auteur du code si il y a lieux, vous faites un rapport de bug ('''Attention:''' ca se prépare !), vous soumettez un patch, vous contactez l'enseignant ou la personne suivant le projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle
indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par ricm4_2014_2015.

* '''Vous devez utiliser un logiciel de gestion de version''' pour vos développements comme [http://en.wikipedia.org/wiki/Git_%28software%29 git ] et nous vous conseillons d'utiliser le site [https://github.com github] pour l'hébergement de votre dépôt public.

* Les document public (exemple sur github) doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

{|class="wikitable alternance"
|+ Affectation des projets RICM4 2014-2015
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[Projet de monoski intelligent]]
| Blondet, Torck
| Didier Donsez, Pascal Jay, David Eon
| [[Proj-2014-2015-MonoskiIntelligent| '''Fiche''']] [[Proj-2014-2015-MonoskiIntelligent/SRS| '''SRS''']]==== Sprint 5 ====
----
Sprint Duration
===== Sprint goals =====

===== Sprint Backlog =====
[[Proj-2014-2015-MonoskiIntelligent/UML| '''Diagrammes UML''']] [[Proj-2014-2015-MonoskiIntelligent/Scrum| '''Scrum''']] ([https://waffle.io/quentin74/monoski Waffle])
| [https://github.com/quentin74/application-monoski '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 2
| [[Smart Classroom]]
| Darrigol, Badamo, Damotte, Leonard
| Didier Donsez, Vivien Quema, Jérome Maisonnasse
| [[Proj-2014-2015-SmartClassroom| '''Fiche''']] [[Proj-2014-2015-SmartClassroom/SRS| '''SRS''']] [[Proj-2014-2015-SmartClassroom/UML| '''Diagrammes UML''']] [[Proj-2014-2015-SmartClassroom/Scrum| '''Scrum''']]
| [https://github.com/AlanDamotte/auth '''github''']
| [[Media:Proj-2014-2015-SmartClassroom/Rapport|rapport]] - [[Media:Proj-2014-2015-SmartClassroom-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassroom-flyer.pdf|flyer]] [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 3
| [[RobAIR]] et [[STM32 Nucleo]]
| Hammerer, Michel, Klipffel, Viallet **
| Didier Donsez
| [[Projet-2014-2015-RobAIR| '''Fiche''']] [[Projet-2014-2015-RobAIR/SRS| '''SRS''']] [[Projet-2014-2015-RobAIR/UML| '''Diagrammes UML''']] [[Projet-2014-2015-RobAIR/Scrum| '''Scrum''']]
| [https://github.com/teiroy/RobAIR '''github''']
| [[Media:Projet-2014-2015-RobAIR/Rapport|rapport]] - [[Media:Projet-2014-2015-RobAIR-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] [[Media:Projet-2014-2015-RobAIR-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 4
| [[IDS|Interactive Digitale Signage]]
| Adam, Zhang
| Didier Donsez
| [[Proj-2014-2015-Interactive_Digitale_Signage| '''Fiche''']] [[Projet-2014-2015-Interactive_Digitale_Signage/SRS| '''SRS''']] [[Projet-2014-2015-Interactive_Digitale_Signage/UML| '''Diagrammes UML''']] [[Projet-2014-2015-Interactive_Digitale_Signage/Scrum| '''Scrum''']]
| [https://github.com/zhangzhengmeng/ProjetIDS2015.git '''github''']
| [[Media:Proj-2014-2015-Interactive_Digitale_Signage/Rapport|rapport]] - [[Media:Proj-2014-2015-Interactive_Digitale_Signage-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-Interactive_Digitale_Signage-flyer.pdf|flyer]] [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 5
| [[Régie vidéo autonome et mobile multi-caméra]]
| Zominy, Bodard, Qian
| Didier Donsez, Thierry C.
| [[Proj-2014-2015-RegieVideoAutonomeEtMobileMulticamera| '''Fiche''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/SRS| '''SRS''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Regie_Video_Autonome_Et_Mobile_Multicamera/Scrum| '''Scrum''']]
| [https://github.com/kurisuter/Regie-video-autonome-'''github''']
| [[Media:Projet-2014-2015-RegieVideoAutonomeEtMobileMulticamera/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 6
| OpenHAB Extended GUI ([[IFTTT]] et à la [[Node-RED]] ou [[Flowhub]] pour [[OpenHAB]], Découverte [[UPnP]] des équipements)
| Toussaint, Saussac
| Didier Donsez
| [[Proj-2014-2015-OpenHAB-ExtendedGUI| '''Fiche''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/SRS| '''SRS''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/UML| '''Diagrammes UML''']] [[Projet-2014-2015-OpenHAB-ExtendedGUI/Scrum| '''Scrum''']]
| [https://github.com/saussact/projet '''github''']
| [[Media:Proj-2014-2015-OpenHAB-ExtendedGUI/Rapport|rapport]] - [[Media:Proj-2014-2015-OpenHAB-ExtendedGUI-transparents.pdf|transparents]] - [[Media:PProj-2014-2015-OpenHAB-ExtendedGUI-flyer.pdf|flyer]] - [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 7
| [[CannonBall de voitures autonomes|CannonBall de voitures autonomes, Edition 2015]]
| Le-Jean, Mammar, Pelloux-Prayer, Rodrigues
| Didier Donsez & Vivien Quema
| [[Project-2014-2015-CannonBall| '''Fiche''']][[Project 2014-2015-CannonBall/SRS| '''SRS''']][[Project 2014-2015-CannonBall/UML| '''UML''']][[Project 2014-2015-CannonBall/Scrum| '''Scrum''']][[Project 2014-2015-CannonBall/DesignPatterns| '''DesignPatterns''']]
| [https://github.com/malek0512/2014_2015_ricm4_cannon_ball '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 8
| [[Navigation et Montre connectée]]
| Hamdani, Mesnier, Yao
| Jacques Lemordant
| [[Proj-2014-2015-Montreconnectée| '''Fiche''']] [[Proj-2014-2015-Montreconnectée/SRS| '''SRS''']] [[Proj-2014-2015-Montreconnectée/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Montreconnectée/Scrum| '''Scrum''']][[Proj-2014-2015-Montreconnectée/DesignPattern| '''DesignPattern''']]
| [https://github.com/vince0508/MontreConnectee '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 9
| [[Python sur ESP8266]]
| Libralesso, Soldano
| Olivier Richard
| [[Project-2014-2015-ESP8266| '''Fiche''']] - [[Proj-2014-2015-ESP8266/SRS| '''SRS''']] - [[Proj-2014-2015-ESP8266/UML| '''UML diagrams''']] - [[Proj-2014-2015-ESP8266/Scrum| '''Scrum''']]
| [https://github.com/librallu/RICM4Projet/ '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast] - [http://librallu.github.io/RICM4Projet/ '''website''']
|-

!scope="row"| 10
| [[Serious Game: Handicap, parole et geste v2]]
| Aissanou, Codazzi, Guo
| Olivier Richard
| [[Proj-2014-2015-SeriousGamev2| '''Fiche''']][[Proj-2014-2015-SeriousGamev2/SRS| '''SRS''']][[Proj-2014-2015-SeriousGamev2/Scrum| '''Scrum''']] [[Projet-2014-2015-SeriousGamev2/Diagrammes| '''Diagrammes UML''']]
| [https://github.com/wizardkeven/SeriousGameV2 '''github''']
| [[Media:ProjetXYZ/Rapport|rapport]] - [[Media:ProjetXXX-transparents.pdf|transparents]] - [[Media:ProjetXXX-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 11
| [[Plateforme d'expérimentation mini-datacentre]] Système
| Fotsing, Morison
| Olivier Richard
| [[Proj-2014-2015-Mini_DataCenter_Systeme| '''Fiche''']][[Proj-2014-2015-Mini_datacenter_Systeme_SRS| '''SRS''']] [[Proj-2014-2015-Mini_datacenter_Systeme_scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:ProjetMini_DataCenter_Systeme/Rapport|rapport]] - [[Media:ProjetMini_DataCenter_Systeme-transparents.pdf|transparents]] - [[Media:ProjetMini_DataCenter_Systeme-flyer.pdf|flyer]]- [[Media:ProjetMini_DataCenter_Systeme-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 12
| [[Plateforme d'expérimentation mini-datacentre]] Portail
| Rossi, Eudes
| Olivier Richard
| [[Proj-2014-2015-Mini_datacenter_portail| '''Fiche''']] [[Proj-2014-2015-Mini_datacenter_portail_SRS| '''SRS''']] [[Proj-2014-2015-Mini_datacenter_portail_scrum| '''Scrum''']] [[Proj-2014-2015-Mini_datacenter_portail_uml| '''UML''']]
| [https://github.com/EudesRobin/webui-oardocker '''github''']
| [[Media:Projet_Projet_Mini_datacenter_portail/Rapport|rapport]] - [[Media:Projet_Mini_datacenter_portail-transparents.pdf|transparents]] - [[Media:Projet_Mini_datacenter_portail-flyer.pdf|flyer]]- [[Media:ProjetXXX-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

|}

* [[Projet de monoski intelligent]] (RICM4 et 3I4 et Matériaux) pour le [http://www.defi-foly-laclusaz.com/ défi Foly 2015] : Didier Donsez, Pascal Jay, David Eon (2 élèves)
* [[Smart Classroom]] (avec ENSIMAG) Didier Donsez, Vivien Quema, Jérome Maisonnasse (4 élèves)
* Robot [[RobAIR]] à base de [[STM32 Nucleo]] (+ cartes additionnelles MEMS BLE4) et de téléphones [[Firefox OS]]. Didier Donsez (4 élèves)
* [[StartAIR]] (Fabrice Dubost) (2 élèves)
* [[IDS|Interactive Digitale Signage]] avec [[Reveal.js]], [[Kinect]], [[WebRTC]], [[Node.js]], [[Open Data]], [[NFC]], [[Miracast]] [http://blueimp.github.io/Bootstrap-Image-Gallery/ Bootstrap Gallery]... (Didier Donsez) (2 élèves)
* [[Régie vidéo autonome et mobile multi-caméra]] (Didier Donsez, Thierry C.) (2 élèves)
* Interface HTML5 à la [[IFTTT]] et à la [[Node-RED]] ou [[Flowhub]] pour [[OpenHAB]] (2 élèves)
* [[Intégration d'Espruino à RIOT OS]] sur [[STM32 Nucleo]]: Application à la robotique [[RobAIR]] (Didier Donsez) (2 élèves)
* [[Inventaire Forestier]] sous Android (3I4 ou 5, RICM4) Emmanuel Promayon (2 élèves)
* [[Navigation indoor basé iBeacons]], Jacques Lemordant (2 élèves)
* [[Navigation et Montre connectée]], Jacques Lemordant (2 élèves)
* [[Projets Sitra avec la région Rhône-Alpes]], Jacques Lemordant (2 élèves)
* [[CannonBall de voitures autonomes|CannonBall de voitures autonomes, Edition 2015]] Didier Donsez & Vivien Quema (piste [[Star War Drone Race]]) (2 élèves)
* [[Python sur ESP8266]] Olivier Richard (2 élèves)
* [[Serious Game: Handicap, parole et geste v2]], edition 2015, Olivier Richard (2 élèves)
* [[Plateforme d'expérimentation mini-datacentre]] édition 2015, Olivier Richard (2 élèves)

==RICM5==
===Projet Semestre S10===
Démarrage : Lundi 26/01 à 8H00-12H00, P257 (Rendez-vous devant la salle AIR)

Soutenance : Mercredi 25/03 à 9H00-12H00, Salle à confirmer

{|class="wikitable alternance"
|+ Affectation des projets RICM5 2014-2015
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Dépot git
|-

!scope="row"| 1
| [[iRock]] :Plateforme Ubilitics pour la surveillance des risques naturelles (déploiement grande échelle de capteurs [[LoRa]] sur le terrain pour l'observation de glissement de terrain) .
| Peyre, Guo, Ginoux, Boey
| Didier Donsez & Denis Jongmans & Georges-Pierre Bonneau
| [[Proj-2014-2015-iRock| '''Fiche''']] [[Proj-2014-2015-iRock/SRS| '''SRS''']] [[Proj-2014-2015-iRock/UML| '''Diagrammes UML''']] [[Proj-2014-2015-iRock/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-iRock-Rapport|rapport]] - [[Media:Proj-2014-2015-iRock-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-iRock-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-iRock-poster.pdf|poster]] - [ [Media:Proj-2014-2015-iRock-média.pdf|Video ou Screencast]]
|-

!scope="row"| 2
| Plateforme Ubilitics pour [[SmartCampus 2015]] : (déploiement grande échelle de capteurs [[LoRa]]) (voir [[OpenBAS]]).
| Sambe, Husson, Labat, Fréby, Barbier
| Didier Donsez & Vivien Quema
| [[Proj-2014-2015-SmartCampus2015| '''Fiche''']] [[Proj-2014-2015-SmartCampus2015/SRS| '''SRS''']] [[Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel| '''Diagrammes UML''']] [[Proj-2014-2015-SmartCampus2015#Organisation_du_projet| '''Scrum''']]
| [https://github.com/nexucis/SmartCampus '''github''']
| [[Media:Proj-2014-2015-SmartCampus2015-Rapport|rapport]] - [[Media:Proj-2014-2015-SmartCampus2015-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartCampus2015-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-SmartCampus2015-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 3
| [[Extensions XBMC Sujet 2015]]
| Valentin, Bobo, Legros, Gabin Teulon (DUT1 R&T)
| Nicolas Palix
| [[Extensions_XBMC_Sujet_2015| '''Fiche''']] [[Proj-2014-2015-Ext_XBMC/SRS| '''SRS''']] [[Proj-2014-2015-Ext_XBMC/UML| '''Diagrammes UML''']] [[Proj-2014-2015-Ext_XBMC/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-Ext_XBMC/Rapport|rapport]] - [[Media:Proj-2014-2015-Ext_XBMC-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-Ext_XBMC-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-Ext_XBMC-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 4
| [[Smart Classroom]] : tables tactiles en mode [[Tiled Display]], Murs interactifs, Robots de Téléprésence, ...
| Benyounes, Fall, Tiamiou, Perruche, Quentin Fombaron (DUT1 R&T), Lucas Reygrobellet (DUT1 R&T)
| Didier Donsez & Vivien Quema & Jérome Maisonnasse
| [[Proj-2014-2015-SmartClassRoom| '''Fiche''']] [[Proj-2014-2015-SmartClassRoom/SRS| '''SRS''']] [[Proj-2014-2015-SmartClassRoom/UML| '''Diagrammes UML''']] [[Proj-2014-2015-SmartClassRoom/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-SmartClassRoom-Rapport|rapport]] - [[Media:Proj-2014-2015-SmartClassRoom-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassRoom-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-SmartClassRoom-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

!scope="row"| 5
| Défi H 2015 : Rééducation de la main
| Mariage, Perea, Clerc-Ghérardi, Arredondo (TIS5)
| Didier Donsez & Alessandro Semere & Nicolas Vuillerme + Pierre-Yves Thomas (tuteur Sogeti)
| '''Sur DropBox''' : [[HandTrainer| '''Fiche''']] [[HandTrainer-SRS| '''SRS''']] [[Proj-2014-2015-ReducMain/UML| '''Diagrammes UML''']] [[Proj-2014-2015-ReducMain/Scrum| '''Scrum''']]
| [https://github.com/ '''github''']
| [[Media:Proj-2014-2015-ReducMain-Rapport|rapport]] - [[Media:Proj-2014-2015-ReducMain-transparents.pdf|transparents]] - [[Media:Proj-2014-2015-SmartClassRoom-flyer.pdf|flyer]] - [[Media:Proj-2014-2015-ReducMain-poster.pdf|poster]] - [http://youtube.com Video ou Screencast]
|-

|}

Rappel: les séances de MPI (Management de Projet Innovant) auront lieu les jours suivants (salles sur ADE) :
* Mardi 27/01 après-midi (Stéphanie Diligent)
* Lundi 2/02 matin (Emmanuelle Tréhoust)
* Lundi 9/02 matin (Emmanuelle Tréhoust)
* Lundi 23/02 matin (Stéphanie Diligent)
* Mardi 17/03 matin (Stéphanie Diligent+Emmanuelle Tréhoust)

Remarque: il y à 3 étudiants PEIP D de l'IUT 1 R&T qui participeront aux projets.

===Projet Biométrie===
Démarrage : Lundi 26/01 à 8H00-9H45

Voir Laurent Besacier & François Portet

=3I=
==3I3==

==3I4==

==3I5==
* Carte d'extension Semtech [[LoRa]] pour [[Arduino]] et [[STM32 Nucleo]] (Didier Donsez)

=M2PGI=
* Extensions à [[SmartCampus]]

=Bachelor Summer Program=

=Année A définir=
* [[GeoDiff]] Production, visualisation, fusion de variations (diff) sur de l'information géocodée : Nicolas Palix
* [[Smart campus augmenté et contributif]]
* [[Intégration OpenHAB / OpenTele]]
* [[Client MQTT pour OBD]] sur Android
* [[Sommeilomètre]] (Michael Perin, Didier Donsez)
* [[Open DynDNS]]
* [[IllumiRoom]]
* [[Emergency mobile app]] Nicolas Palix pour TIS, PRI et RICM
* [[OwnPOI]] ownCloud plugin and osmand plugin to share POI and favorite positions. Nicolas Palix.
* [[OwnList]] ownCloud plugin and Android app to share a TODO list. Nicolas Palix.
* [[floatingimage UPnP feed]] Nicolas Palix
* [[XBMC Reflexive Remote]] Dynamic remote control for XBMC. Nicolas Palix.
* [http://intgat.tigress.co.uk/rmy/uml/index.html Zerofree] Portage de zerofree pour d'autres systèmes de fichiers que ext2/3/4 (notamment Unix FS). Voir également la page [http://packages.qa.debian.org/z/zerofree.html QA de Debian]. Nicolas Palix.
* [[Bracelet électronique de monitoriing de l'alcoolémie]]
* [[Oxymètre DIY]]
* [[PinSound]]
* [[Extension du support STM32Fx-Discovery dans libopencm3]] : Olivier Richard
* [[Arduino et libopencm3]] : Olivier Richard
* [[Data Acquisition System et Stm32f4-Discovery]] : Olivier Richard
* [[Distributed Data Storage System]] : Olivier Richard
* [[Dashboard based on w2ui]]
* [[Environnement logiciel pour FabLab]] : Olivier Richard
* [[Environnement logiciel pour le Live Programming]] : Olivier Richard
* [[VirtualPinball]]
* Tondeuse dessinatrice
* [[ImmersiveDog]] Nicolas Glade, Didier Donsez
* Projet avec [[OpenROV]] ???? : Didier Donsez
* [[Sphero]] malin (Michael Périn) (2 etudiants)
* [[Drone paramoteur]] ???
* [[IRock : Surveillance Géotechnique LoRa|iRock]]: Plateforme Ubilitics pour la surveillance des risques naturelles (déploiement grande échelle de capteurs [[LoRa]] sur le terrain pour l'observation de glissement de terrain) en commun avec Geotech (à confirmer) : Didier Donsez & Denis Jongmans
* [[Optimisation de l'énergie pour cyclotouriste électrique]]
* [[SmartSelfService|Smart Self-Service 2015]] Didier Donsez & Vivien Quema
* [[Station Météo LoRa]] : contribution au projet [[LoRA-Fabian]] (Didier Donsez)

=Réserve (boite à idées)=

# [[Tag et Paint Ball en réalité augmentée]] (Michaël Périn)
# [[Passe moi ton fichier]] (Michaël Périn)
# [[Extensions à Fab Server]] (Jean-Michel Molenaar) sous reserve (CM ou SR)
# [[Table multijeux de café 2.0]]
# [[ GPIO_Qemu_RasPI| Emulation des GPIO dans QEMU pour le carte Raspberry Pi]] (Olivier Richard)
# [[ Qemu et STM32F0-Discovery ]] (Olivier Richard)
# [[Serrure à clé MIDI multifactorielle]] (Didier Donsez)
# [[Table interactive musicale]] (Didier Donsez)
# [[iMailbox]] (Didier Donsez)
# [[AmILight]] (eclairage d'ambience intelligent) (Didier Donsez)
# [[PDAmeetPDA]] (synchronisation d'agenda) (Michaël Périn)
# [[1 000 000 VMs]] (expérimentation d'application distribuée à très grande échelle) (Olivier Richard) (2-3 RICM4)
# [[Multiple Kinect]] (utilisation simultanée de plusieurs Kinect) (Olivier Richard) (RICM ou 3I)
# [[Kinect musicale]] (Didier Donsez) (RICM)
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# Ocaml on AVR (Arduino)
# Ocaml on Cortex-M3
# [[Arduino on STM32 Discovery]]
# [[Reverse Geocache Puzzle Box]]
# [[OSGi ME]] (Didier Donsez)
# [[Affichage Etudiant à Polytech]]
# Synthèse 3D + motion capture Kinect
# Logiciel d'[[apprentissage du calcul]] sur tablette Android (reconnaissance de chiffres manuscrits)
# Plancher de verre (saint gobain) à la [http://www.wat.tv/video/mickael-jackson-billie-jean-oewj_2ey2h_.html Mickael Jackson dans Billie Jean] ! woo
# [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)
# [[CNC]]
# [[Idées en Vrac]]
# Scheme Everywhere (Olivier Richard) (2-3 RICM4-SR)
# [[Projet Station Météo]]
# Ocaml on AVR (Arduino)
# [[Table interactive musicale]] (Didier Donsez)
# [[AmILight]] (eclairage d'amnbience intelligent) (Didier Donsez)
# [[Cube pointeur]] d'activité ingénieur
# [http://www.instructables.com/id/Puppeteer-Motion-Capture-Costume/ Puppeteer Motion-Capture Costume]
# [[Musical Staircase]] @ Polytech (Didier Donsez, 1 RICM4 + 1 3I4)
# [[Total Recall]] (Didier Donsez)
# [[SoundMachine]]
# [[IGN-OSM|Importation de données IGN publiques dans OSM]]
# [[Speed-limit-OSM|Analyse de traces GPX pour déterminer les limitations de vitesse]]
# [[Multi perceptual cameras]] (Didier Donsez)
# [[Photomaton 3D]] (Didier Donsez)
# [[ArduCopter]]
# [[Parking Intelligent]]

File:IRock3.jpg

2015-03-23T10:14:18Z

RICM4-prj14-grp9:

File:IRock2.jpg

2015-03-23T10:13:53Z

RICM4-prj14-grp9:

File:IRock1.jpg

2015-03-23T10:13:31Z

RICM4-prj14-grp9:

Proj-2014-2015-iRock/UML

2015-03-23T10:00:41Z

RICM4-prj14-grp9: /* Architecture générale du projet */

Proj-2014-2015-iRock/UML

2015-03-23T09:59:57Z

RICM4-prj14-grp9: /* Diagramme physique */

Proj-2014-2015-iRock/UML

2015-03-23T09:59:08Z

RICM4-prj14-grp9: /* Diagrammes dynamiques */

Proj-2014-2015-iRock/UML

2015-03-23T09:58:03Z

RICM4-prj14-grp9: /* Diagramme physique */

Proj-2014-2015-iRock/UML

2015-03-23T09:56:38Z

RICM4-prj14-grp9: /* Diagramme logique */

Proj-2014-2015-iRock/UML

2015-03-23T09:56:08Z

RICM4-prj14-grp9: /* Diagramme de contexte */

Proj-2014-2015-iRock/UML

2015-03-23T09:54:54Z

RICM4-prj14-grp9: /* Architecture générale du projet */

Proj-2014-2015-iRock/UML

2015-03-23T09:54:28Z

RICM4-prj14-grp9: Created page with "==Architecture générale du projet== La communication entre les différents éléments du projet se fera via LoRA et MQTT [[File:IRockArch.png | 800px| center| thumb | A..."

File:IRockAct.png

2015-03-23T09:52:30Z

RICM4-prj14-grp9: