Reprogramming the Dash Robotics Kamigami – Part 1

Reprogramming the Dash Robotics Kamigami – Part 1

As regular readers will know, I’m a fan of the Nordic nRF51822 Bluetooth MCU, as it can be programmed developed using Open Source tools.

So when I saw the Dash Robotics Kamigami at Bay Area Maker Faire in May, and spoke to their hardware engineer Dwight Springthorpe, who confirmed that this innovative educational toy used the nRF51822, I took the plunge and bought one on the spot – at the special show price 😉

See http://kamigamirobots.com/

 

 

Dwight told me that Dash Robotics were interested in people developing for this product using the Arduino IDE, so I hoped I could develop an Arduino library to allow the various peripherals of the Kamigami to be programmed by the Arduino IDE, or possibly develop using mbed.org

When I initially got in touch with Dash via email, they were reticent at providing me with any information about the hardware. So I set about reverse engineering the Kamigami.

Luckily a few days later I was able to get in touch with Dwight directly via email, and he has since provided me with some technical details.

 

As I first step I had to solder a 4 pin header to the empty header points on the board and hook it up to a SWD programmer and see if I could reprogram the nRF51822.

 

kamigami_swd_pins

 

The connections are labeled on the silk screen,

GND = GND

CLK = SWCLK

3     = Vdd (3.3V)

D     = SWDIO

I hooked this up to a Jlink. (remember you need to connect the 3V pin to the Jlink or it won’t detect the nr51822 as being connected.

Before I overwrote the existing firmware, I thought it prudent to see if I could read back the existing firmware, in case I needed to re-install the existing firmware, while reverse engineering the hardware peripheral connections, and to my pleasant surprise I found that I was able to read out the all of the Flash memory, as the nRF51 had not been read protected.

kamigami_jlink

 

So I now had firmware backed up in case I need to a restore.

At this point, I had intended to possibly poke around the PCB using a multi meter and a scope to try to determine how the peripherals are connected to the nRF51, but I suddenly realised that I could restore the firmware backup onto a more convenient debug platform, namely my WaveShare nRF51822 (http://www.waveshare.com/nrf51822-eval-kit.htm)

 

ble400-4_2

This board has a slightly different MCU, as it has the better QFAC variant with 32kb of RAM instead of the QFAA on the Kamigami but apart from that the MCU is identical. The other difference between the Kamigami PCB and the Waveshare is that the Kamigami doesn’t have the 32kHz RTC oscillator crystal (and the Waveshare does). This can make a big difference to the nRF51 startup code, and also its operation, because firmware written for boards with the 32kHz osc, don’t normally work on boards that omit this oscillator.

Fortunately the reverse is not generally true, and after flashing the firmware backup to the Waveshare board, I was able to connect to it using both Kamigami iOS app.

I selected the “Drive” option in the app, and twiddled the joystick that controls the 2 motors, and I noticed that some of the LED’s on the Waveshare board began to light up.

http://www.waveshare.com/img/devkit/accBoard/BLE400/BLE400-size.jpg

Specifically, the LED’s on pins P18,P19,and P20. All the pins seemed to be driven via PWM, as the LED intensity could be adjusted. P18 and P19 seem to get lit when the robot would be moving forward, and P20 was lit when the robot would be going backwards.

This seemed an odd arrangement, so I checked whether and of the other adjacent pins had PWM on it when moving the virtual joystick in the app, and found that P17 seemed to modulated when the robot would be going backwards.

i.e

P0.17 is left motor reverse control

P0.18 is the left motor forward control.

P0.19 is right motor forward control

P0.20 is right motor reverse

 

Hooking a scope up to these pins, revealed that they were modulated at a clock frequency of just 64Hz, and that the joystick control has slightly odd mapping, in that For Example, 100% PWM is delivered to the right motor, not when the joystick is fully forward in the middle, but is actually when the joystick is over hard to the middle left, when the robot is being commanded to turn left – not that this important information at the moment, but may come in handy later when programming some new firmware.

Incidentally, the motor driver IC’s appear to be GPY0067A, but I can’t track down a datasheet it… Not that this is particularly important as I’m pretty sure I know how to control the motors.

The next thing I looked for was what controlled the 3 tri-coloured LED’s (which are wired in parallel), and a quick visual inspection of the board, revealed that the LEDs were on pins P0.5, P0.6 and P0.7, and playing with the App isolated that

P0.5 = Blue channel

P0.6 = Green channel

P0.7 = Red channel

Looking at these on the scope was also interesting, as the App just seems to have each channel, either on or off, but the scope showed that the LED’s are actually being driven with 64Hz PWM (like the motors), so it would be possible to get the LED’s to be any colour from black to white, not just the 6 options in the “Games” section of the App.

 

Moving on to the inputs.

The ambient light detector seems to be attached to P0.02, as grounding this pin though a resistor changed the value displayed in the App.

The App displays the Battery level, but I have not been able to establish if this value is taken by reading the a pin, or whether its just a calculated value, which goes down depending on the amount of motor and LED usage.

 

The Kamigami also has a 6 axis IMU, with 3 accelerometers and 3 gyros. I was unable to read the markings on the IMU chip, so I emailed Dwight and he told me it is an ST LSM330.

I’m fairly sure that its connected via SPI, but I have not confirmed this with Dwight and I have not tried to communicate with it yet.

Its actually a real shame that Dash opted to use a IMU without a compass (magnetometer), as in my experience the outputs from the gyros and accelerometers are not especially useful, as they are subject to noise and drift which makes them useless for inertial navigation. Where as the magnetometer always lets you know which way up it is and where north is.(Assuming it has been correctly calibrated in the first place)

 

Developing using mbed

Although I have an Arduino core that works with the nRF51822, I know it doesn’t work unless the hardware has the 32kHz RTC crystal, and the Kamigami board doesn’t have this.

However there is an mbed platform for an nRF51822 module without 32kHz crystal –  for the HRM1017 (https://developer.mbed.org/platforms/mbed-HRM1017) , that can be used as an equivalent platform.

 

 

More to follow…

 

 

Leave a Reply