Sparki / Python Library

The Easy Robot for Everyone!

Sparki / Python Library

Postby radarjd » Mon Jan 04, 2016 9:20 pm

Hi all, this post is going to contain a lot of background, so for those of you looking for the tldr: I've written a library that you can upload to your Sparki, which can then be used with a library I've written for Python. You can write Python programs with this library and control your Sparki with Python. The github can be found here: https://github.com/radarjd/sparki_learning

Okay, so now the background, which will be cathartic for me if not interesting to anyone else. I teach a class in Robot Programming using the Institute for Personal Robotics in Education (IPRE) Myro library using the Scribbler 2 / Fluke robot combo. The IPRE provides a textbook free of charge, and use of this particular robot and the text predates my involvement with the class. The Myro API itself is fine, but the Calico Project IDE gives me and my students lots of problems. Moreover, it has its own internal implementation of Python, and cannot use many standard libraries.

About a year ago, I got a Sparki and saw its potential as a robot to be used in education. Unfortunately, there wasn't a python library for it. Fortunately, it had Bluetooth, so I knew one could be written. I did not have the impetus to write the library at the time so I didn't.

This year a local high school, targeted at poor and underprivileged but smart high school students, was founded and requested my help with the robotics program. We met and I suggested that they use the Sparki, though I noted that there wasn't a Python library. There was some discussion that either the college (where I am an adjunct) or the high school would pay me for development of the library, but I heard little and forgot about it. Several months later, the high school contacted me and said they'd bought the robots and asked when the library might be available. They used their entire budget on the hardware purchase. Rather than leave them with expensive hardware (for an inner city school) and nothing to show for it, I wrote the libraries which are attached.

The concept behind the libraries is that Sparki runs an interpreter to which Python sends commands over Bluetooth: Image

