more complete python implementation

Has a more complete python module been implemented, particularly that accesses the AHRS information?

Thanks!

Hello talgball,

Thanks for your interest in RIO and for your patience.

Unfortunately we need a bit more time to prepare more sophisticated Python module.

Good news is that the priority of this functionality is getting higher now.
So, it is a good time for you to request a particular functionality that we consider rolling it out first.

Please find some time to describe your urgent needs. We will do our best to cover them with our solution.

Regards

Thanks for the reply, and I'm glad to hear the priority is going up.

For me, the most pressing thing is access to the AHRS data, quickly followed by functions to configure it. I don't remember which chip you are using, but knowing that would also help with planning the capabilities.

I'm considering implementing some of this functionality myself for python just to get past this sticking point in the project. However, if there's a way to set some rough expectations on timing, we could plan around your implementation. I wouldn't want to spend time on something that you're doing soon.

Also, if you could publish a bit of additional information, we could potentially contribute to developing the code. Not sure if that's an approach that RoboteQ has embraced, but it's a thought.

Best,
Tal

Hello talgball,

As for:

For me, the most pressing thing is access to the AHRS data, quickly followed by functions to configure it. I don't remember which chip you are using, but knowing that would also help with planning the capabilities.

Currently we are using:
MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS MotionTracking™ Devices
Specification ver 3.4 in PDF format
But we highly recommend to stick to our API rather than hacking around the chip somehow.

I'm considering implementing some of this functionality myself for python just to get past this sticking point in the project. However, if there's a way to set some rough expectations on timing, we could plan around your implementation. I wouldn't want to spend time on something that you're doing soon.

Unfortunately we can't guarantee any milestones/release dates. Once again - thanks for the understanding.

Also, if you could publish a bit of additional information, we could potentially contribute to developing the code. Not sure if that's an approach that RoboteQ has embraced, but it's a thought.

What kind of information would be considered useful, do you think? Yes, at RoboteQ an enthusiasm was and is the driving force of every project and we embrace every attempt to make our products better (be it constructive critics or new feature suggestion).

Regards

The MPU-6050 is a very feature rich chip. In order to participate in the api / python work, it would be good to understand the roadmap for how much of the capability that RoboteQ plans to expose via the api, any standard naming conventions and styles, etc. (Some of the naming stuff could be inferred form the code already provided in the install package, but it would be good if there are any docs around it.)

The functionality questions include, for example:
-Only retrieve current register values, or current and fifo?
-Support for interrupt on data ready?
-Ability to configure full scale ranges for the gyro and accelerometer? (Config for a drone and config for a relatively slow land based robot would be very different.)
-Access to the fused DMP data?

-Access to the temperature value?
-Access to the on chip algorithms, such as support for gesture recognition and shaking detection? (Use case not obvious with chip mounted on rio, but it depends on the robot design.)

I've implemented some work based on the 3 axis predecessor of the 6050 and the 9 axis successor that integrates the magnetometer with the other two sensors. The 6 axis and 9 axis came out so close in time to each other, that we didn't get to implement the 6 before we were ready for the 9. That family was a good choice of devices by you guys in my view.

Thanks!

Hello talgball,

Sorry for the late response.

First of all thanks for your generous proposal (to help us out providing your input/expertise about the AHRS). It really looks like you are quite into the details about the entire family of these chips by now and talking out of experience. Has the product(s) your are working on been already released somewhere? Is RIOBoard involved in your project?

As for chip-specific features to be exposed on RIO side (say, via Python library) - after some considerations we decided to observe the use cases for a bit longer, sticking to what we have implemented now. It seems that 9-axis is enough for most of the RIO users so far.

If you are badly missing particular functionality - we can think of providing that in case more similar requests come out. But exposing complete functionality of the chip would be a bit of an overkill for us. Not to mention possible complications in case we decide to use an alternative chip in future.

Thanks for your understanding. Looking forward to hear more about your experience with our products.

Regards