The Charge Connectors are already on the bottom of the Create, which wouldn't need to change.  I was suggesting they make the Dock with less of a Ramp so the front bumper on the Create, when loaded down, wouldn't hit it.  I was hoping to suggest an improvement to the Dock without a complete re-design of the Create (for the engineers sake).

RE: Charge contacts on the FRONT...  Works for me.  As long as the create, fully loaded with weight and rear wheel installed can dock and undock on its own, as advertised.

It appears the 5xx Dock has a much smaller Ramp, does the Create work on the 5xx dock?  Silly me, I've never tried it.  I'll give it a shot this evening...

UPDATE:  it docks nicely (hand pushed) and doesn't trip the bumper like the Create/Roomba dock does, but the new dock gives out different IR codes and the Create doesn't start charging when it sees it.  It does recognize it's IR signals though, so there's another Beacon

The Wheel Encoders need to be easier to clean considering how quickly they get dirty and really make the Create unreliable/unusable until they are cleaned again.  Also considering that cleaning them requires dissassembly which I expect voids the warranty.  That's just not right.  Or, was that the Plan?

fixing the wheel encoders is easy,all they need to do is seal them from dust and dirt,would be really good is to have connections to them to read the pulse on the 25 pin connector or add another 9 pin

i am working on some mods to wheel encoders and to the motors for higher torque

From what I can tell, when a Wheel Encoder get's dirty, the Create will usually make that wheel go too-fast because it's not getting "tick's" back from the encoder so it thinks the wheel isn't moving so it thinks it needs to ramp-up the power to that wheel.  I really like that.  It's nice not having to deal with that bit of detail to simply get the robot to go straight.

That said, it would be nice to be able to DISABLE that feature.  When the wheel encoder gets dirty, it kinda renders the robot unusable since it'll shoot off unexpectedly trying to compensate for a wheel that's "not moving".

Giving us individual wheel-encoder data in the sensor data as well as the ability to disable the auto-adjust feature (assuming there is one) would allow developers a lower level of control, which is nice for some applications, and expected by seasoned robotic developers.

I know that this thread has kind of died. (Last post over 2 years ago) 

From my reasearch it seems that there is a very big flaw in the firmware.  Apparently (and my experiments have supported) fractional distances (parts of a mm) are stored after the distance registers are cleared by reading the "distance" sensor.  However, the fractional degrees are apparently not.  This means that the robot must turn at least 1 degree every 15 milliseconds for any angle to be sent over the RS232 link.

In my experience differential drives with optical feedback are supposed to be more accurate when moving slower, not less.  I doubt that you ran out of internal memory so that leads me to believe that it is a relatively simple fix in the firmware. (The method is already used for distance so just transpose that algorithm to the angle).  

If anyone has found fixes to this issue please respond, or send me a pm.

Thanks

Paul R.

Purdue University.