While I am not the most talented of programmers, these were no small task. The C code which runs on the Sparki is 1199 lines (with internal spaces) and the Python code is 1952 lines (with internal spaces). They implement most of the Myro API, so an educator wishing to do so could make use of the existing materials published by the IPRE (see http://calicoproject.org/Learning_Computing_With_Robots_Using_Calico_Python). Further, using the Python library allows you to teach programming without the compile / upload cycle, and allows the students to get immediate feedback from their work.

I have tested the libraries to the extent I am able -- I'm certain there are bugs and edge cases I have missed. The Sparki library was particularly challenging as I haven't done extensive C++ programming since college, and the Sparki is extremely limited in space -- the compiled library uses 28,650 bytes of the 28,672 bytes available. Adding the String data type pushed the robot over the limit, so everything is done with char*. Probably a better coder than I could have done better, and I hope someone will take what I've done and improve it. I have limited access to a Mac, so while I have tried the Python code out on it, there may be some implementation specific issues. I have not tried it on Linux at all.

The code is released under the Apache 2.0 license with one exception -- I would ask that Arcbotics only link to the library and not distribute it. In an attempt to recoup some of my time, I contacted the company, but it was unwilling to pay anything at all for it. I understand that every business has to weigh costs and benefits, and they don't see the benefits. That is fine, but it should not be distributed by them, nor should they create derivative works from it.

I hope this code is of use to students and educators. I have commented the code heavily and used a variety of techniques in the Python portion, which again I hope is useful. I did not use OOP -- this was partially a stylistic choice, but also because I think it can be challenging for students who are not intending to be computer scientists or professional programmers. It's not that elementary school students can't be taught OOP, but I do think it can get in the way. Others can (and I'm sure, do) disagree, and that's fine -- rewrite or wrap it as an OOP library!

Sparki is a fantastic piece of hardware. I hope this library aids in your enjoyment of it and the enjoyment of your students. If anyone has any suggestions or finds any bugs, please let me know and I will try to fix them when I have the opportunity.
radarjd
 
Posts: 21
Joined: Wed Feb 11, 2015 6:26 pm

Re: Sparki / Python Library

Postby banda » Sun Jan 10, 2016 12:17 am

Very cool - and more thorough than I would have been.
banda
 
Posts: 12
Joined: Sat Jan 02, 2016 11:28 pm

Re: Sparki / Python Library

Postby banda » Fri Jan 15, 2016 2:41 am

Learned while connecting to Sparki via BlueTooth on Ubuntu linux:

http://playground.arduino.cc/Learning/ArduinoBT-Ubuntu

Assuming you bind the bluetooth device to 0, the port string in the init() command will be:

init("/dev/rfcomm0")
banda
 
Posts: 12
Joined: Sat Jan 02, 2016 11:28 pm

Re: Sparki / Python Library

Postby banda » Mon Jan 18, 2016 6:32 pm

When running sparki_myro_test.py, i get the following error every time I execute getName():

File "~/sparki_learning/sparki_myro.py", line 301, in getSerialBytes
return result.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte

I tried running setName first (no error) thinking that the problem was that no name had been written to the eeprom, but getName still fails with the error above.

Also, I have observed problems with the motors(), forward(), backward(), turnRight() and turnLeft() commands. turnBy() and turnTo() work fine. The non-working commands seem to run Sparki's right motor for a very long time at normal speed, and Sparki's left motor at a very very low speed.
banda
 
Posts: 12
Joined: Sat Jan 02, 2016 11:28 pm

Re: Sparki / Python Library

Postby radarjd » Tue Jan 19, 2016 5:08 pm

banda wrote:When running sparki_myro_test.py, i get the following error every time I execute getName():

File "~/sparki_learning/sparki_myro.py", line 301, in getSerialBytes
return result.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte

I tried running setName first (no error) thinking that the problem was that no name had been written to the eeprom, but getName still fails with the error above.

Also, I have observed problems with the motors(), forward(), backward(), turnRight() and turnLeft() commands. turnBy() and turnTo() work fine. The non-working commands seem to run Sparki's right motor for a very long time at normal speed, and Sparki's left motor at a very very low speed.


Interesting. What version of Python are you using and what's your OS?

motors(), forward(), backward(), turnLeft(), and turnRight() all use the motors() command -- that is, all of the other commands call motors. I noted an issue with motors() during development that caused a very similar issue, but it "fixed itself" as unhelpful as that is. The code that runs on the Sparki under the motors() command is what gave me fits, and I tried re-writing it many different ways. Eventually, it started working and I had done nothing which I believe should have fixed it. If you're feeling adventurous, pull the motors() command on the sparki code into its own sketch and see if you can replicate the behavior.

Re: getName() -- when the sparki turns on, does it display its name on the LCD? If it does, then things are being stored properly in the EEPROM.
radarjd
 
Posts: 21
Joined: Wed Feb 11, 2015 6:26 pm

Re: Sparki / Python Library

Postby banda » Thu Jan 21, 2016 2:37 pm

Ubuntu 14.04.3 LTS
Python 3.4
pyserial 2.7 (Tried it with pyserial 3.x, no difference)
The name does not display at startup - rather I get a multi-line block of diamond characters followed by a single # sign. setName executes with no error, getName fails every time.
banda
 
Posts: 12
Joined: Sat Jan 02, 2016 11:28 pm

Re: Sparki / Python Library

Postby radarjd » Thu Jan 21, 2016 5:18 pm

banda wrote:Ubuntu 14.04.3 LTS
Python 3.4
pyserial 2.7 (Tried it with pyserial 3.x, no difference)
The name does not display at startup - rather I get a multi-line block of diamond characters followed by a single # sign. setName executes with no error, getName fails every time.


It looks to me like the name is not being set correctly, which I can't figure out. I have uploaded a sparki_name_util sketch to the github. Would you try loading sparki_name_util onto your sparki to see if it is able to set the name properly? It should write the name into the same EEPROM location where the sparki_myro library will look for it.

The differences in the functions setName() and loadName() from the main library are:
1) Much more debugging output in both functions so you can see what is being read / written
2) The loadName() function zeroes out the buffer that is sent to it -- if that fixes things for you, then I will add that change to the main library
radarjd
 
Posts: 21
Joined: Wed Feb 11, 2015 6:26 pm

Re: Sparki / Python Library

Postby banda » Sat Jan 23, 2016 6:39 pm

Image

sparki_name_util seems to work fine!
Attachments
IMG_20160122_075138344.png
banda
 
Posts: 12
Joined: Sat Jan 02, 2016 11:28 pm

Re: Sparki / Python Library

Postby radarjd » Sat Jan 23, 2016 9:01 pm

banda wrote:sparki_name_util seems to work fine!


Great -- thanks for trying that! I've moved that minor change into the main code. Can you re-upload the main library and get for the same error(s)? I'm thinking you'll still get them on the Python side, but I'm hoping the Sparki's LCD will be able to tell us something during startup.

Thanks again for your help with debugging this. Are you still having the same issues with the motors()? (I assume you are, but as I mentioned previously it fixed itself "magically" for me.)
radarjd
 
Posts: 21
Joined: Wed Feb 11, 2015 6:26 pm

Re: Sparki / Python Library

Postby banda » Sun Jan 24, 2016 8:20 pm

Your update definitely solved the getName() issue. The motor behavior is unchanged. All the motors() based commands still yield the same results - the right motor turns at speed, the left motor inches incredibly slowly, and the command takes more than a minute to complete.
banda
 
Posts: 12
Joined: Sat Jan 02, 2016 11:28 pm

Next

Return to Sparki

Who is online

Users browsing this forum: No registered users and 2 guests

cron