Servo 360 and Blockly
Phil Pilgrim (PhiPi)
Posts: 23,514
I'm designing a robot arm for the local HS robotics class. It uses Servo 360s for positioning. Each axis is designed to accommodate positions from 5 to 355 degrees. When the servo is at position 300, say, and I command to go to position 10, it needs to go in a negative direction from 300 to 10. Unfortunately, the Blockly code tries to make it go forward through 0 to get to 10 (i.e. the shortest route). But this causes the robot arm to hit a stop and stall, because it can't go that way past 355.
1. How do I specify that it must stay within bounds and not cross zero to reach its target?
Also, when it's on position, the dead zone is about 9 degrees wide, causing quite a bit of backlash and imprecision. That won't work for this app.
2. How do I narrow the dead zone?
Thanks,
-Phil
1. How do I specify that it must stay within bounds and not cross zero to reach its target?
Also, when it's on position, the dead zone is about 9 degrees wide, causing quite a bit of backlash and imprecision. That won't work for this app.
2. How do I narrow the dead zone?
Thanks,
-Phil
Comments
3. In Blockly, the servo's assumed zero point is the position it had when initialized. This is not acceptable. This app needs the zero point to be the servo's absolute zero point. These coordinates are fixed for the robot arm and cannot be relative to some unknown initial position.
-Phil
We have a process for making BlocklyProp improvements and I invite you to use it. Go here https://github.com/parallaxinc/solo/issues and post the request as a new issue. You can include the link to this forum thread to avoid replicating the request explanation.
If you don't have a GitHub account or don't want to make the request, I'm happy to do it for you. Just advise if you want me to handle it.
I can't promise a response time for improvements. It would have helped if the BlocklyProp F360 block requests were received a while ago so they could have been developed in parallel with the robotic arm. I'm concerned that we may be adding to your time now, but we'll know after the team looks at this. Some changes are easy because they don't require any library changes; others require library updates on the BlocklyProp server and have been difficult for our team to efficiently handle.
We're closed Monday but I know we can reply on Tuesday.
Thanks,
Ken Gracey
-Phil
Ken
https://github.com/parallaxinc/solo/issues/276
Item 2: Dead Zone. Achieving accuracy without hunting is a real problem, especially since this servo has a large inherent dead zone. I found I had to tune several parameters individually by servo (gain, minimum delta from 1500, max delta from 1500, I'm sure others) to obtain useful results. And that was with fixed load.
Item 3: I agree that is unacceptable. The servo tells you where it is.
tc
I think I've got this covered now. I didn't imagine it would be this easy, hence my initial query.
Anyway, although it was a bit cumbersome, I wrote a Blockly function that handles the low-level positioning the way I want it done, and it keeps the angle within a degree of the target without hunting. This puts me in a better position to modify things, if the students run into trouble, without bothering the Blockly boffins. So, questions:
1. Can I copy the C code that Blockly produces into a user-defined code block that the students can access?
2. How do I provide such a block to the students' workspaces?
Thanks for directing so much attention to my query! I hope I've not caused a lot of effort in vain.
Parallax rocks!
-Phil
Hey Phil,
You won't think anything rocks after reading this. I'm thrilled to see you make progress, though.
1. Yes and no. It's entirely possible but you'll want it to be part of the BlocklyProp system your students can access, so it must involve Parallax.
2. See below.
BlocklyProp programming environment (the language, compiling) runs from our AWS servers. Blocks that are released become part of the standard distribution, visible to everybody based on the board type they choose. When we add a block we test it on a demo server, then push it to BlocklyProp Solo (I think we are now diverging https://blockly.parallax.com from https://solo.parallax.com, favoring the latter). We also produce a reference page at the same time so people can right-click and go to help for the block.
The process has some steps, and they can feel cumbersome. I'm waiting now for about three months for us to release the new 3-axis accelerometer blocks. I'm not even sure why we're stuck internally, but we are. Parallel with this effort we released Solo, slowing our ability to create new blocks.
Unless you copy the GitHub code base and deploy your own BlocklyProp, we'll need to work together to achieve your goal.
This isn't at all what you want to read. Go ahead and shout out loud that you don't like things so we can get that part over with. Then, determine if your latest effort replaces the one currently posted on the BlocklyProp GitHub. If it supersedes yesterday's issue, then I'll close your prior issue and make a new one.
You can also make a GitHub account and get involved first-person, which expedites the process.
Ken Gracey
As you've created a function to do what you wanted to do, your development process is similar to ours. We recently released the Pixy2 camera and it had a fairly challenging serial interface which JonnyMac coded in BlocklyProp. For now, we're keeping those blocks as functions and people can download the SVG file. When people program with the Pixy2 they're accessing a pretty big code set of functions that also haven't been turned into blocks yet.
Right-click and "collapse" the function so it's minimized, and students can put it to use.
This is a great way to work in the meantime. While you're getting the students to use your functions and our standard F360 blocks, you might change the way it works. Use this time, and this process to really finalize what you're doing while the BlocklyProp boffins look at the issue you've submitted. Parallel processing.
Sound okay as an interim solution, or not?
Ken Gracey
So it looks like my best option is to write a Blockly demo program whose .svg file the kids can save on their own PCs under solo that they can open and modify for the specific operations their arm needs to execute -- assuming there's nothing workspace-specific in the SVG header that prevents this from happening. It would be nice to be able to lock my stuff so it can't be modified, but I guess that's what creating a block is all about.
Frankly, the only way Parallax's block-creating logjam will ever be broken up is to allow private -- or even shared -- block spaces, so users can create their own libraries and share them without Parallax having to get involved. Obviously, a BLOCKEX will have to follow.
Anyway, thanks for responding. I'm still optimistic that there's a way to make this work.
-Phil
Two important things for you to consider as you go about this.
First, be sure to choose the "board type" that your students will use. If they're using the Propeller Activity Board, then you need to use the same. If you try to import/open blocks from another board type you are bound to have problems. There's a reason for this, though. Consider the Propeller Activity Board, which has an audio amplifier, A/D converter and other stuff not found on a FLiP. The SD card socket may be tied to pins only found on the Propeller Activity Board. None of these pre-built things exist on the FLiP board.
Second, create the blocks in Solo. My understanding is that the two systems have diverged a bit, or at least there are some minor differences between them. Have your students use Solo as well. I already told Mr. Behrenfeld about Solo last week when he called the Educator Hotline.
You're asking for a user-contribution system and we offer one through your GitHub issue submittals. The only way to achieve your privately shared block spaces is for you to run your own BlocklyProp (on AWS, with the many challenges that accompany it). But you don't want to do that AND we want you to be involved with us, so let's work together.
Ken Gracey
I don't want to hijack this thread, but your C code for the 360servo sounds interesting & useful. Could you please post your code (zip)?
@"Ken Gracey" likewise the pixy2 code sounds interesting. I had posted pixy1 code for use with SimpleIDE and the ActivityBot on the forums a few years ago and just bought a pixy2. With trying to get up to date with my P2Eval Board with BASIC, SPIN2 and C I haven't found the time to start even thinking about writing code for the pixy2.
Would it be possible to point a way to the code that Jon wrote?
I realize that you are both busy, so if possible at your convenience.
Thanks
Tom
Absolutely! I'll get it posted here and on the product pages by Thursday.
Ken Gracey
Thanks for posting the files on the product page. However, when I tried to download & open the C file there was a problem.
SimpleIDE did not find anything.
The zip file size is only 285bytes and there is no ".c" file, ony the ".side" file.
I appreciate your help.
Tom
Sorry about that; not sure how that empty C project made it to our web site.
Anyway, I'll replace it and I've attached the code for your convenience. Let me know how it works out.
There's also Spin and BlocklyProp versions if you prefer. I've written a tutorial on the setup of PixyMon2 with the camera - you might need it to train the camera for color signatures. I could share it here as a Google Drive path.
Ken Gracey
Thanks for posting the C files. As with all Jon's applications it is very thorough and will take me some time reading it and the pixy2 wiki to understand the how and why of it.
I would also appreciate the link to your tutorial.
A little background:
With the pixy1 had written 3 different methods for interfacing it to the propeller using SimpleIDE. One was just using the easiest interface where the pixy set a voltage indicating the x or y position of the largest blob. I just used the a-d pns on the activity board. But that was very limited.
For my Activitybot I used the duplex serial function from the SimpleIDE library which uses a cog, and collected data looking for the start of a new data block and then collecting data as quickly as I could. I was able to write a program using that code to allow me to control the ActivityBot with bluetooth and command it to search for and drive to one of 4 different color patches. I could not get enough data collection/analysis speed to use more than 4 colors or combined color codes before the pixy would start sending a new data frames.
The program and instructions are in the post at the link below and following.
https://forums.parallax.com/discussion/comment/1291807/#Comment_1291807
To try to speed things up (with the help of Andy and the forum members) I took the spiasm.spin object from the proptool library made some mods to the pasm and called the pasm from the C program to use the pixy spi interface. With that I was able to read and analyze 14 blocks of data before pixy started a new frame, greatly increasing the number of colors and color codes I could look for. I never got a chance to incorporate that into my ActivityBot program; although I have used the spi functions for other purposes. My spi code was written for the last pixy firmware version before they changed the spi mode to require 2 way communication (host sends 16bit word - pixy responds with 16 bit data.) I felt that would result in a slow down compared with the older firmware that just sent data.