The way to handle things like overflows in real-world robots is to use real-wold units in the data. The lower level controls on each motor does the conversion. So the motor command is in radians per second and is in floating-point. The encoder reports its angle in radians, in floating-point.
This allows for easier software reuse and importantly makes it easy to swap in or out real hardware or simulation be redirecting were the data flows to. Maybe this "wastes bits" but development time and flexibility is what matters. Bits are cheap. You can examine most of the code used in real systems pretty much everything is on github these days. On Sat, Aug 22, 2020 at 10:03 AM N <nicklas.karlsso...@gmail.com> wrote: > > > > I thought of one bus per leg, but the Raspberry Pi only supports two > CAN > > > > busses and I think this is a common limitation not just on the Pi. > But > > > > I think we just figured out that one CAD FD can do 12 motors at 20 > Hz. > > > > > > It is more or less possible to configure mapping of dictionary into > PDOs sent in real so I expect values for more than one servo motor > > > could be sent in each message, maybe a few. If driver use internal > position control loop you could send back feedback at a lower rate, > > > looking into standard for CANopen lower numbered PDO have higher > priority and for each PDO number TPDO have higher priority > > > than RPDO while it may make sense to do the opposite if possible to > send back feedback at a lower rate. > > > > > > > > > Nicklas Karlsson > > > > > I think it all depends on what a motor requires. > > One byte for Enable/Direction/MotionType > > Four bytes for signed position > > Two bytes for Current/Torque/Velocity value? > > That leaves one byte Maybe a max Current Limit value? > > In Canopen standard there is. A 16 bit control word index 6040h usually > mapped to PDO sent periodically. A signed 32 bit position value 607Ah > usually mapped to PDO sent periodically. It is possible to map other > values. It might be possible to run drive without mapping to a periodic PDO > or a PDO sent more seldom but but are not certain it is allowed according > to standard and even if it is it might not work with the drive. Data sent > is normally at least 48 bit and payload is 64 bit so there will values for > one motor only in each message CAN-FD allow longer messages so here it > might be possible to squeeze in values for more than one drive in each > message. Then drives send back feedback each drive however neeed to send > one message but if drive have internal feedback and does not make complain, > bugs or other problems these values could be sent back more seldom. > > > A reply with 6 bytes might be position (4 bytes) and velocity(2 bytes) > > In canopen standard there is. A 16 status word index 6041h and 32 bit > signed integer position actual value which I think is the value usually > sent back but are not totally certain. > > > Both of those messages can't easily be packed into one shared with a > second motor. Not without going to perhaps signed relative position and > signed velocity. > > You are right they can't in CAN but maybe in CAN-FD but only for values > sent to drives and not feedback. > > > The problem with relative is it turns again into the equivalent of a > toggle message. Miss one and your position is wrong. So I would never do > that. > > Agree, almost. It is in most cases possible to use a 16 bit value and keep > track of the overflows provided it does not move to many counts in between > each time. It is not uncommon Micro controller have 16 bit encoder counter > so software need to keep track of overflows, not many rows of code but it > must be there and work perfect. > > > Nicklas Karlsson > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
