cvra / modules-old

The library made for the differents robots by the CVRA

CVRA NIOS 2 Code & libraries

To build on Linux (should work on any UNIX, but not tested) :

cd /path/to/repos/
mkdir build
cd build && cmake ..
make

To build just for a single robot :

make debra
make nastya

Cross compiling for the robot is more complicated, as for now we dont have any standard makefiles to cross compile. For now you should create a blank project in Nios II SBT, and then add all the C files to the build by right clicking them and choosing "Add to NIOS II build...". Then you can add the subfolders of modules to the include path (look in the Makefile for ALT_INCLUDE_DIRS). In the long run we will probably setup our own system to be able to cross compile with nios2-gcc only, without using any other Altera tools.

Organisation of the source code

The source code is organised like this :

nios2
|-- debra
|-- doc
|-- include
|-- modules
|-- nastya
|-- nios_files
|-- tools

• The debra folder contains all the source specific to our first robot (the one with the arms).
• The nastya folder contains all the source for our holonomic robot.
• The include folder contains a few generic includes.
• The modules folder contains all generic modules and a lot of code taken from Aversive.
• The tools folder contains various tools for developpers.
• The nios_files folder contains all the binary files generated by Quartus II from VHDL.

Useful warnings

• When building for the NIOS 2 system, do not assume that the compiler will zero out memory before giving it to you. It won't.
• Do not do any rebase / rollback of already pushed commits.
• The NIOS 2 compiler hates you. Really.

Contributing

If you are from CVRA, ask Antoine to give you commiter access. If you come from an external club (omg a contributor, welcome!), please open a pull request.

In both cases, it is really important that you configure your Mercurial client to have the right user setting. We want your user settings to look like this : FirstName LastName <[email protected]>. The < and the > must be in the username. This is required by Bitbucket to properly match your account to your commits.

modules-old's Issues

Add a real obstacle avoidance system

We need a real avoidance system for the cup because stopping when we see an opponent is not an option.
I think the best way to start is to check what Microb Technology did for Aversive and then adapt it to our needs.

arms dont do quadramps.

so apparently, doing sudden moves is really bad for the robot according to the mechanics team. Smoothstepping[1] the interpolation makes the jerk less visible, but is sub-optimal. A better fix is needed, probably using a quadramp for Z axis and smoothstep for XY.

[1] : http://en.wikipedia.org/wiki/Smoothstep

blocking detection manager fails after setting acceleration.

I was debugging strat_autopos() and I got the following bug : If I changed the acceleration at the end of the function using traj_set_acc for some reason the blocking detection manager would refuse to allow the robot to do any movement.
Removing the call to traj_set_acc removed the problem and I have no time to investigate it at the moment, so i am opening this issue to remember it.

Use of strtok

strtok (3) is used in the commandline module and is not re-entrant. We should switch to strtok_r, which is reeentrant.

source : http://linux.die.net/man/3/strtok_r

Add a system to calibrate Z axis

We need a system to calibrate the arms automagically using current as stop switch because @izeaf is having too much fun calibrating the arms ;)

Review parse module

Is this module still used ? Is it thread safe ? So much questions, so few answers.

Add an IRQ-safe getter to CVRA beacon.

Current method of accessing the data from the beacon is not safe. We will change it to add a getter that disables interrupts before reading.

Add the option to dynamically change the arm length

One should be able to change the arm length during the trajectory. This would be useful to handle approaches. I think the best way to do it is add it to the keyframe_t structure. We will have to do it for 2014.

Nastya's odometry

Nastya's odometry needs to be trimmed. If we're already at the hardware's limit, we need to add a gyroscope and do some sensor integration by Kalman filter.

Implement communication between the camera and the robot

Debra and the camera should be able to communicate via Bluetooth. Otherwise we wont be able to work on the candles.

Create a script to patch Altera's Makefile

Modifying the Makefile by hand when starting a new project is a tedious process. I think an automatic process would be a huge improvement.

Ideally, this script would also document better the process of creating a new project, which would come very hand when I will go to the army...

More Issues

we reaaaaaally need more issues (=

Calage du robot

Le robot holonomique ne se cale pas. On doit pouvoir le faire avec les courant des moteurs et c'est indispensable si on veut faire des points

Fix the reset

The reset() function makes the robot crash. It should make it reset.

Servos fail before battery is empty

The servos seems to stop working before the battery is empty (the rest of the robot is still operationnal), as replacing the battery solves the problem.

Check fast_math for thread-safety and statics.

1. All global variables should be static.
2. Is this module thread-safe ?

Nastya's trajectory

Nastya's trajectory manager needs to be able to do rotations and translations at the same time.

Implement overheating protection

The robot can use current sense to protect its motors, so we should implement an IIR[1] filter to compute the average temperature of the motor and shutdown it if necessary.
It should be done quickly to allow for some testing.

[1] http://en.wikipedia.org/wiki/Infinite_impulse_response

Make control_system_manager thread safe.

Title says all.

commandline history display bug

When navigating the history, the display is not properly refreshed and "eats" the line above the last one of the screen. Could be a problem of nios2-terminal, but would be nice to have it fixed.

Split repositories

We need to split repositories between Nastya, Debra and modules. This would allow us to have a nice separation between common code and robot code, while still being easy to integrate, thanks to hg submodules.

It need to be done cleanly, because we want to keep history of the project. We can do that using hg convert with a filemap[1].

I wrote the beginning of a script to do that. It still needs to be tested and documented before deployement. See attachement for details.

We also need a way to transmit issues. According to [2] we can export issues. We need to investigate if we are able to filter issues by component or if we need to write our own filter using the information available in [3].

[1] http://mercurial.selenic.com/wiki/ConvertExtension#A--filemap

[2] http://blog.bitbucket.org/2013/04/02/finnovation-brings-you-a-heap-of-new-features/

[3] https://confluence.atlassian.com/pages/viewpage.action?pageId=330796872

Arm have some weird glitches

When passing around x=0 or y=0, the arm make sudden moves. Still got to investigate, but non critical for post belgium cup.