State space model and controller

[ralphstirling]

Our robotics class is enjoying learning to use the ROSbots this quarter, and we are thinking about how we can use them in the Feedback & Control class next quarter. This course is primarily a state space control class. I’m looking for suggestions on the best place to use a state space controller in ROS and the ROSbot 2.0.

My first thought was at the level of wheel drive (rosbot_ekf?) with velocity command and encoder feedback, but looking at rosbot_ekf source on github looks like there might be a lot of extraneous aspects (IMU etc) that would distract from the basic task. Any ideas or examples that could help us?

Thank you.
– Ralph

[Adam_Krawczyk]

Hi,

First of all, I’m happy to hear, that you are enjoying our product.

Secondly, not sure what you really need, if you could explain better would be nice.

To straight things up, at this point, a low-level robot controller (core2) subscribes to velocity commands (/cmd_vel). PID, forward/inverse kinematics are calculated there so there would be a perfect place to make a controller using raw data, but I think it might be complicated to mess with firmware.

My idea is that you can build a simple Kalman filter using SS model and compare results to EKF. Second taught is to tune a little firmware giving it the ability to share data for every wheel separately and build a high-level python controller.

What do you think?

Best,
Adam

[ralphstirling]

Thank you, Adam.

I don’t think we plan to introduce Kalman filters in this introductory course. I think the ideal would be to have a new bottom-level core2 node that publishes wheel encoder counts (odometry), and subscribes to velocity commands (motor voltage level). A new ROS node that sits between the EKF node and this new core2 node would keep the rest of the ROS chain intact, so we could use it for traditional projects and the controls course assignments without reflashing the core2 board. I was hoping something like this already existed, as I’m not sure I’ll have time to get that done myself before the next term starts.

– Ralph

[Adam_Krawczyk]

Hi,

At this moment you can get information about every wheel from joint_states, maybe this will be enough.
Otherwise please feel free to change the firmware to match your own needs at firmware-repo, propably there.

In case of any troubles post an issue on a repo or email us.

Best,
Adam

[ralphstirling]

Thank you, Adam. Is the sampling rate for wheel rotation constant? I’m also a little worried about latency between publishing joint_states odometry, computing new wheel velocities, and updating the motor drive. Modelling these factors may be a little difficult.

– Ralph

[Hubert_Zwiercan]

Hi Ralph,

Yes, sampling rate for wheel rotation is constant, but like Adam said before you can easily modify our firmware and set needed frequency of publishing and subscribing any topics you like.

Firmware is handled by MCU inside ROSbot, encoders can handle up to 20kHz frequency, so possibility are very big. Please try to change the frequency of publishing for example one wheel to 100 Hz and check latency. I think that the value of latency will not be as big as you expect.

Please let me know the result of your tests

Best regards,
Hubert