Profiles.TylerPackard, SummerBlogs
August 5
Over the past few weeks I've wrapped up toe SimGrasp documentation. I wrote more detailed documentation for all of the classes and functions and wrote a short rundown of how the example program works. You should be able to find it online at shiquan.bitbucket.org/simgraspmanual.
I also create a class in SimGrasp for modifying the Klamp't world files. Now you should be able to modify the terrain of the simulation between simulations.
I installed Klamp't on one of the BDML desktop computers, and it took a while to get it working. For some reason it couldn't find certain symbols, but after recompiling it, everything worked fine. It was weird because both times I compiled it from the github source, and no commits were made between each compilation, so it should have worked the same both times. I also had to reinstall it on my computer, but I was also getting a lot of weird errors, with the compiler complaining that some things had been already declared and that there were undefined references to cerr and endl, but not cout in one of the files. I had never seen any of those errors when installing it before. I eventually got it to compile, but at runtime it would throw errors that stl files weren't supported. Using stl files had always worked before on other computers, and no new commits appeared to remove stl compatability, so I eventually gave up and tested my code on the BDML desktop.
July 20
I've decided that Sphinx is probably the best documentation tool for Python. Given that it was originally created to document Python 2, it interfaces well with Python and will feel very familiar to people who have used Python before. It's also capable of both reading documentation from the source code and allowing you to write your own documentation outside of the source files. The syntax for formatting is pretty intuitive too, and doesn't look too strange in the source files where it's unrendered.
I've started to write up some of the documentation in the Sphinx format, and it looks pretty good so far.
A sample of the autogenerated documentation from
design.py July 15
I got Blender working with SimGrasp today, and now SimGrasp can scale geometry along each axis independently. At first I though that the fact that bpy, the Blender Python API, is a Python 3 library would make it incompatible with SimGrasp since Klamp't is a Python 2 library. However, the only way to expose bpy to python is to run it through Blender, so I'm using the subprocess module to run Blender in headless mode and run the transformation script. Since the transformation script is being interpreted by the Blender Python interpreter, it doesn't matter that SimGrasp is being run with a Python 2 interpreter.
Another problem that I ran into was sending information on which geometry to transform and which transformations to apply from SimGrasp to the Blender script. Since they are being run in separate interpreters, I can't just share variables between the two. I also didn't think I would be able to send them via command line arguments since the arguments are interpreted by Blender, and Blender crashes if it's given arguments that it doesn't understand. However, I found that if you pass as an argument, Blender will ignore all of the arguments after it. Using this, I was able to pass arguments to the transformation script.
The transformation script itself is pretty simple, and just parses the arguments and calls the appropriate blender functions. It's currently not very powerful, and can only scale entire objects, not smaller subsections. In the future it might be nice to be able to do that, but it will be tricky to figure out how to pass that information via the arguments.
July 12
I spent nearly all day installing Klampt for SimGrasp. At first I tried installing it using the .deb files provided on the website. I couldn't find the the example code and data though, and it didn't seem like the python bindings had installed, so I tried installing Klampt from the github repo instead. Later I found the example code and data and python bindings in /usr/data/ and /usr/Python/.
I installed Klampt today from the github repo. At first I tried installing it using the KrisLibrary .deb file that I had downloaded and installed earlier, but it's slightly out of date and the github version of Klampt depends on a newer version. Installing the newest version of KrisLibrary from github manually solved this problem. If you don't install the KrisLibrary .deb, the Klampt unpack-deps and deps make targets should automatically download and build the one from github.
After I compiled Klampt, I tried to run make apps like the installation guide says, but it would not compile because it was missing dependencies. After looking in to it a little, I don't think that the apps are necessary for SimGrasp, so I decided to skip building them. I then built the python bindings and tried to run the one of the python demos, but it failed because it was missing the RobotSim dependency. I then tried to build RobotSim from github, but it kept failing because it was trying to compile with out of date dependencies.
The Klampt github repo recommended installing Klampt using docker, saying that it was the easiest way to install the library. I decided to try it out, but since installing via docker creates a virtual environment for Klampt, everything had to be run through docker. The command to do this was very long and annoying and docker didn't install the example data and code (or at least not where I could find it), so I ultimately decided to try building Klampt from the github repo again.
I first tried to run make uninstall, but it didn't work because it couldn't find some file that it needed. Since I was going to reinstall Klampt again and overwrite all of the files anyways, I just deleted the Klampt directory and re-cloned the github repo. After building it again without running make apps everything worked. If I ever end up having to install it again, I would just build it from the Klampt github repo and not use the other methods.
July 11
Today I got the calibration program to a mostly working state. The calibration is a little off depending on where on the sensor the force is exerted, especially with larger forces. With a 100g weight, the readings can vary around a range of 10g. When I graph the calibrated input versus the known forces, the 0g and 20g trials are very accurate, the 50g trials are reasonably close, and some of the 100g trials are decent and some are way off. I'm going to put the calibration program aside for now though and wait until Alice comes back to see if there is anything I can improve.
July 5-July 9
This week I changed the calibration for the normal axes from a linear function to a third-degree polynomial one. In order to do so, I changed the force calculation function for the sensor to accept a whole matrix instead of just an array of scalars for each term of the polynomials. I also changed the sensor code to bias the sensor input before it calibrates it because the calibration matrix expects the data to already be biased since the sensor data used in generating the calibration matrix is already biased. At first I didn't really understand exactly what I was doing, so it took me a while to figure out how to structure everything. I had thought that it would still calibrate each channel individually, but in the end I realized that it only calibrated the total normal force. Even after I figured out how everything worked, the calibration did not work correctly and gave very large values. Eventually I found lots of little bugs and typos and got the numbers to be much more reasonable.
June 27-July 1
During this week I moved the shear forces onto their own graph and improved the the drawing speed. Although the fast drawing method I was using earlier worked much faster than matplotlib normally does, it still wasn't fast enough to draw all of the data that was coming in at real time. To get around this, I switched to using matplotlib animations, which also fixed the problem of not being able to close the matplotlib window while it was running. However, the matplotlib animation is a blocking process, so I had to move the sensor to its own thread in order to run them both at the same time. The animation function is also run on a timer instead of being a callback function like the old process I was using before. Instead of the sensor calling the redrawing function whenever it got new data, the drawing function now pulls the data from the sensor. I also modified the sensor to store all of the data it gets in a list instead of just the last set of data. That way the plotter can graph all of the data that was recieved in between animations. Now the plotter works great drawing in real time.
I also began working on the calibration code for the sensor. It uses matrix equations to scale each channel linearly to best match the known forces applied to it and then writes the scalars to a json file. One problem that came up while working on this is that the sensor I am testing my program on seems drift slowly when forces are applied for more than one second. This prevents the calibration from being as accurate as it would be if the sensor didn't drift, but for the most part it works decently.
Both programs now use command line flags to set various options, and these can be found by passing the --help or -h flags.
June 17
I got the serial plotter working with the tactile sensor, and now it shows 6 lines representing the different forces acting on the sensor. I tried to allow you to click on one of the lines in the legend and toggle its visibility, but the clicks never registered. I think this is caused by the fast drawing method that I am using that messes up interactions with the window. I think the only way to plot the data in real time and make it interactive is to use a different library, but I think matplotlib will do for now as long as interactivity is not important.
The graph of the sensor data
June 16
I finished the basic serial plotter, and now I just have to get it to work with the tactile sensor once it is found. I sped up the program by using a different drawing method, but now you can't do anything interactive with the graph window. It does update the graph in real time now, so I'll leave it how it is for now. I also started looking at the shoe insole sensors with Chris Ploch, but we couldn't find a battery for it, so we'll have to wait to find one before we test it.
June 15
Arrived for lab orientation. Started working on a program to graph live data sent over a serial connection in python with matplotlib. It doesn't seem like matplotlib is the best library to use for graphing live data since it updates at roughly half the speed that the data comes in, but it works.