Unfortunately, I have not any background on motors dynamics, and torque specs are like black magic for me :-(
Having said this, thank you very much for the detail photo of the wheels. When I read your previous blog, I was wondering how the robot was going to deal with the "dragging" force of the remaining perpendicular wheel when moving in a straight line. Now the mechanism is crystal clear!!
Also to note you may need more power to get up a bump in the road and such. As to your motors, and torque in general. Torque is a simple force times a distance. So if you had a wheel that had a diameter that was ø1" and it took 2lbs of force to get it going, then you would need a motor with 2in*lbs of torque (sometimes also written as lbs*in). As to which motor is stronger, you will just need to do the unit conversions (actually cancel out the appropriate number of zeros) to get to N*m (Newton*meters).
@TonyTib: Next questions, how are you going to read the quadrature encoder?
Duane Benson is working on something that is so exciting it makes me want to squeal like a school girl. Duane and I will be writing about thsi in the not-so-distant future. Suffice it to say that it can be used to address this issue.
That encoder is just a US Digital E4P with the proper sizing for the motor's shaft. Another option if you need higher resolution is CUI's AMT encoders, which are <$30 at Digikey. With encoders, you have to match shaft size, mounting holes (or sticky tape), output format (quadrature / sin-cos / serial, single ended / differential, etc), and speed (which won't be an issue in your case). Most (all?) E4Ps are single ended quadrature output.
Next questions, how are you going to read the quadrature encoder? If you use interrupts, you'll be severely limited in speed. Another approach is to convert quadrature to up/down and connect to a counter. Also, there might be encoder input shields available. (Side note: another reason why the BeagleBone is so nice, it's got three quadrature encoder inputs built in)
While bowties are cool, I prefer more the pinstripe suit and a long overcoat. That aside to things of lesser importance, motors. DC electric motors are not that bad if you can get a few numbers out of them. The two main numbers that you will need are the Stall Torque and the No Load Speed. From there I plot that data on a chart with RPM on the x axis and torque on the y axis. The line between these two points represents the operating capacity of the motor. I generally try and keep the motor operating under 30% of max torque for continuous duty operations with brief moments in the 50% torque range. This will keep the motors happy. You can go higher if you have active cooling on the motor. With this in hand, you will then need to determine the amount of torque that is needed on each wheel. Because you are going to loose some efficiency in each wheel (most likely each of these wheels will be around 50% efficient in transmitting torque to the ground). This should give you some general sizing parameters. You would have to do some hand cranks assuming an acceleration rate how much torque would be needed to be delivered to the wheels, but this should give you a starting point.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.