original Issue by @Stapelzeiger:

while running a bootloader ping through the master board it crashed at an assert at chsys.h:318.
The comment above the assert says:

The following condition can be triggered by the use of i-class functions
in a critical section not followed by a chSchResceduleS(), this means
that the current thread has a lower priority than the next thread in
the ready list.
ch.rlist.r_current has prio 3 (must be the TCP thread),
ch.rlist.r_queue.p_next is the uavcan thread and has prio 64

I quickly checked all use of I class functions in our code and didn't spot any obvious problems.
the two thread structures look ok, so no memory corruption of the thread working areas.

For some reason Travis version of clang has a broken c++ library. I disabled Clang's build in ae47b7c but it would be good to re enable it later.

Possibly relevant links:

• catchorg/Catch2#334
• Andersbakken/rtags#204

• Split in modules
  • Lie groups
  • Hardware interface
  • Controllers
• Improve arm API

MVP1 should provide this behavior:
Given: The camera (with embedded computer) is rigidly mounted on a beacon spot
When: It is turned on
Then: It detects the position of the color sequence in the image, and determines the color sequence

• Marker detection
• Camera pose computation
• Color sequence 3D->2D projection
• Color segmentation
• Display results

See #101

Sometimes the opponent is detected very close to the robot and it will think it's inside the opponent bounding box obstacle. The robot should be able to first get out of this situation before recomputing a path to its goal.

Currently the beacon handling code assumes (incorrectly) that we are always moving in XY mode, but angle_* and d_* mode are very useful and we should handle them.

See: trajectory_helpers.c.

We should add some locks around all operations manipulating positions. I personally believe it should not go in the module source code itself, but rather around every caller site.

Wire lever module, includes:

• 1 CAN IO board for the servo (with micro-switch)
• 2 Motor boards for the pumps

The goal is to be able to visualize the state of the robot:

• the map of obstacles
• the position of the robot
• the path found

I hope you can tolerate my intrusion here, I'm just looking for friendly open source projects that leverage the ChibiOS's USB stack. The reason is that there appears to be a serious issue with the USB stack that may crash the OS under certain conditions; it is described here: http://www.chibios.com/forum/viewtopic.php?f=25&t=4568

So far the issue was observed on ChibiOS 16.1 running on STM32F105, STM32F373, and STM32F446. As can be seen in the linked thread, Giovanni is reluctant to take action until the issue is confirmed on newer revisions of the RTOS. Seeing as you're using version 17.6, perhaps you could spare half an hour to run a simple test described in the thread? That would be supremely useful for ChibiOS users in general.

Thanks!

as discussed tonight the motor firmware needs to be reimported to preserve history and allow for easy git logging / bisecting. @nuft are you volunteer for doing it ?

We should have a CVRA fork of all dependencies.

A memory related problem appeared recently when I tried to add support for additional motors on the bus (to support all motors in Debra's arms). This issue was not related to a specific motor but rather to the number of motor drivers used.

With the help of @Stapelzeiger @nuft, we successfully identified the issue in the motor driver where new failed because of lack of memory. A temporary fix is to free some place on the heap by reducing the size of trajectory buffers (from last year).

Long term solution:

• Remove trajectory buffers as we don't use them anymore (they were meant for using the master board as IP-CAN relay)
• Move thread stacks to CCM
• Reduce obstacle avoidance internal buffer to accommodante enough obstacles for the competition, but not too much.

So we have something in log.h and something in aversive/error.h. One logging system should be enough for the whole robot I think ;)

I think Aversive's one is more feature rich, we can be both good and bad. In any case it should be cleaned up and maybe simplified (There are definitely some features we don't need).

What do you guys think ? Any reason to keep our own logger ?

I volunteer to cleanup/test/put everywhere Aversive's one should we decide to keep it by the way.

The current setpoint publisher (part of cvra_studio pid_plot) was rushed, so it's missing some features:

• The node is addressed by ID, should be by name through a list of available nodes
• The setpoint should be either symmetric or not (alternate value and 0), currently it's symmetrically alternated only (positive/negative)
• Dump config to yaml for easier PID tuning

The screens showed their potential for debug outputs when we used them as console. I think they can do much more, especially if we make use of their touch part. Then we could have real panels for things such as arm position, robot position, beacons, etc.

Wire the new arm, includes:

