MegaPi Firmware / Python Interface

[brucebannor]

I’ve noticed a few issues when running the MegaPi from my Raspberry via the serial port.
I’m running:
RPi3 with the newest Raspbian
V0e.01.012 of the MegaPi Firmware
Python v2.7 / Node v7.0

1. *Just a note for you; RPi3 users need to disable bluetooth to use the original serial port or will be regulated to the ttyS0 port by default. Via adding “dtoverlay=pi3-disable-bt” to their /boot/config.txt file. If bluetooth isn’t needed, that’ll free up the original port.

2. Many of the functions which have documentation for python & node seem to be missing from the MegaPi.ino firmware. The motor functions which have callbacks are missing even though they are present in the python/node libraries. The motors just turn on and stay on. To make it worse with the extra bytes the RPi3 gets from the serial port causes the MegaPi library to fail after the first call.

The backing library itself works great, because I just started modifying the MegaPi Firmware myself as needed to add those functions. It also works via the MakeBlock iOS app. I also tried Node which has the same issues because it uses the same MegaPi firmware.

Are there any plans to update the MegaPi firmware or am I better off just making a version for what I need?

[brucebannor]

I’ve managed to fix most of the calls between MegaPi and Python/Node. I’m having an issue with callbacks from the “ino” file though. If anyone has any idea’s on how to get a typedef function pointer defined in the “ino” firmware file to run from a cpp class it’d be much appreciated. I need the function pointer to run when things are finished like the encoder motor.

I’ve got the rest of the function to work correctly, i.e.

Encoder.move(1,50, 500, callback) now moves the correct distance and speed then stops but the callback function pointer I added isn’t invoked back on the MegaPi_Firmware.ino file.

I created a fork of the MegaPi firmware and will share once it’s working.

---

(Already defined in “MeEncoderOnBoard.h”)

 typedef void (*cb)(int16_t,int16_t); 

(MegaPi_Firmware.ino)

 void encoderMotorCallback(int16_t slot, int16_t extID) { .... }
 cb encoderCallback = encoderMotorCallback;
  ...
 Encoder_1.move(motor_position, speed_value, command_index, encoderCallback);

[brucebannor]

TheCodingYeezus/Makeblock-Libraries

Has a version of the firmware where I’ve fixed the motor encoder functions and callbacks to python. There’s a few broken pieces of functionality relating to speed-pid (seems to be existing) that I need to fix before I propose a merge into MakeBlock code.

“Firmware_for_MegaPi_New” under examples

[fergerberg]

Bruce, thanks for helping here.

I also found an issue with the gyro functions in python that didn’t pass enough parameters to the firmware.

I’ve been running my PI3/MegaPI using the USB port, but am trying to get it working over the GPIO serial port.

I’m currently updating my raspian, as soon as that is complete, I will reboot and try your fix to disable bluetooth.

Ferg

[brucebannor]

After some more research it’s okay to continue to use the /ttyS0 port. You need to change a few things in your /boot/config.txt;

core_freq=250
enable_uart=1

and make sure you pass the path as a start parameter to the Python Bot: bot.start(’/dev/ttyS0’)

The first config entry makes sure the baud-rate stays correct and doesn’t vary with CPU load. The 2nd enables the /ttys0 uart because you should have went into sudo raspi-config and turned off the Serial Port terminal. Normally it wouldn’t start without that 2nd line or having the Serial terminal enabled.

Of course if you don’t need bluetooth, you can still do the steps in the posts above. Most people would probably prefer to still keep their bluetooth module on the RPi3.

I haven’t tried to gyro but if you need I can take a look at it later here.

[fergerberg]

I’ve fixed the python code to make the gyro work. I’ll publish the change here when I get things back up and working.

Again, thanks for the help.

[fergerberg]

Ok, I got it running on ttyS0, thanks again for the help.

Now, on to the gyro…

The origin code for gyroRead was:

def gyroRead(self, axis, callback):
    self.__writeRequestPackage(6, axis, callback)

and __writeRequest was:

def __writeRequestPackage(self,deviceId,port,callback):
    extId = ((port<<4)+deviceId)&0xff
    self.__doCallback(extId,callback)
    self.__writePackage(bytearray([0xff,0x55,0x4,extId,0x1,deviceId,port]))

So, it was passing the axis as the port (axis is supposed to be 1 for X, 2 for Y, 3 for Z).

In firmware_for_megapi.ino code for the gyro is this:

case  GYRO:
  {
    uint8_t axis = readBuffer(7);
    if((port == 0) && (gyro_ext.getDevAddr() == 0x68))      //extern gyro
    {
      value = gyro_ext.getAngle(axis);
      sendFloat(value);
    }
    else
    {
      sendFloat(0);
    }
  }
  break;

So, you can see, that any axis value other than zero will automatically get the response of 0, and that it’s looking for the axis in buffer position 7.

So, I added a new version of __writeRequestPackage that takes an additional parameter (for the port), and my code looks like this:

def gyroRead(self, axis, callback):
    self_writeRequestPackage(6,0,axis,callback)

and

   def __writeRequestPackage(self, deviceId, port, axis, callback):
        extId = ((port<<4)+deviceId)&0xff
        self.__docCallback(extId, callback)
        self.__writePackage(bytearray([0xff,0x55,0x5,extId,0x1,deviceId,port,axis]))

and now the gyro works…

I suppose that the Python code could be left alone and the ino could be fixed to use the port as the axis. I chose to fix the python, because I was more comfortable messing with that.

Fergus

[brucebannor]

I suppose that the Python code could be left alone and the ino could be fixed to use the port as the axis. I chose to fix the python, because I was more comfortable messing with that.

I think that’s smart, especially if you want to keep compatibility with the other MakeBlock platforms. Ideally there’d be a small quick spec for the serial communication so you’d know what’s correct. I did find this in the source code comments;

 ff 55 len idx action device port  slot  data  a
 0  1  2   3   4      5      6     7     8 

So I’ve been using that as to what data should be sent via the serial port.

[andrew19ty]

Hi, is there something I am doing wrongly? I have performed all the necessary setup and I ran the following commends and got no results. Would you be able to shed some light please?

pi@raspberrypi:~ $ cd Documents
pi@raspberrypi:~/Documents $ python motorRun.py
init MegaPi
megapi.mSerial instance at 0x766ead50

[rdhelli]

It is almost a year later, I’m following up on this topic due to the faulty gyroRead function I have also discovered.

@brucebannor @fergerberg have your fixes (on gyro and motor functions) made way into any official version of MakeBlock code (python/firmware), or what’s the easiest way to include them? Is there any hope for the ‘MORE SOON’ content of your github?

@tec_support Can we expect some help for these updates to be integrated, or your own intent to solve the above issues?

[tech_support]

Hi All,

Sorry for the late response on this topic.
Recently, We have updated the instruction for using the MegaPi with Python as well as the Python library for MegaPi in this Github page.

[Mark_Yan]

I have update the python library to version 0.1.6 and also added some instructions on README, but so sorry, we have not updated in a long time. If you have some suggestions or questions, you can contact my email myan@makeblock.com

[rdhelli]

Thank you for the response, I have provided my suggestions and requests to the email, please have a look and let’s update this thread when there is news.

[Mark_Yan]

the megapi python library have updated to 0.1.7

[system]