Open source hardware project announcement: FXIMU, imu sensor board for ROS

General
1

Dear ROS users,

I would like to announce the Fximu2 project: Fximu is a IMU board that uses the FXOS8700, FXAS21002 as sensors and an Arm Cortex TM4C123GH6PM as microcontroller.

Here is project page: https://github.com/altineller/fximu2

We have ported ROS’s imu_complementary_filter on to the embedded TM4C123 platform, and created ros software to configure the sensors and complementary filter over ros parameters, so the device could be used by 3rd parties, without requiring firmware update.

Basically, it is a small, easy and cheap to build IMU sensor board, that directly plugs into Usb port.

I needed a Imu sensor for my project, I was not happy with the results I got from different sensor boards I tried, and decided to build my own, based on the above chipset, and the manufacturer claims noise characteristics are 100 times better, after being disappointed by the hardware DMP (digital motion processing) features of few sensor chips I experimented, I decided to use a simpler, and cheaper chipset, and do the filtering myself. In the first version, raw data from sensor was used to feed ros’s imu_complementary filter, which worked quite well, much better than madgwick or dcm algoritms that you can find in imu boards that does the processing on-board. After realizing running the filter on another host causes latency, I decided to port ros’s complentary filter to TM4C123, a microcontroller unit that has a floating point processor.

Gyro, acceletometer, and magnetometer sensors are read at 400hz, and the complementary_filter running on the embedded microcontroller, it publishes standard Imu and MagneticField messages over rosserial.

The device shows up as a virtual serial port, since it encodes itself as a usb hid device, requiring no drivers, or ros software, it will directly publish at ‘imu/data’ and ‘imu/mag’

All parameters from output rate, to sensor config to complementary filter parameters are configurable over ros param, with a yaml file.

It has a calibration mode, and software wrapper, that can take the ros message, and send it to another virtual serial port, by using unix program ‘socat’, so one can use off-the-shelf software for calibration.

I woud like to colloborate with other people on this project. I prototyped the circuit for my own use, but after realizing that it could be useful to other people, I built a full circuit, that is configurable for every need.

I would like to start an open-source hardware project, and keep both the software and hardware open.

I am asking the communities help with this.

Best Regards,
Can Altineller

8 Likes
2

Hi Can!

Very interesting project! There is definitely quite a niche in the IMU space. I didn’t find a <100$ option that worked well for me either.

I wouldn’t be able to help on the hardware side myself but if you had some spare prototype I would be willing to buy it from you and help testing / working on software and spreading the word about it on Weekly Robotics.

Best regards,
Mat

1 Like
3

Hello,

Thank you for your comment. I have some more PCB’s and I can send one to you, along with the montage diagram, and Bill of Materials, and all you need to do is get parts from an electronic distributor, and find someone in a local hackerspace who can do SMD soldering. I will even put in some parts, like the usb connector and the crystal for the microcontroller.

I am updating the design right now, and I will have new pcbs manufactured with slight improvements on ergonomics, and addition of a i2c port, (for putting a satellite sensor, like another magnetometer, and then fusing in) - If you like to wait for that one, I can send that one too.

Right now, I am making the boards with hand. As soon as I get a first batch produced, then I can send the whole working device.

Please contact me for details

4

Looks pretty cool. I’ve never known you can just use functions like initNode, advertise etc. in a bare-metal environment.

Is it actually documented somewhere for ros (and maybe also for ros2) what can be done in bare metal, and what requires POSIX environment?

5

hello @oytis

I am using rosserial_tivac. It allows the use of ros objects and messages on the TM4C123. There is also ros_embedded which could be more suitable for your requirements / platform.

6

Very nice project, the robotics/maker community truly lacks open affordable AHRS!

Did you take measurements of the CPU load? In comparison to the Sparkfun 9DOF Razor equipped with a Cortex M0+, is the M4F not ‘overkill’ for running the filter, or communication costs on the load significantly?

Matt

7

Hello,

I have not made load measurements on the microcontroller yet. I am planning to do so to better the memory and performance of the filter. At 400hz, there is not much time for updating the filter, reading the sensors, etc. The main diffuculty was to get both of sensors generating interupts, and the MCU being able to proces them syncronously.

I dont think the tm4c123 is overkill for the project. It does play nice with floating point numbers. It can be programmed with Energia, CCS, or gcc. [gcc and catkin in my case.] TI has excellent support, and they have helped me debugging sensor problems. The TM4C123 costs only 5usb if purchased by 1000’s. The unit also has an expansion port, so it is nice to have some extra programming space, for things like rosservices that could be convenient.

I have looked at sparkfuns 9dof razor, with the cortex 0+, and they seem to be using the DMP on the mpu9150 for filtering. The last time I worked on a mpu9150 was 2 years, and maybe they are better in new batches, but ros’s complementary filter is much better than the DMP on that device, and the dmp is not tunable, like the ros’s complementary filter. We are running ros’s complementary filter on the TM4C123, and it is a lot of processing. Most Imu’s that I know of use either compdcm, or madgwick method on their mcu’s.

About communication costs: Since I am publishing standard Imu and Mag message, and since those have covariation matrices, Imu (3), Mag (1), some bandwidth is being spent for nothing. I did it like that for convenience, so the user would not have to compile and install custom message types. In the previous version, (also in github) this was the method I was using, to be able to publish sensor data upto 400hz.
So right now, sensor is read, and filter is updated at 400hz, and output published at 100hz. (for 230400 baud - and the usb hid on that chip can go 4 times that.) But still publishing standard messages with empty covariance matrices, is a performance penalty in terms of communication.

Best Regards,
Can