• 2 Motor boards for elbow and shoulder
• 1 Motor board for the pump
• 1 CAN IO board for the servo

This should allow us to view waypoints when we select them (plot on the map) and improve the workflow of writing / tweaking strategy code.

• Inject a struct pointer to all oa function calls
• Explicitly handle ownership of oa in the map server thread
• All queries to oa should be properly synchronized.

The control panel LED names don't correspond to their true function.
And as we're at it, we should label them also on the robot hardware.

https://github.com/cvra/robot-software/blob/master/master-firmware/src/scara/scara_trajectories.c#L50

• Power CAN bus (5V) through Master board dedicated connector
• Get rid of Y connections over CAN bus
• Get rid of loops in CAN bus connections
• Fix arm pump bad connection (over CAN)

Problems with obstacle definition, we need to define all missing obstacles in the map

So it appears to me that the config.c file from master firmware has a lot of boilerplate code that can probably be autogenerated from config.yml anyways. So we should do that.

I think this can be a good beginner project for someone interested in build tools (nobody is interested in build tools?)

Many configuration parameters for different subsystems are accumulating in the Makefile.
In my opinion this is a bad practice and those parameters should be independent of the build system.
I propose to move them into header files grouped by topic.

example from master-firmware:

# List all default C defines here, like -DDEBUG
DDEFS += -DUAVCAN_TOSTRING=0 \
		 -DUAVCAN_STM32_NUM_IFACES=1 \
		 -DUAVCAN_STM32_TIMER_NUMBER=2 \
		 -DUAVCAN_STM32_CHIBIOS=1 \
		 -DUAVCAN_TINY=0 \
		 -DLWIP_DEBUG=1 \
		 -DSHELL_MAX_ARGUMENTS=5 \
		 -DSHELL_CMD_THREADS_ENABLED=FALSE \
		 -DSHELL_CMD_TEST_ENABLED=FALSE

Requires:

• Functional driver for LCD screen
• Display numbers on the LCD screen
• Mounted LCD screen on the robot
• Wired LCD screen on the robot
• Count points in strategy and display current score asynchronously

I see that all the individual projects are littered with {build,test}.sh files, that seem to sort-of automate the build of the project. I feel like this belongs to the developer's own automation and we should not put that kind of stuff in the repository, but I would like to hear the team's own arguments for this: what are your feelings on this guys ?

Score counting #99 is now live on the robot, but it would be better to do it by watching the goap state instead of increasing it in each action execution.

• Motor monitor
• PID feedback live plot
• Parameter read/set
• Make proper python package
• Save params
• Support Master board PID tuning

We have a lack of logging on our robots:

• We need to log more, use DEBUG for internal logging.
• We need to enable SD card storage of logs again.
• We need to be able to retrieve saved logs via ethernet (reenable the http server).

I think the config loading should be documented somewhere in this repo.
Or even better, write a python package with tools to interact with a motor board (like we have for the CAN bootloader).

We only handle one opponent in the map and the dynamic avoidance.
It would be good to support two opponents (i.e. distinguish two beacon signals from two different reflectors and so on).

We only use chibios-syscalls in the can io firmware, others use the default syscalls from ChibiOS.

This should be more uniform.

http://178.32.216.117:8000/cvra/robot-software/294

So as you all know, we had some issue to properly tell GOAP "Please do not do this action before XX seconds into the game". We tried hacking something, but it did not work somehow.

What I personally see would be to put the time constraint in the can_run method, where we would compare trajectory_get_time() > 80 for example.

Another option would be to put the time in the state, but then I am afraid that GOAP would just do stupid actions "waiting" for the time to come instead of staying idle / trying new goals.

MVP2 should provide this behavior:
Given: The camera (with embedded computer) is rigidly mounted on a beacon spot
When: It is turned on (power on of the whole module)
Then: It determines the color sequence and streams it regularly via a wireless connection (TBD) to the robot(s)

We need to choose how to store and load the configuration of different robots. Do we use config.yaml for everything and remove all the defines.
There are common parameters and ones that are specific to each robot. How do we separate those ?

When the arm tries to execute a trajectory but is blocked by a physical obstacle it hangs.

We need to have two trajectory windows:

• coarse windows, so we can smoothly transition between two consecutive waypoints.
• fine windows, to allow more accurate positioning on final waypoint.