Arduino lib for additional IMU

[samuk]

Description

Support additional common IMU

Definition of Done

Add support the IMU supported by this Arduino Lib: https://github.com/torehan/arduino-mpu-driver/blob/master/src/MPU.cpp#L153

[platisd]

What exactly do you want to do here?
Not sure I follow. 🤔

[samuk]

I want to make a robot that works with a variety of common IMU.

[platisd]

Usually a robot has a specific chip for its IMU, why would you want it to work with a variety of them in the first place?

Also, since this library already exists, why would we duplicate this work? At the best case one would need to interface this library your referring to with the Smartcar one, not integrate it.

[samuk]

I'm interested in making open hardware components that are useful to other hobbyists. One of those components may be a chassis loosely based on your platform

Similar in concept ro this https://shop.pimoroni.com/products/trilobot?variant=39594077093971 the manufacturer doesn't specify which I2C sensors you must use.

,The more components supported 'out of the box' the better the initial experience for the builder.

[platisd]

In the example you sent, they don't specify which sensors to use because they don't support any IMU sensors with their library. 🤷‍♂️

The idea of supporting "as many things as possible" is attractive in the development of any library or product, however it contains risks (e.g. it will be harder for users to discover the functionality they want if there's too much of it) and also requires a lot of maintenance.
Personally, if I don't know how a sensor works and don't see the need for making it a part of the Smartcar's hardware reference platform, it doesn't make sense to start supporting it software-wise.

This library instead allows for new sensors to be interfaced with it. I think I've mentioned this before, but if a class provided by the user implements the HeadingSensor interface, then it can be used along with the Smartcar library.

So my suggestion is to go one of the following roads:

1. Pick a sensor and provide support for it. If it's the GY-50 then support for it is baked into this library.
2. Don't provide any support and leave this responsibility for your users, allowing them to interface the software library with custom sensors.
3. Create a new library, eg Smartcar_IMU.h that wraps up those IMU sensors into new classes that implement the correct interface. Then the users can get that new library and use it along the Smartcar one.

I can provide some guidance for the last "road" but I'm not going to implement it myself since my time is limited.

[samuk]

Thanks, my thought is to adapt your 'motors' board slightly and make it wider so Nano ITX compute modules fit on it. Retain the position & electrical/signal compatibility with your existing inter-board connector headers.

The idea is users could start their robotics with your existing ESP32 modules board, but later stack an additional RPI or CM4 based compute module on top to run PythonRobotics or Linorobot2 these are the IMU supported by Linorobot2

I'd add pinout for three connector types Breakout garden, UEXT & mikroBUS probably leaving the actual connectors unpopulated in any board runs.

I realise there's no such thing as a universal robot platform, and there are risks in trying to be all things to all people. I am however drawn to seeing what's possible with modularity and testing the edges of interoperability.

I suppose this is a long-winded way of going for your 2) to focus on hardware, then hope that people find the hardware useful and improve the software.

I may of course just abandon the idea as overambitious, or I may get around to doing some PCB's.

[platisd]

Sounds good. Oh also, I don't know your background (mine is in software) but -electrically- the current PCB design is not optimal, e.g. the AA batteries are often not enough to power everything up.
Just something to keep in mind before repeating the mistakes I did. 😅

[samuk]

Yeah I've been browsing Lipo Your power traces are super thin too!

I think to make room for the Lipo the TB6612FNG would need to go on the underside of the board next to the motors.

[platisd]

Looking forward to see what you create 👍

[samuk]

Done a bit of thinking/hacking on this concept: https://github.com/rosmo-robot/smartcar_shield#proposed-smartcar-20-development

Thinking to go for two motor drivers to enable mecanum drive. Do you have any feedback on the concept before we start the proper PCB design?

[platisd]

Looks nice, where will the batteries go?

[samuk]

3S 2200Mah https://www.aliexpress.com/item/1005001419560964.html sits between the Motors board and the Modules board. (The motor drivers will be moved to the underside of the motors board to facilitate this)

~11.1v goes direct to the motors board. The modules board receives 5V USB direct from https://www.aliexpress.com/item/1005003593209704.html (or Via the RPI/Jetson/whatever if one is used)

[platisd]

Nice, just make sure everything fits I guess. Can't comment much on the "electric" part of things as I'm not the most knowledgeable. 😅

[samuk]

I think we've mostly finished the new 'motors' board

Ended up with quite a few changes compared your original;

• Dual SMT motor drivers
• On-board bucks
• LiFePO4 batteries
• 2 x 40pin board interconnect headers

We're tarting work on the 'modules' board soon: https://raw.githubusercontent.com/rosmo-robot/smartcar_shield/master/extras/images/modules.png

Optional SBC would mount above this.

I don't know if you have a preference for continuing to call this hardware 'Smartcar 2.0' or would you prefer it if we call it something different? Started a bit of documentation here: https://rosmo-robot.github.io/aboutme/

I'd quite like to call it 'Rosmo' but interested in your thoughts.

[platisd]

You're doing some great work, keep it up! 👍

And you can call it however you like, I at least consider it as novel work. :)

[samuk]

Progress on the derivative Rosmo board is happening slowly.

I've opened three issues which we need to resolve before the derivative Rosmo/ Smartcar2 robot will run your lib https://github.com/rosmo-robot/smartcar_shield/issues any input on those would be welcome, particularly how to best handle dual motor drivers: rosmo-robot#1