ekumen-os / andino Goto Github PK

Summary

General goal: Build one(two if possible) robots.

To have in mind

• Each smart car kit contains a single chassis. We printed some extra chassis in order to build a two stories robots.
• While assembling it, it is recommended to take some pictures in order to later on document the process.
• Keep in mind wiring diagrams to better explain how things are expected to be connected: Pins from the arduino to be used will be decided between hardware and firmware responsables.
• We could create for example a carpincho_assembly folder for everything related to the assembly and documentation related.

General notes

• Block diagram
  
• BOM
• Google drawing

Summary

Good SW docs needs to be written so as to allow new CarpinchoBots to be built.

Definition of done

Create a markdown document including:

• ROS packages description
• Installation/setup steps
• HW interfaces
• ROS graphs

Summary

The current implementation of the Carpincho URDF has an offset between base_link and the front_right_wheel and front_left_wheel axis, this influences localization since the robot movement also gets affected by that offset.

The fix would be to modify the position of base_link to be between the wheels, sharing the same axis.

View of the base_link and the wheels

Definition of done

• Carpincho URDF file updated with the correct values.

Hey team,

I'd like to propose we remove the andino_ prefix from the different folders, as it becomes a bit redundant.

Summary

This tasks involves developing a base project for the robot firmware.

Basic structure:

• include
• lib
• src
• test

Configuring PlatformIO or a similar framework to be able to develop using VSCode instead of specific IDEs is desired.

Definition of done

• Base project is created and it can be built, downloaded and a test can be executed.

Summary

Adding test coverage makes the code more robust.
We could mock the microcontroller in order to provide some tests that guarantee that the hardware interface is working correctly.

Definition of done

• Provide a testing node that mocks the interaction with the microcontroller (two/three topics, for JointStates and joint velocities)
• Add a test for verifying a correct behavior.

Summary

This tasks involves designing the firmware solution in terms of classes and their interactions.

Definition of done

• Software is designed.
• Header files (and perhaps diagrams if required) are developed.
• Source files w/o inner implementation are developed.

Summary

Good HW docs needs to be written so as to allow new CarpinchoBots to be built.

Definition of done

Create a markdown document including:

• Assembly steps
• BOM
• HW diagram
• Electrical diagram
• Models for 3D printing

Summary

Enable nav2 navigation in Andino.

Suggestions

• Provide an andino_navigation package.
• Provide a basic launch file to bring up nav2: Check nav2_bringup launch file.
  • A configuration file is expected to be added to a config folder within the package for setting up different nav2's systems and to be loaded by the launch file.
  • Probably some topics in Andino/Nav2 should be remapped (or relayed)

Extras

https://arxiv.org/abs/2307.15236

Desired behavior

Add PlatformIO support to be able to build and upload the firmware using Visual Studio Code (by using the PlatformIO extension). Among other things, some advantages from doing so would be:

• No further need to install the Arduino IDE.
• Allows to add unit testing.
• Allows to support development boards other than Arduino.

Arduino IDE support for building and uploading the code shall remain as an easy and straightforward option to do so.

Desired behavior

Enable the use of a continuous joint in the simulation

Additional context

Here #100 the option was added

The id assigned to each usb device should be deterministic.
Example:

• USB0 -> microcontroller
• USB1 -> rplidar

Desired behavior

Unit tests shall be added to ensure regressions don't take place as the code evolves.

This issue require us to define who are the code owners of the project and who are responsible for approving PRs.

Environment

• OS Version:
• Source or binary build?

Description

• Expected behavior:
  • Wheel size is defined the same across all the stack
• Actual behavior:
  • Wheel Diameter is defined to 0.035 for Gazebo's diff drive plugin (here)
  • Wheel Radius is defined to 0.0331 (here)

Desired behavior

Provide a world for the simulation

Which world? To discuss here

Summary

Requirements file https://github.com/ekumenlabs/carpinchobot/blob/humble/docker/requirements.txt
isn't being used within the Dockerfile

Suggestion

• Copy and install it within the Docker image build.

Desired behavior

The caster wheel rotates freely when the robot moves

Implementation suggestion

Add a flag to XACRO to generate the required joints.
Keep default as is

For example:

• OS to use
• Packages to install
• Networking recommendations (Using ros domain?)

This PR #54 doesn't provide meshes for the visual of the camera.

Summary

• The robot description we are using is also one level while the real robot is expected to have two levels

Definition of done

• Replicate the real robot:
  • Add a new level

Context

We already have a gazebo simulation at noetic branch but it was an old implementation. The urdf description way different than the current one.

Summary

• Create gazebo ROS2 simulation
• Gracefully deal with urdf descriptions for:
  • real robot (ros2_control)
  • simulation using ros2_control
  • simulation using diff_drive plugin. (long shot, might not be necessary)

Notes

• an andino_gazebo package is expected to be created
• I expect no gazebo references to andino_description's urdf description. Gazebo references should be part of the andino_gazebo package.

https://github.com/marketplace/actions/run-on-architecture#supported-platforms

Description

