Marco's Corner

Just another Software Developer's Musings

Browsing Posts in Uncategorized

UNI-T UT61E and QtDMM

No comments

I played with my UNI-T UT61E and Linux before. But now a friend pointed me to a little graphical display/grapher for the DMM data called QtDMM. It looked interesting but it did not work completely for my meter:-( So I looked around and found two source bases, one on github which was moved to Qt5 and the original version which is still based on Qt4. Both seem to have moved apart a bit but neither worked really for me. So I picked the github base, partly because I’m running Qt5/KDE and partly because it seemed easier to keep it sync.

So I had to do a couple of things:

  • Try to incorporate most of the changes on the original version since the fork. I don’t know how, successful I was there. It still works for me;-)
  • Add the complete decoding for the data as it comes from the device. The specs of the main chip are available online and sigrok and some CLI tools support that. So it was just a matter of integrating the ideas into the QtDMM source.
  • There are two different computer cables for the UT61E. One is using a real RS-232 which is hard to find on current computers. Since that adapter is powered by the RS-232 connection, it seems to be picky  on the used USB->RS-232 cable. I have one which seems to be working. But I saw some videos were people had problems with others.  The second UNI-T cable is a native USB connection, but that is recognized as a USB-HID device. So I had to add support for that as well. Again, this was mostly the integration of QtDMM with the hidapi-libusb. It seems to well now;-)

Overall, I’m happy with this little excursion in C++ and Qt5 land. Things seem to work for what I tested. If somebody wants to play with it, yet another fork of the code is here: github.com/mw46d/QtDMM.I’m not planning to take this over, but iff I find problems, I”ll try to fix them.

As always, have fun at what you’re doing;-)

Thanks Camp, for sharing that photo.

For the January 2017 meeting of the Home Brew Robotics Club (HBRC), I did a little presentation about my robots for the RoboMagellan events @ RoboGames. I did compete in that event for the last two years, and I’m working on my robot for the 2017 competition coming up in Pleasanton, CA on Apr 21-23, 2017. If you want to get an impression of the competitions, Camp collected some photos in a Google Album.

This post is just a anchor for the slides. They are here in PDF ( 201701_HBRC.pdf) and ODP (201701_HBRC.odp) format.

Most of my Arduino and ROS code and my 3D printed parts are on GitHub. The old code lives in the Entdecker repo and the updated code will be added to the EntdeckerL repo as I get it going. It’s currently a manual process to get working things from the robot to GitHub. So please let me know when you find something missing, and I’ll try to hunt it down.

As always, have fun trying something new;-)


I know about the different FIRST competitions for quite some time.  I even asked our kids about it a couple of times while they were still in school. But I guess, I was not enthusiastic or  aggressive enough to get a team started:-(
Since I joined the Home Brew Robotics Club mailing list, I saw the “Call for Volunteers” emails flying by every year. But it never really fit in the schedule until the Modesto First Lego League event.

So, I went to the FIRST volunteer site and signed up, did the background check and picked some jobs which I thought, I could do without having any experience how such an event works.  I got accepted, but there was still no indication on what I would be doing. So on Sunday morning, I packed my laptop and camera and went to the Fred Beyer HS in Modesto.

During the opening ceremony, the announcer asked for volunteers as referees for the actual games. Apparently some people could not make it. Since I did not have an assigned role yet and have some experience with “hobby robots” in competitions, I raised my hand and got the job;-) That was the beginning of a very fun but also stressful day;-)

If there was a `learn by fire’, the warm-up rounds were it for me;-) I had not looked at the ANIMAL ALLIES rules beforehand, so I was watching the teams while also trying to understand all the pieces of the game setup. The first break helped, so I could read the rules;-) Overall, I think, with the help of all the others, I did a reasonable job. But I would definitely not recommend that as normal `preparation’;-)

Thanks to the La Loma Green Machine Robotics Team and Mr. Ollar for allowing me to use some of their photos here. While I had my camera, I did not get around to take many pictures during the day. It was simply too busy. Their photo album is here.

Overall, this turned out to be a very fun-filled day for all involved. But I was very tired in the evening.
If you’re thinking about it, I would suggest to try to attend one of those events. It’s always fun;-)

— Marco

Oracle Mini Maker Faire 11/2016

Oracle Mini Maker Faire 11/2016

I did not know how wide this would be publicized but since I made it into the official Oracle blog, I guess it’s OK;-) Yes, Oracle had a company based Mini Maker Faire;-) All the people I saw, had a blast. But unfortunately, I did not have time to take any photos. I was busy with all the visitors at my little table explaining my different robotics experiments;-)

Here is the link to the official Oracle post about this;-)

Have fun,
— Marco

3D Printing with NinjaFlex

No comments

img_20161029_155112_1024 I found those nice little lighted costume horns @ the Adafruit tutorials. So I had to try to build my own pair;-) They were 3d-printed out of a nicely flexible filament called NinjaFlex. Playing with that opens a whole new area of potential uses. But first, the printer has to be able to handle it. My little HobbyKing Turnigy Fabricator printer has an open space between the filament drive and the actual hot end. I learned very quickly, that the NinjaFlex needed extra guidance there. (Normal ABS filament works just fine).

My first attempt to overcome that problem, was a little piece of Teflon tube. That kind of worked, but eventually, the filament would push the tube to one side and then out of the drive. So, I was on the right track, but needed to stabilize  the tube more. Since this is sitting right on top of the hot end, I did not like the idea of ABS, so I opted for a bit of wood;-) Cut to the right shape and the little wood piece works perfectly. The wood piece is just laying there but that’s enough;-)

