small Mecanum bot
Started working on this thing... Think will fit with P1 to start with...
https://www.amazon.com/dp/B09P2XR91Z?th=1
Drew it up in SolidWorks to help think about motor driver PCB...
Think will use two of these dual motor drivers:
https://www.amazon.com/dp/B0F43L7LLD?
Sparkfun also sells something that looks identical, in case these ones are bad for some reason...
Comments
Just ordered these long boards to drive the motors...
The idea is that everything is controlled by one QWIIC cable from Propeller PCB.
Uses two of these boards, one for each side. Each has a 16 I/O Expander and a dual motor driver (plus some extra stuff).
@Rayman
Howdy this is Martin.
I have been fascinated with the mechanum wheels. Bought several sets.
But the best place I found was Goodwill where I get r.c. cars and tear them down for parts.
Finally got around to working on this...
I2C I/O Expander is working.
Original plan was to generate the PWM for the motors using a pin in I/O Expander. But now, think this is too hard and may not work right...
Going to use P1 I/O for PWM instead now.
Did this form and fit test on the bot with the I/O Expander / Motor Driver boards.
Had to drill out some of the holes a bit to get M3 standoffs in. Only using 2 screws to connect these boards to robot. Using unsecured standoffs for the other two holes...
Just remembered that going to need some battery packs in there too, have to figure that one out still... Maybe 3D print some kind of holder...
Wish the name was "Mechanum", but guess it's "Mecanum", bad decision... Anyway, had to change the name of this thread and some folders to match the unfortunate reality...
Kool stuff. One of my next projects uses these wheels.
3D printed a corral for the battery pack and got it installed. This was a pain, should have installed these things BEFORE the motors, but oh well...
The plan was to use two of these battery packs, one for motors and other high current stuff, and one for the P1 and it's accessories.
But, guess going to try single supply. Not exactly sure how much power this pack will put out. Could be 3A and then all would be OK.
But, might be 900mA and things might get dicey...
Just noticed some microscopic text on the back of this supply that actually lists the current outputs of all the ports.
Seems it can actually do 3A from its usbc cable.
This is plenty of power for bot but still don’t know how will handle surges. Hope it works without having to add caps or other things…
3d Printed a fixture for holding the P1 Platform3 PCB at the top of the robot. Seems like it will work, just need to find some more screws...
Think the bones are all together now, just need to wire it up...
Just tested one of these low cost ultrasonic sensors, HC-SR04, gotten from Amazon...
Was using Google to look for code, but it made it's own, so tried it:
`PUB GetDistance(TrigPin, EchoPin) : Distance | time1, time2
'' Set TrigPin as output and EchoPin as input
dira[TrigPin]~~
dira[EchoPin]~
'' Send 10us Trigger Pulse
outa[TrigPin]~~
waitcnt(cnt + (clkfreq / 100_000)) '' ~10 microseconds
outa[TrigPin]~
'' Wait for Echo pulse to start
waitpeq(|< EchoPin, |< EchoPin, 0)
time1 := cnt
'' Wait for Echo pulse to end
waitpne(|< EchoPin, |< EchoPin, 0)
time2 := cnt
'' Calculate distance (Propeller counts / clock frequency * speed of sound / 2)
Distance := (time2 - time1) / (clkfreq / 1_000_000) / 58 ' Result in cm`
This didn't work at first because it stalled on the waitcnt.
Apparently, not long enough for Spin...
Just made it 10X longer and it worked.
The waitpxx instructions can stall the code if there is no pin transition. I was recently helping a friend read servo pulses from a receiver; we used at counter module to measure the return pulse in system ticks. If you can spare a counter, this code works (tested with HC-SR04), and has a timeout so a bad/out-of-range sensor doesn't cause the code to stick.
pub get_distance(tpin, epin) : usecs | tmout outa[tpin] := 1 ' trigger dira[tpin] := 1 outa[tpin] := 0 ctra := (%01000 << 26) | epin ' prep for pulse measure frqa := 1 phsa := 0 tmout := cnt + (clkfreq / 20) ' timeout after 50ms repeat if (ina[epin] == 1) ' wait for start quit if (cnt > tmout) return 0 repeat if (ina[epin] == 0) ' wait for end quit if (cnt > tmout) return 0 usecs := phsa / (clkfreq / 1_000_000) ' ticks to us if (usecs > 30_000) return 0Thanks @JonnyMac , did see that stall possibility but trust AI. Just kidding
I had to look up that waitpe to see if it had a timeout setting but doesn’t …
This may be a case where I’d like to do spin2 on p1 to get inline assembly….