Using hFramework package

Hi there,

I was looking to build the hFramework package for ubuntu using the instruction on this website GitHub - husarion/hFramework: hFramework is a library for creating real-time software for robotic & mechatronic devices. I tried following the steps at the bottom but immediately got the following error in the terminal at step one:
apt-get install cmake ninja-build gcc-arm-none-eabi
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

Also the link that should take you to the tutorial on how to use the hFramework library gives a 404 error. Is there another way to access this library?

The purpose of this is to access data of the rotational speed of the wheels of the rosbot 2.0. When we used to work in the cloud, the ROSbot.cpp file in this package gave us this data, however it does not seem to work the same way in ubuntu. Any tips would be greatly appreciated.

Kind regards,
Thijs

Hello Thijs,

Command apt-get install cmake ninja-build gcc-arm-none-eabi needs to be executed with root permissions, e.g. with sudo:

sudo apt-get install cmake ninja-build gcc-arm-none-eabi

The link was broken indeed, thank for pointing this out. I just fixed it, proper link is: https://husarion.com/tutorials/other-tutorials/hframework-library-development/

Regards,
Łukasz

Hi Lukasz,

Thanks, this solved my initial problems. However I’m still struggling to implement the package properly. Do you know if there is a way to access data regarding the rotational speed of the wheels without the cloud or the hFramework package? An idea was to relate positional data from geometry_msgs/PoseStamped to velocity, but i found this method to be very imprecise.

Thijs

Hi Thijs,

There is no need to use cloud, but it is necessary to use hFramework. In fact, interfacing with ROSbot low level interfaces (motors, encoders, IMU, distance sensors) is based on hFramework.
In ROSbot class there is used Wheel class for controlling motors.
Wheel class provide method getSpeed() which returns wheel speed in encoder pulses per second.

Regards,
Łukasz

Hi Lukasz,

We got hFramework to work by following the instructions, but we would now like to use hFramework within our existing nodes and packages. Whenever we try to implement this however we get errors, which are probably linked to the cmakelist.txt file. Do you know how we should alter our pre-existing cmakelist in order for it to also support the hFramework library?

This is our current cmakelist.txt:

By the way, we appreciate all the help you have been giving us for the last couple of weeks, so thanks for that :slight_smile:

Regards,
Thijs

Hello Thijs,

It is not possible to use hFramework in ROS catkin project, it requires its own build process.
The hFramework is dedicated for STM32 microcontrollers, which is on CORE2 board.
Workflow for using hFramework with ROS system is:

  • build hFramework project using VSC plugin or cloud IDE
  • flash project onto CORE2 board
  • start roscore on TinkerBoard
  • start serial bridge /opt/husarion/tools/rpi-linux/ros-core2-client /dev/ttyCORE2 on TinkerBoard

CORE2 board is connected with TinkerBoard through serial port which enables two way communication.
Serial bridge node connects to serial port and publishes or subscribes ROS topics which are available to other nodes built in catkin workspace.

Regards,
Łukasz

Hi Lukasz,

The reason we want to connect hFramework to our existing nodes is to access the IMU data, which is not possible without hFramework from what I understand.
Im just curious of why it wouldn’t be possible to access encoder data without flashing and using vscode. Right now we can get a lot done without it and I don’t see how suddenly this part should change that up, since this method is pushing us into a very specific and also restricted direction. I feel like there has to be a way to get encoder data while still using nodes and launch files, since that is the more open approach to working with ROSbots.
I have attached one of our packages so you could get a more general feel of how our scripts are set up, since i feel like there should be a way to publish encoder values and subscribe to those topics in our main nodes.

I would like to know your opinion on how we should continue to approach this subject.

Regards,
Thijs

Small note: this is an adaptive cruise control package. spd is our ‘real speed’, which is too imprecise the way we calculate it right now. That is the part where we would like to access wheel encoder data

Hello Thijs,

The CORE2 board (with STM32) and TinkerBoard are different hardware platforms.
Software built for CORE2 can not run on TinkerBoard and software built for TinkerBoard can not run on CORE2.
Encoders, motors, IMU and distance sensors are components of CORE2 hardware platform, they can be accessed only on CORE2.
It is not possible to access encoders, motors, IMU or distance sensors on TinkerBoard directly, as there is no applicable hardware interface to handle such devices.

TinkerBoard can access encoders, motors, IMU or distance sensors only using serial bridge by publishing and subscribing ROS topics on CORE2. The serial bridge is node which translates data between CORE2 and TinkerBoard.

For your use case, I would consider moving the cruise control to CORE2 board. On CORE2 board you can access encoders and distance sensors directly as well as perform required calculations. Would it be suitable for you?

Regards,
Łukasz

Hello Lukasz,

Let me try to rephrase what you are saying to make sure I understand correctly. You are saying we should flash the cruise control onto the CORE2 using VSCode, like stated in the tutorial, because it is not possible to access the IMU data otherwise unless we change the serial bridge node so that the wheel encoder data can also be accessed by the Tinkerboard, since the bridge does not seem to do this at the moment.

If this is correct, then do we need to flash every node that uses the hFramework library onto the CORE2? And is it then possible to launch these nodes together with our other nodes on the Tinkerboard with a single launch file?

My last question refers to the actual flashing procedure using VSCode on Linux. The tutorial on hFramework library development states in step 13. (all the way at the bottom) that we need to replace the USB driver for our CORE2. Then it asks to download a windows USB driver but does not explain the required steps on linux. Could you clarify that for us?

Thank you.

Kind regards,

Thijs

Hello Thijs,

Let me try to rephrase what you are saying to make sure I understand correctly. You are saying we should flash the cruise control onto the CORE2 using VSCode, like stated in the tutorial, because it is not possible to access the IMU data otherwise unless we change the serial bridge node so that the wheel encoder data can also be accessed by the Tinkerboard, since the bridge does not seem to do this at the moment.

That is correct.

If this is correct, then do we need to flash every node that uses the hFramework library onto the CORE2?

Yes, it need to be flashed onto CORE2, but there can be only one node running on CORE2 at the same time.

And is it then possible to launch these nodes together with our other nodes on the Tinkerboard with a single launch file?

Node on CORE2 is running since it is powered on and will be running until it is powered off. It can be restarted by reset button or flashing new firmware.
Node on CORE2 starts to publish/subscribe as soon as serial brigde is started.
Effectively, starting serial bridge equals to starting node on CORE2, thus you can include serial bridge in your launch file to start it with other nodes on TinkerBoard.

USB driver installation is required only on Windows. For Linux version, default USB driver is enough for flashing process.

Regards,
Łukasz