Availability of EnoderMotorDriver software

#1

Hi,

Can you please make the software of the EncoderMotorDriver available? If possible the source code, but at least the hex file of the stock firmware.

I’ve tried the source code posted last november, but found that this was beta code (some bugs and quite bit of dead code) and is not compatible with the MeEncoderMotor class.
I’v added support for direct (pwm) drive to the beta code (with the november version of the MakeBlock library) but would like to maintain compatibility with the mainstream library. If this is not possible, I would at least like to have the option to reflash the EncoderMotorDriver with the stock firmware.

Regards,
Joep

#2

Did you try https://github.com/Makeblock-official/Makeblock-Library/blob/master/makeblock/examples/Me_EncoderDriver/EncoderMotorTest/EncoderMotorTest.ino? It’s from January 2015

#3

Hi Shaiss,

Thanks for the relpy. I did look into this code, it’s for the ‘master’ side of the controller, the one you normally program, and has some nice features. The way it communicates with it’s slave (the EnocoderMotorController, also an arduino compatible unit) has changed significantly though. What I want is to add the the ability to just run the motors at a specific PWM. For this I need to change the the code of the ‘slave’ and the master. The last one is available, the first one only in an old beta version.

I got some new beams from makeblock today and realy love their mechanics. The software could be improved and I am a bit disappointed there was no reply on my question from the Makeblock support team after 3 business days. I guess even a ‘no you can’t have it’ would have been better…

#4

FYI: I’ve emailed MakeBlock support and got a prompt reply including the firmware :smile: .

At first glance, the code looks much more solid than the beta version they posted earlier. Like the interface, the code seems to be changed quite a lot. I’ll look into this in more detail in the near future.

#5

After playing around with the encoder motors, I have mixed feelings:

  • Control of the motors is pretty good.
  • Quality of the electronics is okay (although I did put a bit of glue between the encoder pcb and motor, to fixate it).
  • Angle and Speed values seem to be in units of about 700 / wheel turn. Is there a way to set this to a more intuitive value?
  • I can’t get RunSpeedAndTime to work for a short time. Time seems to be in seconds and should be over 200 for the command to be executed at all.
  • GetCurrentSpeed and GetCurrentPosition seem so work most of the time when the motors are off, but sometimes returns 0 (when it should not). When the motors are running, over 40% of the request return 0. Any suggestions to fix this?
  • I have not yet found a way to turn the motors off. When the motors have turned and stopped, they continue to make a buzzing sound. The sound can be reduced (sometimes to zero) to turn the motors slightly by hand. Issuing the reset command doesn’t help, but pushing the reset button on the encodermotordriver does. Is there a way to do this from the Orion board in software?

Again, I have mixed feelings. Your mechanical hardware is great, electronics seem to be pretty good too (assuming the above are not related to the electronics). But the software and documentation could do with some improvement… I hope you can help me with - at least some of - the issues above.

Joep

#6

Hello Joep, I facing exactly the same issues, were you able to find defects in the firmware? could you please attached the source in the forum so I and others can have a look an possible solve some of the issues.

Enrique

#7

Hi Enrique,

The short answer is: I have not solved this.

The long answer: point 3 and 6 are software design issues that should be pretty simple to fix. Point 4 is a bug in the EncoderMotorDriver software.
I have not determined the cause of point 5, but suspect it is related to hardware or power supply issues.

Fixing the issues (or making modifications to the code in general) is one thing, but distributing them is another. First the fixes require changes to both the arduino makeblock library and to the firmware embedded into the encodermotordriver. The first one only makes sense if MakeBlock makes (or adopts) the changes in their code, otherwise one would have to make these modifications after each update of this library.
The embedded firmware has this issue, but is less relevant since people are not likely to update this firmware when a new version is released. The major issue here is how to upgrade (program) this controller without special tools.

My intention was to use the encodermotordriver with micros beyond the arduino. For my application it is mandatory I can read the encoders while the motors are running. Other features like the PID controller are less important. And since the i2c protocol used by makeblock has a lot of overhead (and hence, requires relatively long i2c bus time) and it’s implementation is quite complicated (partly due support for the serial setup tool, but also for reasons I can’t comprehend).
This provides me with a dillema: create new, simpler firmware with less features that matches my requirements or spend a lot more time to extend the makeblock software to maintain compatibility, knowing this will have limited benefits for current users and only have benefits for future users if makeblock adopts the changes?

I’m afraid it will probably be the first option, and only then when I reliable read the position when the motors are running.

Joep

#8