Notifications
Clear all
Topic starter
2019-07-01 4:41 am
Following from Bill’s DB1 idea I thought others might be interested in the approach I have decided to take.
Like Bill, I am using Actobotics structural hardware and the same motors and wheels, but I decided to use a single Arduino NANO as the Motor Controller and a Cytron MDD10A Dual-Channel Motor Driver Board. There will also be an Arduino MEGA which will manage motion and other tasks, but I am waiting to see where Bill goes with the Jetson Nano before deciding on the real intelligence part of the project.
My “Motor Controller” however does a lot more than just control the drive motors as it also handles all system interrupts and 4 fixed-position Ultrasonic Sensors.
Part of the challenging criteria I set for this project was to use a single data pin (NANO D2) for all interrupt requirements including some way of determining the exact source of the interrupt. I decided that I’d need 6 separate interrupts as follows –
1. Rotary Encoder (Left Motor)
2. Rotary Encoder (Right Motor)
3. Bumper Left (or Front)
4. Bumper Right (or Rear)
5. Emergency Stop (from Arduino MEGA or elsewhere)
6. Unassigned (Spare)
I scoured the Internet looking for solutions, but it appears many people have the same challenge but no real solution. Being an Electronics Technician I turned to a hardware solution as I do not believe this can be achieved in software without assigning (wasting) many data pins.
One of the problems is the individual interrupt sources could possibly generate a pulse that lasted from a couple of micro-seconds to tens of milli-seconds or even seconds, depending on the source. To overcome this my design uses a Retriggerable One-Shot Monostable Multivibrator using NAND Gates. The design allows me to set an exact interrupt pulse width no matter what the source.
Once the pulse is received, and the interrupt is generated, I needed a way to determine where it had come from. For this I turned to a 74HC165 8-Bit Parallel-Load Shift Register. This receives the fixed-length pulse from each interrupt source as a data input. The Arduino Interrupt Service Routine (ISR) reads the data from the 74HC165 and, based on the Bit position, determines the interrupt source. An advantage with this approach is that multiple simultaneous interrupts can occur and will be recognised because each Bit is dedicated to an individual interrupt source. This also ensures total accuracy which is particularly important for counting Rotary Encoder pulses.
In my case the design generates an interrupt pulse of 50uS for any interrupt source. The ISR first reads the source data (before the pulse collapses) and then decides what Flags/Variables need to be set for the main software loop to respond. The entire ISR takes less than 80uS.
I have included a circuit diagram which hopefully explains it more clearly.
The Ultrasonic Sensors are also each polled at around 10 times per second (when the robot is in motion) and the data is made available (via I2C) to the Arduino MEGA. Several automatic responses are handled by the Motor Controller in case of collision or close-calls, without needing any instruction from the Arduino MEGA.
Finally, you might also be interested to know that the entire robot was first designed in Sketchup, even before I ordered any parts. This has proven to be of enormous benefit as some of my original ideas wouldn’t have worked and Sketchup was able to show me this, but of most value is the ability to design parts (such as the Ultrasonic Housings) and then export and 3D-Print the parts, all with outstanding accuracy.
I have also included an early photo of my robot design and a link to a Sketchup video that will throw even more light on my design.
Well, I’ve rambled on for long enough, so I will leave it there. I am happy to answer any questions and if people are interested I might post more information as time goes by.
There are 10 types of people - those who understand Binary and those who don't
2019-07-01 1:00 pm
Shane, this is an amazing project, I'm very impressed!
I particularly like how you handled the multiple interrupts with the one-shots and the 74HC165, that's ingenious.
And the Sketchup video is very impressive, I wish I had done something like that for DB1. I used the old fashion whiteboard and paper to model the DB1 chassis and as a result, I have quite a few extra Actobotics pieces laying around that I currently have no use for!
I think it's safe to say that you'll get a lot of interest for CARA-2 here! I for one would be interested in seeing some of the code you used,
Welcome to the forum, looking forward to hearing more from you!
?
Bill
"Never trust a computer you can’t throw out a window." — Steve Wozniak
2019-07-01 1:43 pm
That is awesome, would you be able to put your work up on github. I would especially like to see the design files for the little plastic widgets.
When I went to college (pre CAD), a three semester series of courses on Orthogonal Projections was a prerequisite for the mechanical engineering program. Largely because of that, I ended up getting a degree in economics and putering in the shop became a hobby.
2019-07-01 2:00 pm
Very nice Shane.
2019-07-01 7:00 pm
Yes it's a very nice project Shane. The Sketchup drawing is very nice as well. Looking forward to hearing how Cara-2 continues to evolve, either physically or in terms of software evolution.
DroneBot Workshop Robotics Engineer
James
Topic starter
2019-07-01 9:58 pm
Hello Bill,
Thank you for your comments.
The idea of using Sketchup was more of a necessity as I am sourcing the Actobotics hardware directly from the US and each delivery to Australia costs US$100 (AU$145 - ouch!) so I wanted to get it right before ordering. As mentioned the benefits are many, including the ability to "virtually" add items to Cara-2 before committing to any purchase plus being able to 3D Print designed parts.
I also want to thank you for your DB1 project and your overall channel. It has given this old Tech some new inspiration and I very much look forward to where this will go.
Shane.
There are 10 types of people - those who understand Binary and those who don't
Topic starter
2019-07-01 10:09 pm
Yes, in time I will consider your Github suggestion as I believe it might help others.
I'm also considering designing a PCB for the Interrupt Circuit as it was very time-consuming to solder all those connections. I expect to use this design in future and a PCB would make it so much simpler.
Thanks for your suggestion and comments.
Shane.
There are 10 types of people - those who understand Binary and those who don't
2019-07-02 2:51 am
I'm also considering designing a PCB for the Interrupt Circuit as it was very time-consuming to solder all those connections. I expect to use this design in future and a PCB would make it so much simpler.
Yeah, perf board soldering can be quite tedious. It really cheap now to get PCBs made.
2019-07-03 5:25 am
Shane, I love that !
You people are making me feel like a first grader here
I was thinking about your bumpers, and how you could program them with only one interrupt, and it brought to mind a burglar alarm I once created for my TRS-80
What I did was install a reed switch and magnet to each window and a different resistor to the reed switch, then ran them all into the joystick port, so, if any window got opened, I would know it as well as which one it was. Of course, I kinda went overboard with the whole thing, and ran one to the door bell along with a speaker, then I started programming people's names, and... well, the point I'm trying to make is that I did a quick search and found an arduino circuit that reads different resistances that you might be able to connect to the bumpers. It probably wouldn't work for the sensors, but, it might work for the bumpers which would be a simple on/off with each bumper being a different resistor
2019-07-03 7:54 am
You people are making me feel like a first grader here.
That is the great thing about Robotics. There are so many different subjects to know that we are all first graders in at least a dozen of them:)
Topic starter
2019-07-04 6:08 am
I was thinking about your bumpers, and how you could program them with only one interrupt, and it brought to mind a burglar alarm I once created for my TRS-80
Yes, as they say, "Necessity is the mother of invention". It's amazing how we find work-arounds for system limitations!
I did consider a Voltage-Divider Circuit connected to one of the Analog Ports but discounted that fairly early in the piece as it wasn't reliable enough and to overcome that particular limitation created an exponential increase in the number of Resistors once you went beyond about 5 interrupts, plus it didn't provide any control over the Pulse-Width of the incoming Trigger Signal.
The hardware solution made it simple and my Interrupt Service Routine (ISR) now processes it all with just the following lines of code -
digitalWrite(coniPin_74HC165_LOAD_D3, LOW); // Transition from High to Low to trigger Loading of Data.
digitalWrite(coniPin_74HC165_LOAD_D3, HIGH); // Put back to High. (Ready for next ISR call).
byIncomingByte = SPI.transfer(0x00); // Use SPI to Read the 8-Bits of Data. (Will only be interested in the lower 6 Bits)
From here I can determine exactly which Device triggered the interrupt and either handle it immediately within the ISR or just allow the Main Loop to examine the "byIcommingByte" variable to see what has been triggered.
Shane.
There are 10 types of people - those who understand Binary and those who don't