Dexter dIMU Support

HomeForumsMonoBrick EV3 FirmwareDexter dIMU Support

This topic contains 7 replies, has 2 voices, and was last updated by Author Image Anders Søborg 3 years, 5 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #4007
    Author Image
    Martin Zenkel
    Participant

    Hi,

    building up some balancing vehicle I’m trying to implement the Dexter dIMU I²C-sensor, especially the accelerometer
    http://dexterindustries.com/manual/imu-sensor/
    http://dexterindustries.com/files/dIMU_Datasheets.zip

    I’m deriving from I2CSensor which seems to be very straightforward. The problem is that every Read../Write.. call attempt hangs (e.g. setting the mode or reading a value from the appropriate hex register address). The same applies to the gyro on the same device (of course with the correct I²C- and register-addresses). After reading some lines about the I²C bus I wonder if it might be the case, that MonoBrick Firmware doesn’t support some special I²C detail (maybe another mode) yet?

    The same device (both the accelerometer and the gyro) delivers measurement values with the standard EV3 software, using the blocks from
    https://github.com/DexterInd/EV3_Dexter_Industries_Sensors/raw/master/Dexter.ev3b

    Unzipping this file and analyzing the *.vix-files in it gives me no hint (apart from a I²C-address shift, which I tried too).

    Do you have any idea? Thank you in advance.

    Best regards,
    Martin

    BTW: MonoBrick Firmware is a really great project!

    #4008
    Author Image
    Anders Søborg
    Key Master

    Hi

    Try to use this as a starting point. My guess is that you did not call the initialize on the base class in your constructor. Post some code if this does not work. Also when you are done make a pull request on github – then you can help expand the number of sensors that are supported by MonoBrick firmware…

    Anders

    #4011
    Author Image
    Martin Zenkel
    Participant

    Hi, thank you for the very quick response.

    To answer your hints and proposals:

    I already cloned the github monoev3 repository to check the code of the handful of I²C-sensor implementations that ship with MonoBrick firmware and I already did call Initialise() on the base class in the constructor. This is the code (excl. ReadAsString):

    public class DexterAccelerometer : I2CSensor
    {
    	public DexterAccelerometer(SensorPort port) : 
    		base(port, 0x3A, I2CMode.LowSpeed) //0x3A: Dexter-dIMU-documentation, 0x1D: Freescale-datasheet
    	{
    		Initialise();
    
    		byte mode = 0x01 << 3 + 0x01; //4g measurement
    		WriteRegister(0x16, mode);    //THIS CALL DOES NOT RETURN
    	}
    }
    

    In my previous post the I²C details of MonoBrick Firmware and the I2CSensor class came into my mind because I took a look at the Tutorial Segway with RobotC. There the Dexter dIMU gets initialized with a I²C mode constant named sensorI2CCustomFastSkipStates, whatever that means. This mode is one of six according to the RobotC driver suite common file (line 218ff). So compared to RobotC I guess that MonoBrick Firmware implements ‘only’ the sensorI2CCustom and sensorI2CCustom9V mode (equivalent to I2CMode.LowSpeed and I2CMode.LowSpeed9V) – just a guess.

    Secondly, what strengthens my suspicion: In the Dexter’s ev3b block description (unzipped, in Accel4.vix) they write decimal ...DataType="Byte[]">[29,22,9]... for the “Accelerometer Initialization 4G” (as the comment below states). It seams that they send only three bytes, containing hex [1D,16,9] which means [I²C address, register address, value]. Looking into MonoBrick Firmware’s I2CSensor.WriteAndRead implementation it seams that some overhead is built around this essential 3-byte information. Might this be an incompatibility? Sorry, but maybe I’m completely wrong. ;-)

    (Apart from that, my confusion with the “I²C address shifting”-topic is resolved in so far, as I have meanwhile seen I2CAddress >> 1 in your I2CSensor.WriteAndRead implementation. So I use the “left shifted” one, as shown and commented in the snipped above.)

    #4012
    Author Image
    Anders Søborg
    Key Master

    Hi Again

    You might get some helpful info here – but you will have to do some reverse engineering :-)

    I have to go to bed now, but please let me know how it goes…

    Anders

    #4015
    Author Image
    Martin Zenkel
    Participant

    Thank you, I’ll take a look at it.
    Martin

    #4023
    Author Image
    Anders Søborg
    Key Master

    Please let me know how it goes. I would really like to support more sensors

    Anders

    #4043
    Author Image
    Martin Zenkel
    Participant

    Hi Anders,

    sorry for the late response.

    After comparing both I2CSensor implementations (down to some IO-related UnixDevice class) I could not resolve my Dexter dIMU I²C communication issue.

    To proceed with my main objective I’m using the HiTechnic tilt sensor now which is already implemented in MonoBrick Firmware. It is an I2CSensor too but/and it works fine. I’m doing some research concerning timing, threading and so on in order to get a responsive/reproducable balancing loop solution. Further more I’m working on various details, e.g. wondering if (and hoping that) there will never be a time-consuming garbage collector or background system task that breaks my balancer activity.

    I think I’ll come back to the dIMU later, keeping you up-to-date of course.

    Best regards, Martin

    #4051
    Author Image
    Anders Søborg
    Key Master

    Hi

    Please remember to let us all know how this goes…

    Anders

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

Posted in

Make a donation