Build Instructions

Collapse

• 1

  Gimbal

  The gimbal is an implementation of the open source project STorM32bgc http://www.olliw.eu/2013/storm32bgc/ using a generic v1.32 board from Gearbest, and £10 gimbal BLDC motors from Hobbywing.

  Here is the reference for the STorM32 Remote Control commands for the v1.32

  board (there is a newer ref for newer boards):

  http://www.olliw.eu/storm32bgc-v1-wiki/Serial_Communication

  and pin reference for the same:

  http://www.olliw.eu/storm32bgc-v1-wiki/Pins_and_Connectors

• 2

  BLE control of Mekamon

  (see mmdriver_node.py in the files)

  Reach Robotics haven’t yet released an API or anything to allow custom control of the Mekamon. I couldn’t make sense of the BLE services and characteristics. I took it apart and saw it uses a Nordic nRF51822. (and its brain is a PIC32 (and it has a connector called “Shhh! secret connector!”)). I thought that maybe it uses the standard Nordic UART service, and one shows up on a Android BLE info app.

  I watched the packets coming from the Mekamon phone game app using Wireshark and an Adafruit nRF BLE packet sniffer. It took me about a week to work out how to talk to it. It is using the UART service, not BLE characteristics. When it connects there’s a lot of mysterious stuff that goes by but then it settles down and sends the same command repeatedly until you use the onscreen joysticks in the app, when they change accordingly – these are clearly movement commands; 3 signed bytes for fwd-back, strafe, turn. If I replicated all this exactly I could take control. I worked out by elimination that a lot of the startup stuff is unnecessary except for two.

  The frame structure is a header byte, a command byte, optional payload bytes, a checksum byte and a zero terminator byte. The meaning of the first byte was unknown and there was a weird behaviour where bytes that should be zero get replaced with 1-5, depending on which of the 3 axes were active. I laboriously made a table of what causes what, before someone told me about Constant Overhead Byte Stuffing!

  So for example, when in joystick mode but idle, it sends hex:

  02 06 01 01 01 0C 00

  which is COBS header, command #6 for motion, zero on the 3 axes, checksum, terminator.

  Adafruit Python BluefruitLE source & install guide:

  https://github.com/adafruit/Adafruit_Python_BluefruitLE

• 3

  Blob-following demo

  The file for the non-ROS blob demo is “non_ROS_blobtracker.py” - Requires OpenCV and Adafruit_Python_BluefruitLE

  This demo is quite simple and far from perfect.

  BluefruitLE with BLueZ and DBus can be unreliable. It’s not clear to me where the fault lies. Sometimes it just needs:

  sudo hciconfig hci0 up

  or a reboot.

  ROS version:

  This consists of these nodes running on the Pi:

  • Camera publisher - custom Python node
  • Image republishers - standard library node - compresses images for optional use by other machines over the network.
  • Blob tracker - custom Python node - finds objects and makes motion decisions
  • Robot controller - custom Python node - converts ROS motion commands to Meka-mon motion commands and sends them over BLE.

  First, create ROS packages “mmstereocam” and “mmnavigate” and copy the provided files to make this ROS workspace structure:

  On the Pi via SSH, run:

  roslaunch mmstereocam blobtracker.launch

  Then use rqt_image_view  from your PC  and select /stereo_camera/image_blob/compressed, and you should see it highlight your coloured object while the gimbal follows it. You will need to do some tuning for your gimbal setup, camera and target object.
  

  Power up the Mekamon and run:

  rosrun mmnavigate mmdriver_node.py

  This should present a list of nearby BLE UART devices. Select the Mekamon. It should connect and display a stream of commands being sent, and the robot will now walk in response to the ball.
  

  rqt_graph looks like:

View all 4 instructions