• Expected behavior:
  • A single mesh is added to wheels, with different directives depending if scale is defined or not
• Actual behavior:
  • Meshes are added twice if scale is not defined

Steps to reproduce

1. Transpile Andino's xacro, and check the wheels' mesh field.

After a quick search throughout the repository, I've found some references to the previous name.

This task require us to rename those references in favor of the new name andino.

Desired behavior

Adds some smoke tests in andino_description package for processing the xacro files and checking that there is no error when doing so.

Summary

Create urdf for the carpincho bot.

Notes:

• Create base diff drive description

Bonus:

• Add camera link
• Add imu link

Desired behavior

Some source files, for instance the ones within the andino_firmware folder, don't contain the corresponding license note.

Desired behavior

Firmware code base shall be improved so as to ease its maintenance, decouple logic and drivers code (to ease the process of using a different dev board / microcontroller) and add unit tests.

TODO

Desired behavior

Add some gazebo references with colors for the meshes

Summary

This tasks involves modifying the standard Arduino Smart Car 3D design in order to include the required holes and avoid having to drill them after printing.

Definition of done

• Develop modified 3D model.

Summary

Good FW docs needs to be written so as to allow new CarpinchoBots to be built.

Definition of done

Create a markdown document including:

• FW diagram
• Installation steps
• Pinout diagrams
• HW interfaces

Environment

• OS Version: 22.04
• Source

Description

• Expected behavior: robot moving regarding command vels
• Actual behavior: caster wheel is stuck and don't move correctly

Steps to reproduce

1. Run Andino simulation on empty world,
2. move the robot and rotate.

Output

robot movement on gazebo is not regarding with the command vels. I will fix that commands

Desired behavior

• Provide some media about the simulation
• Refer the package from the root readme file.

Summary

The main Readme should work as an entry point to the entire project and documentation
The readme is expected to be improved over time as the project evolves.
For so here there is a list of things to tackle:

Requirements

• General description of carpincho project and motivation
• Installation process
• Hardware description
• Packages description/ repo organization

Summary

Using Gazebo ROS Control with the current robot configuration sometimes crashes the robot under specific movements, high values for the PID, or high-velocity commands being sent.

Different mass values improve the behavior, indicating that it could be an issue with the Inertia values and how Gazebo ROS control interacts.

Definition of done

• Gazebo ROS control works as expected.

TODO

This issue require us to set up a few guidelines on how to collaborate in andino. If we're creating an open source project, we should enable other developers to collaborate.

Summary

This tasks involves developing the firmware communication module that allows the communication between the microcontroller and the Raspberry Pi. ROS Serial over the USB port will be used to that end.

Definition of done

• Module is developed along with the required tests.

Summary

Motor needs to be controlled properly in order to guarantee later on good teleoperation and odometry readings.

• Inputs
  • Motor encoders
• Outputs
  • PWM signal to the L289 for motor control
    • PID controller should be set up for guaranteeing a correct motor driver.

General notes

• Note that there is a PID library for arduino that could be used instead of custom development
• Note that there is a Encoder library for arduino that could be used instead of custom development

Definition of done

• Define diagram connection between microcontroller - HBridge - Motor&Encoders
• Control motor velocity: It is expected to read the encoders in order to guarantee the correct velocity (radianxsec) for the motors.
• Encoder readings: Properly read encoder Information for calculating indirect info like current position and velocity of the motors .
• Add proper documentation:
  • Notes on design
  • Diagrams
• Testing

Summary

Some notes:

• Having a simulation is positive to simulate the navigation stack.
• Carpincho's software is using ros_control, meaning that the simulation is expected to match with these interface.
• There are two simulator targeted:
  • Gazebo: In general, for better integration with ros community, adding a simulation using gazebo might sound like the best approach
  • Webots: More performant and realistic(visual) sim than gazebo. Pretty used. We can push the simulation to the webots repos and the carpincho will be an integrated example in the Webots simulator (as of next release)

Definition of done

• Simulate model: Conversion from urdf to underlying simulator format
• Controller/Plugin set up: In order to properly simulate as a diff drive robot with the sensors that it has.
• Ros integration: It is mandatory to interface with ros.

Desired behavior

It would be nice to have a ClangFormat config file within the andino_firmware folder.

Summary

Go over real robot sizes and adjust urdf description.

Summary

The idea is to build up a well-documented, user-friendly, easy-to-use public repository. Where best practices are used in order to ease the way to new-into-robotics people and to serve as a demo/advertising of the company.

• Put everything together in a single open-sourced repository.
• Divide and conquer: provide several packages to tackle different aspects:
  • carpinchobot_description: containing the robot model.
  • carpinchobot_control: configurations for the diff_drive_controller of ROS Control used in Gazebo simulation and the real robot.
  • carpinchobot_navigation: to set up the navigation stack.
  • carpinchobot_slam: For performing slam with the carpinchobot.
  • carpinchobot_bringup: Containing launch files for bringing up the carpinchobot in the real robot.
  • carpinchobot_simulation: simulation of the carpinchobot
  • Etc.
    Documentation for the win.