tooploox / autonomous_car_model Goto Github PK

The current description of the robot isn't realistic. The actual robot has one joint responsible for steering and one actuator responsible for driving all wheels.

In the current URDF description, there are two joints for steering wheels separately and actuators for each wheel have to be accessed directly to drive them.

The structure of the robot described in the URDF should be modified so:

1. It has one joint responsible for steering.
2. It has one joint responsible for driving all 4 wheels.
3. Meshes used for visualization should remain unchanged.

Here is a good example of proper definition for a robot with Ackermann steering: https://github.com/srmainwaring/steer_bot/tree/c86232658df84a8d3518b480a468e8a260754c9c/steer_bot_description/urdf

As we'll potentially have multiple robots of the same kind it should be possible to support all of them with minimal changes in the codebase.

1. The launch files should be parameterized.
2. URDF descriptions should be created with xacro macros.
3. Messages returned by sensors could include additional information so the nodes responsible for acting upon them would;t have to know about the specifics of the robot (i.e. that the robot XXX sensor "a" is mounted 10 cm above ground on the front of the robot, etc.).
4. Ideally if multiple robots could use the same hardware interface.
5. Possibly the structure of some nodes should change, as well as the names of directories, etc.

As described in the referenced issue, ackermann controller doesn't process angular velocity from Twist messages in any way. I guess it wasn't supose to work like that. We. should update the controller ourselves.

ros-controls/ros_controllers#412

OpenGL or another library could be used to visualize the robot's heading and pitch, yaw, roll values in 3D implemented for the web interface we're currently using to steer the robot.

The main purpose of this would be learning OpenGL and utilization of accelerometer, gyroscope, and magnetometer data.

Interrupts should be used instead of while loops. Here are tutorials: https://raspi.tv/2013/how-to-use-interrupts-with-python-on-the-raspberry-pi-and-rpi-gpio-part-3

It was observed, that certain parts of the model show some kind of shivering. Especially:

a) Wheel contact points:

b) Shaking inertias of front wheels/steering wheels system:

These issues may, but not necessarily, be associated with each other. One of the suspects is low mass of the links, which may cause numerical instability in simulation, but rear wheels do not show the shivering mentioned in b).
The issues were initially introduced in #2, but since debugging of these phenomenons is probably more time-consuming and low-level, so in order not to block remaining improvements/fixes from #2, they were separated out to this very ticket.

While investigating another issue, it was observed, that the plugin throws the following log while the gazebo environment is spawned:

[ WARN] [1621862786.654135772, 0.351000000]: Joint limits won't be enforced for joint 'front_left_steer_joint'.
[ WARN] [1621862786.654197421, 0.351000000]: Joint limits won't be enforced for joint 'front_right_steer_joint'.

According to code overview, the joints mentioned in the logs below should actually be ignored in limit-checking loop (since the joints are virtual).

This might turn out to be a bug in plugin, but since it does not actually cause any serious trouble, it does not need to be immediately investigated.
However, this could be looked into in by-the-way mode, when someone will need to do something more urgent with the steerbot gazebo plugin.

We should think of a solution for working on the project also on macs. Maybe working in docker will be the only way.

Currently the steering and drive motor responds directly to messages sent to /cmd_vel topic. What's more, the node ignores what the values in the message actually represent.

To be able to use external ROS packages a hardware interface supporting our robot must be implemented.
Note: it must be done in C++, Python is not supported.

We should implement tests on all levels:

1. Individual nodes (use language-specific tools to perform the tests)
2. ROS communication (use ROS tools)
3. Integration tests (use ROS tools)

Add, lidar, magnetometer, motor encoder, possibly motor temperature sensor.

As the model behaves strangely in simulation I guess there's something wrong with its description and/or physical properties defined in URDF (collision, inertia, and joints tags in general should be checked).

Potentially helpful resources: http://gazebosim.org/tutorials/?tut=ros_urdf

It should make more sense to resolve #1 first.

The currently used ROS distribution is the Melodic. It was prebuilt for ubuntu 18 and can be used on Jetson out of the box, but it doesn't support Python3 and it's annoying at least. Also, Python2 will end its life in 2023 anyways, so we can help it die faster.

At the same time we could test ROS 2, but first let's make sure that everything is working in ROS 1. Transition to ROS 2 might be complicated as we're using less popular controllers (Ackermann steering), and javascript libraries that may not work with ROS 2 yet.

Currently, the dependencies for python are not listed anywhere. External ROS dependencies also don't seem to be managed well. It's worth looking into how to use rosdep, as well as preparation of the environment.

Refer to http://gazebosim.org/tutorials?tut=ros_gzplugins for more info.

At least a front camera should be added to the robot in the first interation.

The #1 should be resolved first.

There is already one world created but it uses only assets available in Gazevo library.
It would be more realistic to create our own assets (maybe recreate some parts of our offices?).

Creating worlds with static objects or Gazebo can be quite relaxing. It may involve modifying 3D models obtained from various sources like https://www.turbosquid.com/ in blender or similar software.

For a long-term project with multiple participants, documentation is essential.
The challenge here is that the project consists of multiple subprojects and will be developed in at least two different languages (Python and C++).

I suggest using Sphinx with Breath plugging https://breathe.readthedocs.io/en/latest/. The documentation generated with Sphinx can be very readable, looks pretty and we can integrate it with https://readthedocs.org/ service for easier access.