I’ve spend some hours of my Christmas vacation in the cold garage. I’ve added LM’s FSR’s and I’m pretty happy with the result. The rubber cap is just a little bit bigger and all the wires are perfectly hidden in the nylon sleeve.
I think the pictures will explain it all
Started with a 8mm aluminium rod and some M3 bolts
The bumper is a little bit bigger then the FSR but that’s a good good thing because it fits perfectly in the rubber cap.
The cable is strapped behind the leg so you can hardly see it from the front.
Here is the endresult:
The wires are still hanging loose as you can see. I’m making a small circuit to convert the analog signals to digital ones. But I haven’t got that ready yet.
I was thinking of using 10mm aluminium, but your solution with 8mm seemed to work very well. Very great that you could use the original rubber caps. Have you tried the sensor, at what angle they work from?
I also wonder about your electronic solution… Hex inverter, schmitt trigger, ADC, multiplexer??
Looking forward to see more of your work Xan!
(I think I’ll go to my aluminium shop tomorrow…) 8)
EDIT:
BTW, don’t forget to change the tibia length in the code. Not that I have any doubt about you thinking of that…
I’ve made the aluminium parts from a 8mm aluminium rod. The bolds are just 2 M3 x 6.
If you’re talking about connecting the wires to the sensors. My solder station took care of that. I’m gone use the same connectors (jumper pins) as used on the BB2 itself.
I didn’t use the original rubber caps. The once I used are just a little bit bigger. I can measure the size if you want to.
I didn’t tested the sersors yet. I hope the rubber cap doesn’t affect it to much. I post the results as soon as I had time to try them out.
I’ve purchased a ic with 6 schmitt triggers in there. I’ll post a link to the datasheet when I come home. I think this ic together with some pull resistors will do the job. BTW: I might be the same solution that u used in your force sensor demo.
Can’t wait to see what comes out your shop again!
Thanks for the tip. I’m looking for a solution to keep it compatible with the standard phoenix. I might make the terrain adaption in a separate version or a separate module. But I didn’t figured that out yet
Very nice solution. Eventually I will have a similar solution available on the shelf. I planned to make a 3mm slot in the round stock, but this looks good too. Very nicely done.
The only thing that can cause problems is if the bumpers adhesive sticks to the aluminum. If that happens it makes the sensor feel (edit: some) pressure even if the leg is up.
Once you get things set up to use the FSR as a ‘contact switch’ are you going to stop there, or will your next phase be to use the FSRs to sense pressure in order to equalize the load on each leg as it climbs over something? This is where I’d like to see thing go, you’ll are just way a head of me right now.
I know this will necessitate the use of an ADC, most likely on a daughter board, but that is pretty easy to facilitate. I will be glad to help with that aspect, if needed.
No the Atom Pro 28 has 8 analog inputs right on the board. Actually there is no need for any additional electronics beyond some resistors. You can use the analog inputs to “convert” to digital go/no go signals. Just need to set up a threshold value.
I know what you’re talking about. I run some first tests yesterday and it worked perfect! I tried all legs and the reacted perfectly. If the leg is lifted the value dropped I just need to find a suitable switching point.
I don’t have plans to do something like that. I’m wondering if the used pressure switches and servos are accurate enough to do something like that. I think that just having a contact switch will be enough to do the job. But please fill me in if I’ve got things wrong.
About the electronics, I didn’t used one of them. I’ve tested with the 8 analog inputs and they work perfect. I want to run some speed tests because i’m wondering if reading a analog input takes more time then reading a digital input. I’ll stick with the analog inputs if there isn’t a major difference.
If someone wants to try: the analog inputs are P0 to P3 and P16 to P19 (AX0 to AX3 on the BB2).
Reading the input is as simple as this:
value var word
Adin P0, value
BTW: The tibia length increased with 7mm (106mm -> 113mm)
This sounds great, I’ve just bought 2 meters of 8mm aluminium bolt . So when I find time for it I’ll try it.
I’m wondering where/when in the code are you going to read the sensors? At first I tried to read the sensors at the beginning of the main loop, but that wasn’t a good idea because it seemed like the leg wasn’t finished moving yet. If I remember correctly I had to wait for about 30 - 40 mS before I got the right result. I’ve to check what I did in my(your) code to verify.
That sounds good. Actually, I think making the tibia a bit longer is a good thing too. When it comes to the kinematics I think the correct tibia lengths should be the distance from tibia servo to the end of tibia - diameter of the tars divided by 2. Ex. If the diameter of tars tip is 10 mm and total length is 113mm, the correct kinematics length is 113 - (10/2) = 108 mm. For Phoenix this isn’t so very important, but I discovered this with my Felix when doing some tests. Just as you know it
It takes significantly longer to read the analog value than to read a digital input. however with some work you can have it read the analog values in the background. The AtomPro allows interrupts to be triggered when finished reading an analog value so you can set it to start reading and then move on to other things while waiting for that. When it’s done it will trigger the interrupt and you can grab the value. You can also setup the AtomPro to scan 4 of the analog channels constantly and just read the 4 analog registers whenever you need up to date info. You can setup the scanning mode to also trigger an int once all 4 analog pins have been read so you can cause the other 4 pins to be scanned ad infinitum.
I’m figuring out what the best solution should be. The idea is to move the leg a little bit down (5 or 10mm) and check for the pressure sensors. And repeat this step until the leg hit the ground. If the leg hits the ground I’ll switch to the next gait step. There might be a better way so any suggestions are welcome
I need to do the IK and read the 1 to 3 sensors every step. The number of sensors that I need to check depends on the gait type. The sensors are connect to P0 to P3 and P18 an P19. Is it also possible to group analog inputs P0, P2, P18 for a tripod gait. Or can only P0 to P3 and P16 to P19?
I want to run some tests to see how much time it takes to read the analog values. I could also convert the inputs to digital with some external electronics to win some time. I’ve got the needed electronics lying around already
Once again, all suggestions are more then welcome!
Oh believe me, the possibilities are almost endless. I’ve been working on this for some time now and I’ve still got more plans then time…
Good to see more Dutch guys around. Where are you located?
I have not played very much yet with the AtoD system, but as for the question on which pins can scanned with each other, the 3694 manual shows:
Channel Select 2 to 0
Select analog input channels.
When SCAN = 0 When SCAN = 1
000: AN0 000: AN0
001: AN1 001: AN0 and AN1
010: AN2 010: AN0 to AN2
011: AN3 011: AN0 to AN3
100: AN4 100: AN4
101: AN5 101: AN4 and AN5
110: AN6 110: AN4 to AN6
111: AN7 111: AN4 to AN7
For analog pins AN0-AN3 this is IO pins 0-3 and AN4-AN7 are on pins 16-19, however a couple of these pins are switched. I found this out awhile ago and updated the WIKI page: basicmicro.wikia.com/wiki/MBasic:_Module_Pinouts
Hopefully the tech writters will someday update the manual as well.
As for suggestions on the best approach, that is a good question. Looking at the H8 manual, it looks like to do a single sample in fast mode would take about 70 clocks and in slow mode about 132 clocks. As Nathan mentioned you could set this up to interrupt you or you can poll it with or without waiting in a hard loop. To me I guess the strategy may depend on absolutely accurate you need it to be. For example in many of the gaits you might be able to start up a simple scan mode at the beginning of the gait step and then during each loop of it, first see if the first conversion of it has completed and then simply read in the last value from the AtoD registers. Yes, they may be slightly out of date, but if I am reading this right, and worst simple case had to scan all 4 ADIN pins of a group, assuming fast mode, this would be completed in: 4*70 clocks in fast mode (I don’t think you need the accuracy of slow mode). So lets say
280 clocks at 16mhz is not a very long period of time even if you were grabbing the value from 279 clocks ago.
Now if you had to grab some values from both groups. You could set up an easy interrupt handler that would grab the values for the current group, setup the AtoD register to read in the values for the other group and continue and again simply have your program use the last values that were returned. Does this make sense?
Already found some nice features that I can add to my Robot. The more I search on the Internet the more features and possibilities I find. First want to build the robot and get it working with the PS2 controller. After that I’m going to make some plans for what I want to do next.
I in no way want to discourage your work on this! But it occurred to me that because Xan is only interested (at this stage) in detecting ground contact, not the amount of pressure applied, wouldn’t it be possible to just read the input as a high or a low with the pressure sensor connected as a voltage divider? Heck I’m just going to attempt to test it.
The next step is likely to need these analog values so please don’t take this the wrong way.
One thing that may need to be worked out is finding the servo position at which the force sensor actuated. If the sensors actuate on the light side the bot might gradually sink down and wind up scooting along on its behind like a dog needing a worm treatment. If the servos are allowed to move at full speed, overshoot may occurr and the bot eventually walk around on its tiptoes.
I assume by gills, you probably have seen that a lot of Washington State is flooding. Luckily we are about 400’ up a hill made of mostly rock. So we are just fine.
I have not done any work on this, I simply was trying to answer his questions, especially if he was trying to do it with no additional hardware.
Actually I was going to write another paragraph that said something like, if it were me, I would be much more likely to convert the analog signal into a digital one, which is a lot easier to process and does not require you to use specific IO pins on the BAP…
. So when I find time for it I’ll try it.