After the img_20161029_155647_1024mechanics were working, the next step was (and still is), to find the right parameters for Slic3r to create successful prints. The first attempt with layer heights of 0.1mm worked OK for a little test cube, but not so well for those horns:-( I was also printing way to fast.

My latest parameters are:

  • Retract:
    • 0.1mm (probably to be increased to 0.25mm or more, still a lot of oozing)
    • lift 3mm, without that, the moves sometimes bend the piece over when moving
    • 40mm/s speed
  • Temperature
    • 230C
    • Bed 40C, should even work with unheated bed.
  • Printimg_20161029_155103_1024
    • 20 mm/s speed seems to work ok
    • 0.25 mm layer height

The last horns are still not perfect, but they look interesting enough for their costume use;-) So, I’m happy for now. When I need to print more form stabil pieces as a seal or possibly as dampening elements, I might pick up with those parameters again.

Theimg_9566 first trial run at the little Halloween potluck @ RobotGarden in Livermore. The LED strips work but since the ambient light is pretty bright, not much can be seen:-( Thanks Andra for sharing the image;-)

 

Have fun;-)

— Marco

 


OK, this tooArm1k quite some time but some info to our entry for the RobotArm event for the Science Olympiad Division C. This robot is probably overkill for the event, but maybe other teams can find some interesting tidbits for the next iterations of the event. After our first attempt with the team of our daughter in 2013, this was the second version with the team of our son. In the three years in between, we got somewhat more into the whole robotics area;-) I competed two times in the RoboGames and overall learned a bit more about the whole area.

So this year’s robot arm is using mostly Robotis Dynamixel AX-18 & AX-12 servos. They work much more consistent than the normal RC servos, but they are also much more expensive. Most mechanical parts were laser-cut @ RobotGarden, a maker space in Livermore, CA. The `gripper glove’ was 3d-printed;-) Both of those things were not really available three years earlier. The FreeCAD drawings for all are included in the so_arm repository. The gripper itself is one pre-made part, the LynxMotion Little Grip Kit with the only RC servo in the arm.Arm2

The brain stem is a little  Robotis OpenCM 9.04 board with an adapted Arbotix firmware. The idea behind that little board was good, but it looks like there is not too much progress with the OpenSource Support:-( In 2013/14, there was some momentum behind it, but now it looks pretty dead. Why the Arbotix firmware? It makes the connection to the higher level Robot Operating System (ROS) very easy, in this case via a Serial-USB connection.

ROS is used in many different robots in research/education as well as in production environments. It brings many features for higher level control and can be adapted to new robots as needed. So this was a good way to explore it’s features. In the process, we learned a lot with the help of Patrick Goebel’s “ROS by Example” books😉  They show a lot in a `simulated environment’ as well as with real robots when you happen to have the right hardware. But we were able to adapt things to our arm as well.

The first idea was to use a Raspberry Pi2 as ROS computer. I use such setups for some driving rovers. But we quickly learned that the path calculations were too much for the Pi. So in the end, ROS was runArm3ning on a laptop with Ubuntu 14.04 which worked very well. If you watch the video above carefully, you see the model of the arm in RViz on the screen before the laptop turns the screen dark (on batteries).

The Arbotix ROS repo is cloned from the original with my changes and the CM firmware.

The SO_Arm repo contains all the other ROS source packages (some modified copies of the rbx arm packages) and the mechanical designs.

And the result of all that? A second place at the San Joaquin County event;-) The first place went to a `two arm, remote controlled setup’. But overall, we learned a lot;-)

As always, look to explore something new;-)

A little update: The thumbnail images actually hide some larger versions with extra notes. They are very hard to see on the little versions and I got some comments about that.

Over the lasspamt couple of days we saw a big increase in SPAM bugs and SPAM comments in a Bugzilla installation. After the initial rush to stop that influx and clean up the mess, I took some time to look around and try to find some help to fight that issue at the source. Basically trying to filter/reject those bugs/comments right at the submission. Unfortunately, I did not really find much  🙁

The next step was to look at the sources (thanks for Open Source Software 😉 and see how hard it would be to to add a classification setup on my own. Bugzilla has a nice setup for hooks, but unfortunately there were none that fit my purpose. So I decided to add my code right into the normal sources. It turned out, that the majority of the additions were limited to two spots in one file, after the normal validations for the bug creation and the comment addition. I made some more changes related to configuration of the new service and to the error handling/text. But overall, it was quite easy and quick 😉 Thanks to another piece of Open Source Software: the CPAN Net::Mollom module.

The bz_4.4.11.patch was done against Bugzilla 4.4.11 and the resulting installation was tested locally with some simple messages and a free Mollom account. It seems to work as expected, but I don’t yet claim a real-world deployment. That would probably cost some money depending on how large the installation would be.

An additional Net-Mollom.patch to the Net::Mollom sources allows it to use the proxy configuration from Bugzilla. I thought, this would make things easier if the installation would need a proxy to reach the Mollom servers.

This whole exercise was just an attempt to see how much effort would be needed to implement a service-based SPAM classification for Bugzilla. This blog uses Akismet to classify comments and I believe my code could easily be adopted for that or even any other service. The most important part was to find the right spots where all the information is easily available before anything is committed to the DB. I think, I found pretty good spots 😉

As always, have fun expanding you horizon 😉