ArmadeusWiki - User contributions [en]

File:PaulM.png

2017-08-06T19:29:45Z

PaulM: Blanked the page

User:PaulM

2017-08-06T19:28:19Z

PaulM: Blanked the page

ELDER Project

2010-06-30T10:24:06Z

PaulM:

[[Image:elder_logo.png|128px|alt=Elder logo]]
[[Image:elder_robot.png|300px|right|alt=Elder Robot]]
== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Files and links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"

==== Students project reports ====

* '''PaulM''': Motion control, Beacon positioning system, High level software, Motor board: [http://syoctax.free.fr/Elder/Elder_report_paul.pdf PDF]
* '''Sebastien''': Mechanical design, Power Board, Daughter board, GUI: [http://syoctax.free.fr/Elder/Elder_report_seb.pdf PDF]

__TOC__

== Detailled informations ==

===Daughter board===

{| align="center"
|[[Image:elder_main-system.png|thumb|400px|center|ELDER's main system architecture]]
|[[Image:elder_pic-daughterboard.png|thumb|400px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|thumb|Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|thumb|Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|thumb|Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|thumb|Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|thumb|Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

=== Motor board ===
The role of this board is to provide a safe and reliable interface between the logic driver device and motors. It has to meet the motors requirement ([[MFA970D161]]). The diagram bellow shows motors board inputs/outputs.

[[Image:elder_motor_board_diagram.png|600px|center|Motor board architecture]]

==== System design ====

===== Isolated logic driver =====
The protection and voltage translation stage is done by using optocouplers. There are small devices that contain a diode and a photo-transistor. When the diode emits light, the photo-transistor becomes saturated and the logic level at its output is pulled high. Otherwise, the transistor is blocked and the logic level is low. The main advantage is to not have any electrical link between the input and the output. So if a short-circuit happens, the optocouplers might be destroyed but not the logic behind it.
The illustration bellow presents how optocouplers are polarized on the motor board. The reference used is [[FOD617]] from Fairchild semiconductor.

[[Image:elder_motor_board_opto.png|300px|center|thumb|Motor board optocoupler isolation]]

===== Power stage =====
The main devices that drive the motors are two full H-bridge drivers. These devices allow the motor to turn backward or forward at different speeds (controlled by using a
Pulse Width Modulation – PWM). The chosen devices are the [[LMD18200]] from National Semiconductor. They can drive 3A and have a current sensing output. Two capacitors are simply connected between outputs and boostraps pins, as shown on the figure below.

[[Image:elder_motor_board_hbridge.png|300px|center|thumb|Motor board hbridge circuit]]

=== VHDL Motion controller ===
The motion controller used is based on a VHDL design which is implemented in the FPGA.

The very first stage of the motion control is to decode the signals provided by the incremental encoders and output Pulse Width Modulated signals to control the motors
speeds. This is done in VHDL and implemented in the APF27 FPGA (programmable logic device). Further features are then build upon this like speed computation, X/Y
localizer, PID controllers etc.

In order to communicate properly with the CPU, the I.MX bus has to be used.
Signals are first of all wrapped into wishbone signals. The hierarchical structure contains components who owe a specific address range. As the address bus is 10bits
wide, it has been chosen to use a maximum of 8 components with 128 registers each. The motion controller is a component (certainly the biggest!) but other components can be added (mezzanine control for instance). This principle of “virtual components” is fully detailed with a led and button example on the [http://www.armadeus.com/wiki/index.php?title=A_simple_design_with_Wishbone_bus Armadeus wiki page].

[[Image:elder_vhdl_design_diagram.png|thumb|center|600px|VHDL Design architecture]]

==== System design ====

===== Encoder subsystem =====
The aim of this subsystem is to give the encoder speed (a signed value on 16 bits), given the A and B signals. The system again, can be split into different functions.

====== Digital filter ======
The first stage consists to filter the incoming signals. The filter should be able to remove noise peaks. Due to the physical aspects of the robot, the A and B signals cannot trigger faster than a specific rate.

For instance, if the encoder wheel's size is d = 60mm, the maximum speed is V = 2m/s and the number of pulse per revolution is R = 1024, 1 revolution of the wheel corresponds to :
Pi.d <=> R ticks

So there are
a = R / (Pi.d) ~ 5433 ticks/meter

Now the robot moves at V m/s, there are Vt ticks per seconds:
Vt = V.a ~ 10865 ticks/sec

Finally, it corresponds to a minimum width of 46μs. The filter has to remove any spike smaller than that.

The method used remains quite simple to implement and requires few logic elements. The filter uses a shift register, its input is fed by the actual signals (A, B).
The filtered output is stable (high or low) if all the register values are the same. Otherwise, the values remain unchanged. The sampling rate determines the filter latency and its capability to reject noise. For instance, in order to filter less than 46μs (approximated to 40μs) wide peaks, the sampling rate can be 250kHz (period = 5μs) and the filter 4bits wide.

====== Quadrature decoder ======
The second stage uses both input signals (A and B) to produce two outputs: '''COUNT''' and '''UP'''. COUNT is a counter output which triggers at each change (weather it is forward or backward). UP simply indicates if the rotation is clockwise or counter clockwise. This stage is achieved with a 4 states machine describe on the diagram bellow.

[[Image:elder_vhdl_quad_decoder.png|thumb|center|600px|Quadrature decoder state machine]]

{| align="center" width="400px" border="1"
|+ Combinatorial states of outputs truth table
! A !! B !! State !! COUNT !! UP
|- align="center"
| 1 || X || S0 || 1 || 1
|- align="center"
| X || 1 || S0 || 1 || 0
|- align="center"
| X || 1 || S1 || 1 || 1
|- align="center"
| 0 || X || S1 || 1 || 0
|- align="center"
| 0 || X || S2 || 1 || 1
|- align="center"
| X || 0 || S2 || 1 || 0
|- align="center"
| X || 0 || S3 || 1 || 1
|- align="center"
| 1 || X || S3 || 1 || 0
|- align="center"
| X || X || SX || 0 || X
|}

====== Speed counter ======
The output provided by the quadrature decoder can be directly connected to a counter. The increment/decrement input is UP and the clock rate is COUNT. In order to compute the speed, this counter is reset at a specific period. Thus, the value contained by the counter is directly the number of ticks between two resets, it
corresponds to a basic digital derivation.

However, this rate cannot be chosen randomly, it has to be in a certain range.
* If it's too slow, the speed value will be fed to the controller slowly and the physical motion between two computation might be important.
* If it's too quick, small variations may not be detected.

A common value of reset rate is around 100Hz. Thus, at the maximum speed, the speed counter contains around 109 ticks (maximum speed is around 10,865 ticks per second).

===== Left/Right to Alpha/Delta converter =====
The next stage is to convert these speeds into delta (linear translation) and alpha (orientation) values. The logical bloc uses signed values and compute the following formula:
D = (L+R)/2
A = R−L

===== Alpha/Delta to X/Y/T and Cordic core =====
The last stage of the localizer is the bloc that compute actual positions in X/Y domain. In order to do that, it's needed to compute trigonometric operations, this is
enabled with the Cordic core (which is provided by Xilinx as a free IP).

However there are few things to compute before, it's mainly about unit conversions.
The Cordic core needs radian value but the Left/Right to Alpha/Delta converter gives only a relative angle without any units.

The first thing to do is to compute the angle in radian, according to the following formula:
A[rad] = A/I

Where A is the angle and I is the interaxial value (distance between the two wheels). A and I have to be in the same unit (ticks), so that the result is in radian.
This division is done by an hardware divider and the result is fed to the cordic core.

The Cordic core gives the values of cos(A[rad]) and sin(A[rad]), the last stage is to multiply it by the linear speed Vn which is done by embedded multipliers.

The entity also has to manage the different latency and insure signals integrity. A specific process fetches dX and dY only when the outputs are valid. The last thing to do is insure that angle values are bounded between -Pi and +Pi (chosen representation). This is basically done by an hardware modulo.

===== PWM Generator =====
This entity is used to produce a Pulse Width Modulation signal which control the motors speeds. This is simply done by a counter which compares the its value to the
desired speed and set the output to 0/1, whether the counter's value is above or below the threshold.

Some specific features have also been added, the PWM is actually signed and also delivers a direction output depending on the speed's sign. This output can be inverted
(using a XOR gate) with the inverted input. This input is useful because the motors are mounted “head to head” and opposite voltage need to be applied to make the robot goes straight.

===== Alpha/Delta to Left/Right converter =====
This entity is basically the opposite of the Left/Right to Alpha/Delta entity. It computes the following formula:
R = D−A
L = D+A
The outputs are fed to the PWM blocs.

===== Error feeder =====
The error feeder is the link between the localization manager and the control manager. It uses orders (from the CPU) as reference, and computes the errors between those and the feedbacks. Outputs are positions and speeds in alpha/delta domain. These outputs are then used by the PID controllers.

===== PID Controllers =====
This is the heart of the controllers. A PID bloc is basically:
* 3 multipliers, between the error and associated gains (Kp, Ki, Kd)
* An accumulator (integral effect)
* A unitary delay with a subtracter (derivative effect)
* A three-inputs adder (output computing).

The resources needed can start to be important depending on the resolution. Internally, registers are 24 bits wide but only the 16 MSB can be retrieved by the CPU.

=== Main Software ===

==== Specifications ====
This section describes the main software running on the APF27 board. It includes both low-level/drivers functions and high-level (like A.I.) routines. This also also one of the part which needs a lot of work and development is still in progress. That's why some high level functions haven't been written yet, focus on low level primitives and different drivers has been given.

The software is multithreading and has to deal with a lot of different components:
* Motion-controller low-level modules
* CAN bus managment
* GUI and user I/O managment
* High-level routines (path-finding, A.I.)
* Log manager
* Other features (e.g. beacons)

==== Low-level software ====
The low-level software of the motion controller provides the link between higher software (A.I., obstacle avoidance etc.) and the FPGA registers themselves. The motion control is composed of 3 modules:
* FPGA module which is the proper driver to read/write values
* Motion Control driver, which computes the values that need to be written in the registers
* Trajectory Manager module, used to build paths that are then given to the motion control module. These paths need waypoints points (logical point where the robot has to go) which are fed by the higher levels (obstacle avoidance and pathfinder).

===== FPGA module =====
The FPGA is mapped at a specific address and can be acceded like a memory. It's achieved by using pointers and the C code is relatively compact and an example is shown on the dedicated [http://www.armadeus.com/wiki/index.php?title=FPGA_register Armadeus wiki webpage].

===== Motion control module =====
This module is linked to the trajectory manager. The main function of the motion control module is moveFollowPath, which takes a path in parameter. This function write appropriate values in the FPGA registers in order to follow the computed path.
The written values take into account the possible drift of the robot and then correct it accordingly.

===== Trajectory manager module =====
This is certainly the heavier module in terms of computation. This module provide different functions to compute a path, given a set of waypoints. The first and simpler “path rule” consist of two basic steps:
* Turn on place to align the robot on the next waypoint
* Go straight until the waypoint is reached

When the last point is reached, the robot can turn on place a last time to be on a specific direction. It's easy to see that if there are N waypoints, the total number of points/moves will be '''2N-1''' (1 turn and 1 straight path per waypoint except for the 1st point). The function is called pathStraight() and takes two parameters: the waypoints array and its size. The returned path's points are allocated dynamically and then need to be free once the path is used.

The second function is an enhancement of the previous one, instead of turning on place at each waypoint the robot can make a complex move (rotation+translation) in
order to “round” the corners. The function pathStraightRoundCorners() takes the same parameters as previously plus the corner size radius. The two points computed for the
same waypoints are now shifted from the corner size radius along the previous and next direction respectively, as shown on the illustration bellow.

[[Image:elder_software_round_corners.png|center|thumb|500px|Illustration of the "round corner" path generation]]

==== High-level software ====
The main program's goal is to manage all the different and individual modules.
There are many ways to do that, but the program runs on an Operating System so it's possible to use the POSIX multithreading features.
Each “manager” is considered as an independent thread and is launched by the main process. This project intended to work on three threads (but they are more than that):
* The strategy manager, which calls all the pathfinding and motion control algorithms, manage to send message when it's needed etc.
* The CAN manager, which is responsible for messages reception and take proper actions.
* The Log manager; a passive thread that simply store the robot's status in a logfile.

The figure bellow shows the different interconnections between software entities.

[[Image:elder_software_architecture.png|center|thumb|500px|Software architecture]]

===== Strategy manager =====
The strategy manager is the main thread of the program. It uses all the available functions provided by the artificial intelligence, path finder, trajectory generator, motion controller and can manager modules. It also uses the robot's status which is stored and manipulated with the context module.
The artificial intelligence uses a set a rules, determined at the beginning. These rules say, for instance, which action between two possibilities has the highest priority.
It provides primitives that actually call related function(s). For example '''“MOVE THE ARM”''' corresponds to send a message on the CAN bus where “MOVE THE ROBOT” corresponds to a complex cascading call of functions.

===== CAN manager =====
The CAN manager module provides the high level interface with the other robot's peripherals. The initialisation function open the device and create a socket, using the socketCAN module for linux.
The main thread keeps waiting for incoming messages. When something arrives, it's decoded and fetched. Then, the robot's status is updated if needed (for example, the position of a servomotor has changed).

The library used is the one developped by [[User:YoannC|Yoann Congal]] in 2008/2009 for the [http://clubrobotique.free.fr Robotnik Club (INSA of Rennes)].

===== Log manager =====
The log manager is surely the smallest thread but remains nonetheless important for debugging purposes.
The first thing done by the initialisation function is to create a new file with a timestamp in its name. The format is '''“elder_yyyy_mm_dd-hh_mm.log”'''. So that files are sorted by name from the oldest to the newest.

As long as the main program runs, the context is stored in this file periodically (the rate can be adjusted, 50ms is used which corresponds to 20 samples per seconds).
When the program ends, the close function is called. The logfile is then closed and copied with a different name: “last.log”. Then, in order to retrieve the log there is no need to know the exact name (extremely useful for automated tasks that can be scripted).

These logfiles are then used by a Gnuplot script. This script can be found on the SVN repository ('''svn-elder/projects/elder_sw/gnuplot/elder.gnu''').

[[Image:gnuplot_example.png|thumb|center|800px|Gnuplot example of output]]

===== Graphical User Interface =====

[[Image:Elder_onboard_gui.jpg|600px|right|alt=Onboard GUI]]

The [[APF27]] board can be interfaced with graphical [[LCD]] display and its associated touch screen.

During the matches, the robot has to be completely autonomous, without a computer plugged to it.

A simple graphical user interface has been developed in order to be able to display any type of useful informations on the robot such as:

* The battery level
* The time left during the matches
* The position of the robot on the game table
* The number of points the robot has scored

On this screen, there is also a console to display miscellaneous messages.

The touch screen allows the user to be interactive with the robot, to browse menu and ask the robot execute an action.
This can be useful just before the matches to check if everything works properly.

The LCD is directly interfaced with the SDL library.
This library can be used in C language to develop multimedia application on various platforms.

=== Remaining work ===
Regarding the diagram shown at the begining, some parts are still missing. The A.I. is quite a huge piece of work. During the 2010's contest, no A.I. was used due to a lack of time but only deterministic operations (pre-determined path following). Some changes will be also done because some specifications could have been better (often in a simpler way!).

File:Elder logo.png

2010-06-30T10:23:03Z

PaulM: uploaded a new version of "Image:Elder logo.png": ELDER Project: Logo

File:Elder logo.png

2010-06-30T10:16:18Z

PaulM: uploaded a new version of "Image:Elder logo.png": Reverted to version as of 10:11, 30 June 2010

File:Elder logo.png

2010-06-30T10:15:22Z

PaulM: uploaded a new version of "Image:Elder logo.png": ELDER Project: Logo

File:Elder robot.png

2010-06-30T10:11:40Z

PaulM:

File:Elder logo.png

2010-06-30T10:11:20Z

PaulM:

File:Gnuplot example.png

2010-06-30T09:54:44Z

PaulM: ELDER Project: Gnuplot output example

ELDER Project:
Gnuplot output example

File:Elder software architecture.png

2010-06-30T09:49:38Z

PaulM: ELDER Project: Software architecture

ELDER Project:
Software architecture

File:Elder software round corners.png

2010-06-30T09:49:13Z

PaulM: ELDER Project: Software, round corner function

ELDER Project:
Software, round corner function

File:Elder vhdl quad decoder.png

2010-06-30T09:41:30Z

PaulM: ELDER Project: VHDL quadrature decoder

ELDER Project:
VHDL quadrature decoder

File:Elder vhdl design diagram.png

2010-06-30T09:41:03Z

PaulM: ELDER Project: VHDL Design diagram

ELDER Project:
VHDL Design diagram

ELDER Project

2010-06-30T09:37:23Z

PaulM: Motor board section added

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

[[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Files and links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"

==== Students project reports ====

* '''PaulM''': Motion control, Beacon positioning system, High level software, Motor board: [http://syoctax.free.fr/Elder/Elder_report_paul.pdf PDF]
* '''Sebastien''': Mechanical design, Power Board, Daughter board, GUI: [http://syoctax.free.fr/Elder/Elder_report_seb.pdf PDF]

== Detailled informations ==

===Daughter board===

[[Image:elder_pic-daughterboard.png|thumb|600px|center|ELDER's main boards (APF27 connected to the daughter board)]]

====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|thumb|Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|thumb|Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|thumb|Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|thumb|Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|thumb|Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

=== Motor board ===
The role of this board is to provide a safe and reliable interface between the logic driver device and motors. It has to meet the motors requirement ([[MFA970D161]]). The diagram bellow shows motors board inputs/outputs.

[[Image:elder_motor_board_diagram.png|600px|center|Motor board architecture]]

==== System design ====

===== Isolated logic driver =====
The protection and voltage translation stage is done by using optocouplers. There are small devices that contain a diode and a photo-transistor. When the diode emits light, the photo-transistor becomes saturated and the logic level at its output is pulled high. Otherwise, the transistor is blocked and the logic level is low. The main advantage is to not have any electrical link between the input and the output. So if a short-circuit happens, the optocouplers might be destroyed but not the logic behind it.
The illustration bellow presents how optocouplers are polarized on the motor board. The reference used is [[FOD617]] from Fairchild semiconductor.

[[Image:elder_motor_board_opto.png|300px|center|thumb|Motor board optocoupler isolation]]

===== Power stage =====
The main devices that drive the motors are two full H-bridge drivers. These devices allow the motor to turn backward or forward at different speeds (controlled by using a
Pulse Width Modulation – PWM). The chosen devices are the [[LMD18200]] from National Semiconductor. They can drive 3A and have a current sensing output. Two capacitors are simply connected between outputs and boostraps pins, as shown on the figure below.

[[Image:elder_motor_board_hbridge.png|300px|center|thumb|Motor board hbridge circuit]]

=== Onboard GUI ===

[[Image:Elder_onboard_gui.jpg|800px|right|alt=Onboard GUI]]

The [[APF27]] board can be interfaced with graphical [[LCD]] display and its associated touch screen.

During the matches, the robot has to be completely autonomous, without a computer plugged to it.

A simple graphical user interface has been developed in order to be able to display any type of useful informations on the robot such as:

*The battery level
*The time left during the matches
*The position of the robot on the game table
*The number of points the robot has scored

On this screen, there is also a console to display miscellaneous messages.

The touch screen allows the user to be interactive with the robot, to browse menu and ask the robot execute an action.
This can be useful just before the matches to check if everything works properly.

The LCD is directly interfaced with the SDL library.
This library can be used in C language to develop multimedia application on various platforms.

'''More information comming soon'''

File:Elder motor board hbridge.png

2010-06-30T09:35:41Z

PaulM: ELDER Project: Motor board H bridge circuit

ELDER Project:
Motor board H bridge circuit

File:Elder motor board opto.png

2010-06-30T09:35:15Z

PaulM: ELDER Project: Motor board optocoupler isolation

ELDER Project:
Motor board optocoupler isolation

File:Elder motor board diagram.png

2010-06-30T09:34:02Z

PaulM: ELDER Project: Motor board diagram

ELDER Project:
Motor board diagram

ELDER Project

2010-06-29T13:47:36Z

PaulM: /* Onboard GUI */

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

{| align="center"
| [[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]
| [[Image:elder_pic-daughterboard.png|thumb|300px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"

'''Students project reports'''

* '''PaulM''': Motion control, Beacon positioning system, High level software, Motor board: [http://syoctax.free.fr/Elder/Elder_report_paul.pdf PDF]
* '''Sebastien''': Mechanical design, Power Board, Daughter board, GUI: [http://syoctax.free.fr/Elder/Elder_report_seb.pdf PDF]

== Detailled informations ==

===Daughter board===

[[Image:elder_pic-daughterboard.png|600px|right|alt=daughter board]]

====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|alt= Elder project: Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|alt=Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|alt=Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|alt=Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|alt=Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|alt=Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

===Onboard GUI===

[[Image:Elder_onboard_gui.jpg|800px|right|alt=Onboard GUI]]

The [[APF27]] board can be interfaced with graphical [[LCD]] display and its associated touch screen.

During the matches, the robot has to be completely autonomous, without a computer plugged to it.

A simple graphical user interface has been developed in order to be able to display any type of useful informations on the robot such as:

*The battery level
*The time left during the matches
*The position of the robot on the game table
*The number of points the robot has scored

On this screen, there is also a console to display miscellaneous messages.

The touch screen allows the user to be interactive with the robot, to browse menu and ask the robot execute an action.
This can be useful just before the matches to check if everything works properly.

The LCD is directly interfaced with the SDL library.
This library can be used in C language to develop multimedia application on various platforms.

'''More information comming soon'''

ELDER Project

2010-06-29T11:29:07Z

PaulM: /* Links */

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

{| align="center"
| [[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]
| [[Image:elder_pic-daughterboard.png|thumb|300px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"

'''Students project reports'''

* '''PaulM''': Motion control, Beacon positioning system, High level software, Motor board: [http://syoctax.free.fr/Elder/Elder_report_paul.pdf PDF]
* '''Sebastien''': Mechanical design, Power Board, Daughter board, GUI: [http://syoctax.free.fr/Elder/Elder_report_seb.pdf PDF]

== Detailled informations ==

===Daughter board===

[[Image:elder_pic-daughterboard.png|600px|right|alt=daughter board]]

====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|alt= Elder project: Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|alt=Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|alt=Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|alt=Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|alt=Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|alt=Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

===Onboard GUI===

[[Image:Elder_onboard_gui.jpg|800px|right|alt=Onboard GUI]]

The [[APF27]] board can be interfaced with graphical [[LCD]] display and its associated touch screen.

During the matches, the robot has to be completely autonomous, without a computer plugged to it.

A simple graphical user interface has been developed in order to be able to display any type of useful information on the robot such as:

*The battery level
*The time left during the matches
*The position of the robot on the game table
*The number of points the robot has scored

On this screen, there is also a console to display miscellaneous messages.

The touch screen allows the user to be interactive with the robot, to browse menu and ask the robot execute an action.
This can be useful just before the matches to check if everything works properly.

The LCD is directly interfaced with the SDL library.
This library can be used in C language to develop multimedia application on various platforms.

'''More information comming soon'''

ELDER Project

2010-06-29T11:28:38Z

PaulM: /* Links */

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

{| align="center"
| [[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]
| [[Image:elder_pic-daughterboard.png|thumb|300px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"

'''Students project reports'''

* '''PaulM''': Motion control, Beacon positioning system, High level software, Motor board [http://syoctax.free.fr/Elder/Elder_report_paul.pdf PDF]
* '''Sebastien''': Mechanical design, Power Board, Daughter board, GUI: [http://syoctax.free.fr/Elder/Elder_report_seb.pdf PDF]

== Detailled informations ==

===Daughter board===

[[Image:elder_pic-daughterboard.png|600px|right|alt=daughter board]]

====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|alt= Elder project: Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|alt=Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|alt=Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|alt=Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|alt=Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|alt=Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

===Onboard GUI===

[[Image:Elder_onboard_gui.jpg|800px|right|alt=Onboard GUI]]

The [[APF27]] board can be interfaced with graphical [[LCD]] display and its associated touch screen.

During the matches, the robot has to be completely autonomous, without a computer plugged to it.

A simple graphical user interface has been developed in order to be able to display any type of useful information on the robot such as:

*The battery level
*The time left during the matches
*The position of the robot on the game table
*The number of points the robot has scored

On this screen, there is also a console to display miscellaneous messages.

The touch screen allows the user to be interactive with the robot, to browse menu and ask the robot execute an action.
This can be useful just before the matches to check if everything works properly.

The LCD is directly interfaced with the SDL library.
This library can be used in C language to develop multimedia application on various platforms.

'''More information comming soon'''

ELDER Project

2010-06-29T10:20:29Z

PaulM: /* Detailled informations */

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

{| align="center"
| [[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]
| [[Image:elder_pic-daughterboard.png|thumb|300px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"
* You can already have a look to the students project reports at "svn-elder/resources/classe"

== Detailled informations ==

===Daughter board===

[[Image:elder_pic-daughterboard.png|600px|right|alt=daughter board]]

====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|alt= Elder project: Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|alt=Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|alt=Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|alt=Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|alt=Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|alt=Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

===Onboard GUI===

[[Image:Elder_onboard_gui.jpg|800px|right|alt=Onboard GUI]]

The [[APF27]] board can be interfaced with graphical [[LCD]] display and its associated touch screen.

During the matches, the robot has to be completely autonomous, without a computer plugged to it.

A simple graphical user interface has been developed in order to be able to display any type of useful information on the robot such as:

*The battery level
*The time left during the matches
*The position of the robot on the game table
*The number of points the robot has scored

On this screen, there is also a console to display miscellaneous messages.

The touch screen allows the user to be interactive with the robot, to browse menu and ask the robot execute an action.
This can be useful just before the matches to check if everything works properly.

The LCD is directly interfaced with the SDL library.
This library can be used in C language to develop multimedia application on various platforms.

'''More information comming soon'''

File:Elder onboard gui.jpg

2010-06-29T10:18:47Z

PaulM:

ELDER Project

2010-06-29T10:17:15Z

PaulM: /* Detailled informations */

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

{| align="center"
| [[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]
| [[Image:elder_pic-daughterboard.png|thumb|300px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"
* You can already have a look to the students project reports at "svn-elder/resources/classe"

== Detailled informations ==

===Daughter board===
====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|alt= Elder project: Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|alt=Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|alt=Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|alt=Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|alt=Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|alt=Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

===Onboard GUI===

[[Image:Elder_onboard_gui.jpg|800px|right|alt=Onboard GUI]]

The [[APF27]] board can be interfaced with graphical [[LCD]] display and its associated touch screen.

During the matches, the robot has to be completely autonomous, without a computer plugged to it.

A simple graphical user interface has been developed in order to be able to display any type of useful information on the robot such as:

*The battery level
*The time left during the matches
*The position of the robot on the game table
*The number of points the robot has scored

On this screen, there is also a console to display miscellaneous messages.

The touch screen allows the user to be interactive with the robot, to browse menu and ask the robot execute an action.
This can be useful just before the matches to check if everything works properly.

The LCD is directly interfaced with the SDL library.
This library can be used in C language to develop multimedia application on various platforms.

'''More information comming soon'''

File:Elder fan characteristic.png

2010-06-29T10:13:03Z

PaulM:

File:Elder module pinout.png

2010-06-29T10:12:52Z

PaulM:

File:Elder encoders sch.png

2010-06-29T10:12:38Z

PaulM:

File:Elder fan control.png

2010-06-29T10:12:15Z

PaulM:

File:Elder daughter board mic.png

2010-06-29T10:12:01Z

PaulM:

File:Elder Daughter board sch.png

2010-06-29T10:11:29Z

PaulM:

ELDER Project

2010-06-29T10:08:15Z

PaulM: /* Daughter board */

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

{| align="center"
| [[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]
| [[Image:elder_pic-daughterboard.png|thumb|300px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"
* You can already have a look to the students project reports at "svn-elder/resources/classe"

== Detailled informations ==

===Daughter board===
====Introduction====

The aim of the daughter board is to interface the [[APF27]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|alt= Elder project: Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|alt=Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|alt=Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|alt=Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|alt=Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|alt=Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

'''More information comming soon'''

ELDER Project

2010-06-29T10:07:11Z

PaulM: /* Detailled informations */

== Project overview ==
ELDER (Embedded Linux Development for Robotics) Project is a robotic team which participated to the [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=100 French robotic cup] in May 2010. The team used an Armadeus APF27 + APF27Dev boards. This involved to work on both hardware and software designs. One of the goal of this project is to evolve and some parts are still under development.

The main features provided by the APF27 were:
* Robot location computation (X,Y,Orientation), done in hardware by the FPGA
* Robot motion control, done by the FPGA as well
* Multithreading program for high level implementations: path-finding, A.I., gui manager, CAN manager etc.

{| align="center"
| [[Image:elder_main-system.png|thumb|300px|center|ELDER's main system architecture]]
| [[Image:elder_pic-daughterboard.png|thumb|300px|center|ELDER's main boards (APF27 connected to the daughter board)]]
|}

=== Project members ===
This project is actually the work of two students in last year of their Master in Engineering at the [http://www.strath.ac.uk/eee/ University of Strathclyde].
* [[User:PaulM|PaulM]]
* Sebastien

=== Links ===
In order to help the development of this project and the team's communication, a wiki and a subversion repository have been created. Links are bellow.
* [http://www.mp-net.fr/elder Wiki] ''Note that the wiki might be updated during the next days''.
* [http://www.mp-net.fr/elder/svn SVN repository]

'''Notes about the Subversion repository'''
* The actual FPGA firmware files are located at "svn-elder/projects/fpga_fw"
* The actual software files are located at "svn-elder/projects/elder_sw/armadeus"
* You can already have a look to the students project reports at "svn-elder/resources/classe"

== Detailled informations ==

===Daughter board===
====Introduction====

The aim of the daughter board is to interface the [[Armadeus]] board ( which is used for the intelligence and the motion control) with everything else on the robot such as sensors, actuators, servos, motors, etc...
Modules can also be plugged on it according to the robot needs and be interfaced with the Armadeus FPGA or the daughter board’s own microcontroller.
Therefore each year, small boards can be developed in line with the project theme and the chosen mechanical solutions.

====Requirements====

The electrical and mechanical requirements are:
*100 x 160 mm board : the board has to be the same size as Armadeus board in order to be stacked over it.
*45 x 45 mm plug-in modules (up to 6 can be plugged) with on each:
**3.3V logic supply
**5V and 12V power supply
**CAN Bus
**UART (serial transmission)
**8 GPIO
*Encoders interface
*Motors interface (PWM and directions)
*Fan control

The daughter board is meant to become a ’mother board’ on which can run the motion control (PID) and the intelligence of the robot.

====System design====

[[Image:Elder_Daughter_board_sch.png|600px|center|alt= Elder project: Daughter board system description]]

=====Microcontroller=====

The choice of the microcontroller was based on the requirements, and first an MSP430 from Texas Instrument was chosen.
But after two weeks of trying to make a programmer for this type of microcontroller without success, a PIC32MX has finally been selected instead.

[[Image:Elder_daughter_board_mic.png|600px|center|alt=Daughter board main microcontroller, with its associated components]]

The PIC32 is a 32 bits microcontroller architecture family from Microchip, and the PIC32MX575F512H has the following features:
*Max Speed: 80 Mhz
*10-bits ADC 16 channels
*5 PWM outputs
*5 timers
*53 I/O pins
*6 UARTS

All this features were enough to fit to the requirements, moreover, this chip could be acquired for free, with the Microchip free samples process.

Note that the microcontroller is also interfaced with the CAN bus, and the implementation is the same as described before for the power board.
A LED has been putted on a free pin at the end, which is useful to debug or to make the first ’led blinking test’ for example.

=====Fan control=====

[[Image:Elder_fan_control.png|300px|center|alt=Fan control circuit]]

The [[Armadeus]] board, daughter board, power board and plug-in modules are all mounted in a same box.
This configuration generate heat which has to be cooled by a fan in order to have correct performances.

A small dedicated microcontroller is used to realize this function, which again has been chosen from the Microchip manufacturer.
It is a PIC12F683 which is small (8 pins), has got an ADC for the temperature reading and a PWM output for the fan speed setting.

The fan is driven by a MOSFET which is triggered by the PWM, and gives the possibility to apply a 12V supply voltage directly on it.

A freewheeling diode is also putted between the fan’s terminals, in order to protect it from being damaged by instant high voltages generated by the inductive property of the motor.

=====Encoders interface=====

[[Image:Elder_encoders_sch.png|500px|center|alt=Encoders interface circuit]]

The encoders are used to measure accurately the distance traveled by the robot, it gives 1024 ’ticks’ for each wheel revolution.
These ticks are transmitted via two channels A and B, which both are differential outputs of the encoder.

In order to treat these signals, AM26LV32 differential line receiver are used. This kind of chip can be supplied with only 3.3V however it accepts 5V inputs, which is the minimum supply level for the encoders.

As a result, it plays a double role as converting the differential input in a single output, and as converting a 5V input to a 3.3V output which is acceptable for the FPGA or the microcontroller.

=====Modules sockets=====

[[Image:Elder_module_pinout.png|500px|center|alt=Module pin-out]]

Each module can access to a 5V and 12V power supply generated from the power board, and a 3.3V logic supply generated by the daughter board.
It also has the possibility to use the CAN bus or an UART from the PIC32MX.

Three of six modules have 8 GPIO each directly mapped to the Armadeus board’s FPGA, and the 3 others have these available GPIO linked to the PIC32MX microcontroller’s ports.

=====Program=====

======PIC32MX======

At this stage of the project, there is no module which has been realized, so the only program running on the PIC32MX is blinking led code.
This one has been developed in order to test if microcontroller was working, according to the configuration bits.
This test has been successful, now need to be debugged the UART and the CAN bus.

======PIC12F======

For the PIC12F which control the fan, the program is very simple, there is a main loop in which the ADC is read, and this value determines the PWM duty cycle.
The relation between the temperature and the duty cycle value is shown in the figure below , where three phases can be seen:

*before 30°C, the fan is stopped.
*between 30°C and 60°C the speed of the fan is linearly increasing according the temperature. An initial offset is required to start the fan’s motor.
*after 60°C, the fan remains at 100% speed

[[Image:Elder_fan_characteristic.png|500px|center|alt=Relation between the temperature and the fan’s PWM duty cycle]]

There is also a blinking LED, to be sure the microcontroller is correctly running.

'''More information comming soon'''

ELDER Project

2010-06-29T09:13:35Z

PaulM: Page creation

File:Elder pic-daughterboard.png

2010-06-29T09:09:05Z

PaulM: ELDER Project: Picture of the APF27 connected to the daughter board.

ELDER Project:
Picture of the APF27 connected to the daughter board.

File:Elder main-system.png

2010-06-29T08:56:14Z

PaulM: ELDER Project: Main system architecture diagram.

ELDER Project:
Main system architecture diagram.

Contest

2010-06-29T08:30:04Z

PaulM: Elder project added to the list

'''2009-2010 Association Contest'''

On this page, you will find all the usefull informations to participate to the 2009-2010 Armadeus Project Association Contest

==What is it and why ?==
After 2 years of existence, the association has generated enough cash to promote or speed up internal developments.
During the [[ArmadeusWiki:Current_events|last annual meeting]], it has been decided to use a part of these funds to organize a contest.
The goal of this contest is to increase the number of applications developped by the members.

==Who can participate ?==
The members of the association (ie the people who already have an [[APF9328]] or [[APF27]] board).
This is a restrictive point, but we consider that a common development system is mandatory to share the work.

== The rules ==
* The projects have to be registered before: June 30th 2010
* The participant(s) is a (are) member(s) of the [[Association|Armadeus Project association]]
* The whole sources and the schematics have to be publicly available and usable (GPL/LGPL)
* Hardware or/and software applications can be proposed
* A wiki page is mandatory and must contain ([[Contest_Template_Page|here is a template]]):
** a description of the project (a few words)
** the name(s) of the member(s)
** the documentation to use the application, to compile the sources and to build the hardware
* No special components have to be used (for electronics projects): all must be easily purchased
* Registration is done by adding the link of the wiki page to the list below
* The jury is composed of all the interested Armadeus Project members (min 5 members) and will have one month to deliberate after the contest closure. The vote will be done by email and have to be sent to contest(at)armadeus(dot)org. Prices will be attributed during LSM 2010 (RMLLs) in Bordeaux (France) .

== The awards (To be confirmed)==
* First award: an [[APF27]] kit (APF27 + corresponding [[APF27Dev]] board (full options))
* Second award: a 7" TFT and its adapter board for APF27
* Third award: an APF27 wireless extansion with GSM and GPS modules

==Current Projects List (2009-2010)==
* [[Brushless motor controller]]
* [[OND - Open Navigation Device (Phase 1)]]
* [[ROBOTNIK]]
* [[ELDER Project]]

==Older projects==
===2008-2009===
* [[FireBoard | FireBoard, development cards emulation project]]
* [[MotionSystem | MotionSystem, R/C Servos Controller and Motion Measurement]] '''<<< Winner'''

User:PaulM

2009-09-18T09:06:39Z

PaulM: /* Présentation */

[[MemberList | Liste des membres]]

= Présentation =

[[Image:PaulM.png|100px|left|Photo de Paul MONSINJON]]

Je m'appelle Paul MONSINJON, j'ai 22 ans et habite à Rennes et en région parisienne (seine et marne). Vous pouvez me croiser sous le pseudo polo35/Hebus.

Actuellement en dernière année d'études à Glasgow en Ecosse, je prépare un double diplôme en [http://www.insa-rennes.fr/eii Électronique et Informatique Industriel] à l'INSA de Rennes et un [http://www.strath.ac.uk/eee/ MEng in Electronics and Electrical Engineering] à l'université de Strathclyde.

Passionné d'électronique depuis mes 15 ans, j'ai toujours aimé concevoir et fabriquer des circuits électronique. Cela a commencé au lyçée avec ma première participation à une compétition de robotique ([http://www.planete-sciences.org/robot/index.php?section=pages&pageid=84 trophée E=M6 à l'époque]). Plus tard, j'aurai l'occasion de participer à la [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=79 Coupe de France] grâce au club de l'INSA.

Mes centres principaux d'intérêt concernent les couches hardware et bas niveau software (développement de drivers). J'aime particulièrement développer sur FPGA et SOC.

Pour plus d'informations ou pour me contacter, vous pouvez consulter mon site web : http://monsinjon.paul.free.fr.

= Participation à l'association Armadeus =

Je possède une [[APF27]], sa carte de développement [[APF27Dev]] ainsi que l'écran [[LQ043_Adapt]] et le touchscreen [[TSC2102]] (équipé quoi !).

== 2008/2009 ==

En 2008, j'ai réalisé une carte d'interface [[User:YoannC#R.C3.A9alisation_avec_Armadeus_:_Club_Robotnik_Coupe_2009|présentée ici]]. Celle ci permet de connecter divers éléments d'un robot à l'[[APF9328]], en particulier :

* 2 moteurs à courant continu
* 2 codeurs incrémentaux
* 3 servos moteurs
* 3 modules SF05 (modules ultrason)
* 1 boussole numérique
* 1 switch de reset connecté au FPGA
* 1 switch DPDT pour la sélection d'une configuration de match (ici, la couleur)
* 1 switch relié à un jack pour le "top départ" du match
* 8 switchs DIL de configuration
* 8 leds qui servent à rien (éventuellement à debuguer !)
* Un afficheur 7 segments
* Et enfin 2 entrées supplémentaires en 5V.

== 2009/2010 ==

Ayant fait récemment l'acquisition d'une carte, je compte continuer à développer l'interface entre armadeus et un robot mobile. En particulier je compte réaliser une carte fille possédant les fonctionnalités suivantes :

* Reprendre une bonne partie des fonctionnalités de la carte précédente
* Monitoring tension et courant de batteries (LI-PO) et circuit de protection via un AT90CAN32 et le bus CAN.
* Intégration dans une partie dédiée des interfaces de puissance (ponts en H, commande des actionneurs etc.)
* Augmenter la modularité de la carte en ajoutant des entrées (capteurs de types différents, nombre de codeurs incrémentaux augmenté etc.).
* Éventuellement intégrer un circuit dédié au traitement d'image (DSP/DSPic) et à la gestion des capteurs.

Pour schématiser, le processeur ARM s'occuperait de la gestion globale du robot (stratégie, interface IHM via l'écran, gestion du CAN). Le FPGA quand à lui serait entièrement dédié à l'asservissement en position du robot via des FPU. Si possible celui-ci gérerait également l'ensemble des capteurs et pourrait faire de la vision (mais j'ai un doute par rapport au 200k portes ! d'où l'idée d'un circuit dédié à base de DSP).

MemberList

2009-09-15T12:13:08Z

PaulM: Ajout de PaulM

==Here is the list of the (active) members and their skills==

This list is maintained by the users themself.

*0: Novice
*1: Notions. At least one successfull experiment
*2: Confirmed
<br>

{| border="1" cellpadding="5" cellspacing="0" summary="Signal connections"
|- style="background:#efefef;"
! '''Name / IRC Nickname''' || '''Linux Apps'''|| '''Linux Drivers'''|| '''FPGA''' || '''Board Design''' || '''Projet/Domain'''
|----------------
|[[User:Salocin68|Nicolas Colombain / Salocin]] || 1 || 1 || 1 || 2 || domotics
|----------------
|[[User:JulienB|Julien Boibessot / Artemys]] || 2 || 2 || 0 || 1 || multimedia
|----------------
|[[User:JeanBaptisteM|Jean-Baptiste Mayer / JiBee]] || 2 || 1 || 1 || 1 || robotics
|----------------
|[[User:NicolasA|Nicolas Aguirre]] || 2 || 0 || 1 || 1 || multimedia
|----------------
|[[User:BenoitC|Benoît Canet]] || 2 || 0 || 0 || 0 || multimedia
|----------------
|[[User:SonZerro|Sonzerro]] || 0 || 0 || 1 || 2 || domotics
|----------------
|[[User:HenriG|Henri Geist]] || 1 || 1 || 0 || 1 || robotics
|----------------
|[[User:BorredonB|Bernard Borredon]] || 2 || 1 || 0 || 1 || domotics
|----------------
|[[User:ThomasB|Thomas Bores]] || 2 || 0 || 0 || 1 || Entertainment
|----------------
|[[User:FabriceM|Fabrice Mousset / KroMignon]] || 1 || 1 || 2 || 1 || Domotics & multimedia
|----------------
|[[User:AmineH|Amine EL HEDADI]] || 2 || 2 || 0 || 0 || domotics & robotics
|----------------
|[[User:PhilippeM|Philippe Monteil]] || 2 || 0 || 0 || 0 || multimedia
|----------------
|[[User:CedricZ|Cédric Zmyj]] || 0 || 0 || 0 || 0 || domotics & robotics
|----------------
|[[User:JeanMichelN|Jean Michel Naimo / jeanmi12 ]] || 2 || 1 || 1 || 1 || Domotics & entertainment
|----------------
|[[User:OlivierC|Olivier Coutanceau]] || 1 || 0 || 0 || 0 || multimedia
|----------------
|[[User:ArnaudC|Arnaud COFFINET]] || 0 || 0 || 1 || 2 || multimedia & domotics
|----------------
|[[User:SylvainP|Sylvain PARRINO]] || 2 || 1 || 0 || 0 || robotics
|----------------
|[[User:AurelienH|Aurélien HIRON]] || 2 || 0 || 0 || 1 || robotics
|----------------
|[[User:GuillaumeT|Guillaume TRANNOY]] || 0 || 0 || 0 || 2 || domotics & robotics
|----------------
|[[User:JulienN|Julien NICOLAS / jujun]] || 2 || 1 || 0 || 1 || multimedia & network
|----------------
|[[User:StephaneF|Stéphane Falck]] || 0 || 0 || 0 || 0 || multimedia & robotics & domotics
|----------------
|[[User:GillesD|Gilles DUSSIN/ Sellig]] || 1 || 0 || 1 || 1 || robotics
|----------------
|[[User:MaximeL|Maxime Liron]] || 0 || 0 || 0 || 0 || domotics, robotics & multimedia
|----------------
|[[User:NicolasC|Nicolas CHARLERY/ realniko]] || 2 || 0 || 0 || 0 || electronic
|----------------
|[[User:BenoitJ|Benoit JESTER]] || 0 || 0 || 0 || 0 || robotics
|----------------
|[[User:FabienM|Fabien MARTEAU/ FabM]] || 1 || 2 || 1 || 1 || robotics,domotics
|----------------
|[[User:XavierA|Xavier AZNAR]] || 1 || 1 || 0 || 0 || environment, entertainment, domotic
|----------------
|[[User:AlbericA|Albéric AUBLANC / PoueT]] || 2 || 0 || 1 || 0 || domotics & multimedia, robotics, entertainment,
|----------------
|[[User:FredericB| Frédéric Blain / creber]] || 2 || 1 || 0 || 0 || system, domotics
|----------------
|[[User:JeanBaptisteMa| Jean-Baptiste Maillet]] || 2 || 1 || 0 || 0 || system
|----------------
|[[User:JeanFrancoisR| Jean-François Rousval]] || 2 || 1 || 0 || 1 ||
|----------------
|[[User:JulienPeeters| Julien Peeters]] || 2 || 1 || 0 || 0 || domotics, real-time, entertainment, network
|----------------
|[[User:YoannC| Yoann Congal / Alpheb]] || 0 || 0 || 0 || 1 || robotics
|----------------
|[[User:MatthieuT| Matthieu Texier / weeber]] || 1 || 0 || 1 || 0 || robotics, real-time
|----------------
|[[User:MartialG| Martial Guex]] || 2 || 1 || 1 || 2 || transceiver RF, real-time, wireless
|----------------
|[[User:NicolasL| Nicolas Lantz]] || 2 || 2 || 1 || 1 ||
|----------------
|[[User:GuillaumeD| Guillaume DELVIT]] || 1 || 1 || 1 || 1 || system, asynchronous CPU
|----------------
|[[User:BernardR|Bernard REMOND ]] || x || x || x || x ||
|----------------
|[[User:SamirH| Samir HAMNACHE]] || 0 || 0 || 0 || 1 || électronique
|----------------
|[[User:OlivierT|Olivier TARDIEU]] || 0 || 0 || 0 || 1 || électronique,robotics,domotics
|----------------
|[[User:ThibautR|Thibault Rétornaz]] || 1 || 1 || 1 || 0 || bio-med, électronique
|----------------
|[[User:BrunoS|Bruno Suarez]] || 2 || 0 || 0 || 0 || bio-med, électronique
|----------------
|[[User:guillaumeDe|Guillaume Denis]] || 0 || 0 || 2 || 1 || Electronique numérique, FPGA
|----------------
|[[User:KevinP|Kévin PETIT]] || 1 || 0 || 1 || 1 || Multimedia
|----------------
|[[User:PierreBa|Pierre Baudemont / b4ud3]] || 2 || 0 || 1 || 0 || domotics, robotics
|----------------
|[[User:BrunoL|Bruno Landré]] || 0 || 0 || 0 || 0 || robotics
|----------------
|[[User:AntonioMB|Antonio Meléndez]] || 0 || 0 || 1 || 2 || domotics, robotics, eletcronics
|----------------
|[[User:MichelTe|Michel Le Mer]] || 0 || 0 || 2 || 2 || electronics, software
|----------------
|[[User:JulienBa|Julien Baley]] || 0 || 0 || 0 || 0 ||
|----------------
|[[User:FrankA|Frank ANJEAUX]] || 1 || 0 || 0 || 1 || software,robotics, domotics, electronics
|----------------
|[[User:JulienViaud|Julien viaud/polric]] || 2 || 0 || 1 || 1 ||
|----------------
|[[User:NicolasCa|Nicolas CARTIER]] || 1 || 1 || 0 || 2 || domotics & robotics
|----------------
|[[User:PierreAlexandreS|Pierre Alexandre SCHEMBRI]] || 2 || 1 || 2 || 2 || electronics, board design, embedded software, FPGA, robotics, low power
|----------------
|[[User:AlexG|Alex GONZALEZ]] || 2 || 2 || 0 || 1 || telecommunications, network & multimedia
|----------------
|[[User:JulienL|Julien Lefrique / apapi]] || 1 || 0 || 1 || 1 ||
|----------------
|[[User:PaoloB|Paolo Bernini / nihil84]] || 2 || 1 || 0 || 0 || robotics, real-time
|----------------
|[[User:MichielE|Michiel Ettema]] || 0 || 0 || 0 || 1 || telecommunications, networking
|----------------
|[[User:NicolasD|Nicolas Duclos]] || 2 || 1 || 0 || 0 || telecommunications, domotics and funs
|----------------
|[[User:SebastienP|Sebastien Philippe]] || 1 || 2 || 1 || 2 || electronics, board design, embedded linux
|----------------
|[[User:PaulM|Paul MONSINJON]] || 1 || 1 || 2 || 1 || robotics, fpga, embedded linux
|}

==Links==
* [[Members | Geographical position of the members]]

[[Category:Association]]

User:PaulM

2009-09-15T12:10:34Z

PaulM:

[[MemberList | Liste des membres]]

= Présentation =

[[Image:PaulM.png|100px|left|Photo de Paul MONSINJON]]

Je m'appelle Paul MONSINJON, j'ai 22 ans et habite à Rennes et en région parisienne (seine et marne). Vous pouvez me croiser sous le pseudo polo35/Hebus.

Actuellement en dernière année d'études à Glasgow en Ecosse, je prépare un double diplôme en [http://www.insa-rennes.fr/eii Électronique et Informatique Industriel] à l'INSA de Rennes et un [http://www.strath.ac.uk/eee/ MEng in Electronics and Electrical Engineering] à l'université de Strathclyde.

Passionné d'électronique depuis mes 15 ans, j'ai toujours aimé concevoir et fabriquer des circuits électronique. Cela a commencé au lyçée avec ma première participation à une compétition de robotique ([http://www.planete-sciences.org/robot/index.php?section=pages&pageid=84 trophée E=M6 à l'époque]). Plus tard, j'aurai l'occasion de participer à la [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=79 Coupe de France] grâce au club de l'INSA.

Mes centres principaux d'intérêt en ce qui concerne l'électronique concernent les couches hardware et bas niveau software. J'aime particulièrement développer sur FPGA et SOC.

Pour plus d'informations ou pour me contacter, vous pouvez consulter mon site web : http://monsinjon.paul.free.fr.

= Participation à l'association Armadeus =

Je possède une [[APF27]], sa carte de développement [[APF27Dev]] ainsi que l'écran [[LQ043_Adapt]] et le touchscreen [[TSC2102]] (équipé quoi !).

== 2008/2009 ==

En 2008, j'ai réalisé une carte d'interface [[User:YoannC#R.C3.A9alisation_avec_Armadeus_:_Club_Robotnik_Coupe_2009|présentée ici]]. Celle ci permet de connecter divers éléments d'un robot à l'[[APF9328]], en particulier :

* 2 moteurs à courant continu
* 2 codeurs incrémentaux
* 3 servos moteurs
* 3 modules SF05 (modules ultrason)
* 1 boussole numérique
* 1 switch de reset connecté au FPGA
* 1 switch DPDT pour la sélection d'une configuration de match (ici, la couleur)
* 1 switch relié à un jack pour le "top départ" du match
* 8 switchs DIL de configuration
* 8 leds qui servent à rien (éventuellement à debuguer !)
* Un afficheur 7 segments
* Et enfin 2 entrées supplémentaires en 5V.

== 2009/2010 ==

Ayant fait récemment l'acquisition d'une carte, je compte continuer à développer l'interface entre armadeus et un robot mobile. En particulier je compte réaliser une carte fille possédant les fonctionnalités suivantes :

* Reprendre une bonne partie des fonctionnalités de la carte précédente
* Monitoring tension et courant de batteries (LI-PO) et circuit de protection via un AT90CAN32 et le bus CAN.
* Intégration dans une partie dédiée des interfaces de puissance (ponts en H, commande des actionneurs etc.)
* Augmenter la modularité de la carte en ajoutant des entrées (capteurs de types différents, nombre de codeurs incrémentaux augmenté etc.).
* Éventuellement intégrer un circuit dédié au traitement d'image (DSP/DSPic) et à la gestion des capteurs.

Pour schématiser, le processeur ARM s'occuperait de la gestion globale du robot (stratégie, interface IHM via l'écran, gestion du CAN). Le FPGA quand à lui serait entièrement dédié à l'asservissement en position du robot via des FPU. Si possible celui-ci gérerait également l'ensemble des capteurs et pourrait faire de la vision (mais j'ai un doute par rapport au 200k portes ! d'où l'idée d'un circuit dédié à base de DSP).

User:PaulM

2009-09-15T12:09:07Z

PaulM: Création de la page personnelle de PaulM / PaulM's personnal page creation

[[MemberList | Liste des membres]]

= Présentation =

[[Image:PaulM.png|100px|left|Photo de Paul MONSINJON]]

Je m'appelle Paul MONSINJON, j'ai 22 ans et habite à Rennes et en région parisienne (seine et marne). Vous pouvez me croiser sous le pseudo polo35/Hebus.

Actuellement en dernière année d'études à Glasgow en Ecosse, je prépare un double diplôme en [http://www.insa-rennes.fr/eii Électronique et Informatique Industriel] à l'INSA de Rennes et un [http://www.strath.ac.uk/eee/ MEng in Electronics and Electrical Engineering] à l'université de Strathclyde.

Passionné d'électronique depuis mes 15 ans, j'ai toujours aimé concevoir et fabriquer des circuits électronique. Cela a commencé au lyçée avec ma première participation à une compétition de robotique ([http://www.planete-sciences.org/robot/index.php?section=pages&pageid=84 trophée E=M6 à l'époque]). Plus tard, j'aurai l'occasion de participer à la [http://www.planete-sciences.org/robot/index.php?section=pages&pageid=79 Coupe de France] grâce au club de l'INSA.

Mes centres principaux d'intérêt en ce qui concerne l'électronique concernent les couches hardware et bas niveau software. J'aime particulièrement développer sur FPGA et SOC.

Pour plus d'informations ou pour me contacter, vous pouvez consulter mon site web : http://monsinjon.paul.free.fr.

= Participation à l'association Armadeus =

Je possède une [[APF27]], sa carte de développement [[APF27Dev]] ainsi que l'écran [[LQ043_Adapt]] et le touchscreen [[TSC2102]] (équipé quoi !).

== 2008/2009 ==

En 2008, j'ai réalisé une carte d'interface [[User:YoannC#R.C3.A9alisation_avec_Armadeus_:_Club_Robotnik_Coupe_2009|présentée ici]]. Celle ci permet de connecter divers éléments d'un robot à l'[[APF9328]], en particulier :

* 2 moteurs à courant continu
* 2 codeurs incrémentaux
* 3 servos moteurs
* 3 modules SF05 (modules ultrason)
* 1 boussole numérique
* 1 switch de reset connecté au FPGA
* 1 switch DPDT pour la sélection d'une configuration de match (ici, la couleur)
* 1 switch relié à un jack pour le "top départ" du match
* 8 switchs DIL de configuration
* 8 leds qui servent à rien (éventuellement à debuguer !)
* Un afficheur 7 segments
* Et enfin 2 entrées supplémentaires en 5V.

== 2009/2010 ==

Ayant fait récemment l'acquisition d'une carte, je compte continuer à développer l'interface entre armadeus et un robot mobile. En particulier je compte réaliser une carte fille possédant les fonctionnalités suivantes :

* Reprendre une bonne partie des fonctionnalités de la carte précédente
* Monitoring tension et courant de batteries (LI-PO) et circuit de protection via un AT90CAN32 et le bus CAN.
* Intégration dans une partie dédiée des interfaces de puissance (ponts en H, commande des actionneurs etc.)
* Augmenter la modularité de la carte en ajoutant des entrées (capteurs de types différents, nombre de codeurs incrémentaux augmenté etc.).
* Éventuellement intégrer un circuit dédié au traitement d'image (DSP/DSPic) et à la gestion des capteurs.

Pour schématiser, le processeur ARM s'occuperait de la gestion globale du robot (stratégie, interface IHM via l'écran, gestion du CAN). Le FPGA quand à lui serait entièrement dédié à l'asservissement en position du robot via des FPU. Si possible celui-ci gérerait également l'ensemble des capteurs et pourrait faire de la vision (mais j'ai un doute par rapport au 200k portes ! d'où l'idée d'un circuit dédié à base de DSP).

File:PaulM.png

2009-09-15T12:06:12Z

PaulM: Photo de PaulM (Paul MONSINJON).

Photo de PaulM (Paul MONSINJON).