Modern CAN uses two formats referred to as CAN 2.0A and CAN 2.0B. These again can use at least two wired solutions. The one we discuss here is the high speed version using twisted pairs. Two newer relatives to CAN that require either a logic circuit or MCU with special port support are CAN FD and FlexRay.
CAN eXtended uses CAN 2.0B that often is called “extended frame”. CAN 2.0A uses a 11 bit arbitration field as ID, while CAN B add’s another 18 bits to this. CAN eXtended uses these 29 bits as follows:
- – 2 bit priority
- – 1 bit message direction
- – 8 bit device id
- – 10 bit stream id
- – 7 bit sequence number
- – 1 bit message continue indicator
As CAN only can carry 8 bytes on a single message we need to use several CAN messages for some of the larger easyIPC messages. To do so we take advantage of the 1 bit continue indicator. If cont = 0 we know this is a new message with a Message ID in the first byte of the payload. If we need to use several CAN messages as an envelope we add a envelope header and an envelope tail:
PID is 16 bit parameter ID. PID=0 is Envelope head, PID=1 is Envelope Tail. Envelope Head contain a 8 bit parameter indicating number of messages that at minimum is 2 and maximum 255. The first message will have cont flag =0, the rest will have cont flag =1 to indicate that this is not a message head.
Envelope Tail contain a 16 bit Envelope CRC which is the CRC for the total message payload.
Wow – I actually managed to order a Raspberry Pi Zero for 3.33 GBP. I have wanted one for months for testing, but declined to pay 50.- GBP or more on ebay. This was through one of the official distributors.
||Raspberry Pi Zero – Max 1 Pi Zero Per Customer!Pi Zero only
I purchased a Prusa i3 DIY kit from Hong Kong some time back. I assembled it and got it working, but have not used the printer much.
The first issue I had with it was that the board shorted and burned some lanes. I managed to fix that and even bought a spare control system (I actually have two spare systems). After that I discovered that I had an issue with the FTDI chip. The Scotish company making FTDI wanted to slam down on fake chips so they updated their drivers to actually damage fake chips.
I don’t like the fake chip industry, but neither do I believe that I as a customer should be responsible. I notice that CH340 chips have gained a lot of marked with makers after these incidents. The only way to know that I have a real chip is by ordering an expensive replacement from FTDI that will cost me the same as a new control system.
I use an Arduino Mega based control system with custom layout. It is quite nice and the firmware for it can be generated from on-line pages and downloaded. The PC front-end use a classic slicer and some custom G-code to operate the printer.
Running the printer I noticed that it sometimes switch on the nozzle fan and “forget” to switch it off. The effect is that the feeder stop feeding as temperature drop below 150 degrees and half my print ends up being a dry run. I have so far not found the configuration to control this better, so I am considering disconnecting the nozzle fan.
I have looked into the open source firmware code, but I am a bit reluctant to start making changes due to the state of the code. It reminds me a bit of a rat-nest to be honest. The challenge with those is that it requires a bit of time to get into and understand the code. I have actually considered re-writing the firmware, but again time. I have enough projects as it is – for now.
The main challenge is however to find a proper, free CAD program that is easy to learn and will allow me to create components that can be printed. One of my experiences is that you need to design the component for printing and you need to add the support mechanism manually. I have a few 3D parts around with support plastic so tightly integrated into the components that I can’t separate them, so I am not using the auto-generated crap anymore.
I need to find a solution to all this since I want to print legs for my spider on this 3D printer.
BasicPI Hat’s uses SPI in a full network with up to 8 Hat’s per Raspberry PI. Communication with a STM32 will clock at ca 15Mhz (Set on Raspberry PI). The protocol uses GPIO pin’s as chip select for critical messages, but will otherwise rely on each device to filter out it’s own messages on MOSI. This allows Raspberry PI to send on MOSI independent of what device that is sending on MISO.
This is possible since all information about sender and receiver is in the message header in the form of a hat/stream-id and MOSI can be filtered in software. The SPI Message format is illustrated below:
Chip Select on MISO is always done between two messages from a Hat. Raspberry PI will either detect a pad character meaning the Hat has nothing to send or wait for a message to complete if the device uses it’s time slot. Each active Hat have a 1ms time slot before Raspberry PI switch to another Hat. The device with Chip Select active will send a status message and either continue with messages in the queue or send pad’s if no messages is waiting.
The way this should work is that messages on MOSI are sent in the same sequence as they are inserted into the queue. Messages on MISO will be received as soon as the Hat receive chip select. ME will load balance chip select so that Hat’s with large MISO queues receive more sending time than Hat’s with empty queues.
HAL (Hardware Abstraction layer) is an interface between “normal” user modules and actual hardware. It makes hardware access easy and portable, it also gives us a layer where we can write optimized, hardware specific code if we need to. We will add more HAL classes as we go.
ETC (Elapsed Time Clock) count the time in ms and ys since the MPU was started. This is used for time differences by the RTOS itself and available all through code using the ETC::millis() or ETC::micros() functions.
GPIO is a class that provide access to a collection of pins. GPIO collections are declared in global space by the user and support logical pin grouping. This means that user modules can toggle pins with a given name even if their location is different from hardware to hardware. This allows the user to “wire” a board during initialization to preserve portability on modules that need pin Access.
More details on HAL classes can be found on Documentation->HAL in the menue as they are added.
The picture show a classic MPU9255 breakout board found on ebay for < 5.- GBP. MPU9255 provide both I2C and SPI interface and a total of 9 sensors (3 axis Gyro, Magnetometer and Accelerometer). In our case we will use the SPI ports Connected to STM32.
I am not sure if I should add a generic Sensor Hat or a specialised Spider Robot Hat (maybe both?).
The block diagram above outline the control system for the Spider Robot. The prototype was a mock up to test the basics of the concept and to proceed I want to make some changes:
- We need a proper CPU and I see no reason not to add in a Raspberry PI to execute AI logic. The servos and sensors are easily controlled by one of our BasicPI Hat’s, which leave us to design a PSU. I like the current 11.1V LIPO at 1.5AH. It should give several hours of operation.
- We need to add sensors. A few ultrasonic transceivers will enable us to check distance to surrounding objects, a MPU9255 adds Magnetometer, Accelerometer and Gyroscope, a couple of microphones adds hearing etc. Raspberry PI have digital camera option with possibilities for optical detection options. The rest is easily added to the IO processor.
- We need to work on the mechanics around the legs. I need a stronger servo on the inner arm and a better wiring solution to the legs. The problems detected was partly the servo breaking after continuous usage, plastic parts not taking the beating and wires worn out.
My first plan was to use a Raspberry PI Zero, but using a Raspberry PI 3 makes a lot more sense in this case. This adds the Wifi option directly.
This robot prototype uses a simple wooden box as body and 6 pan&tilt camera holders with a total of 12 servos to move around. The picture is a prototype to test the concept. I initially used a 5.2Ah LIPO but the total weight on the servos was getting a bit much, so I dropped down to a 1,2Ah LIPO.
The second issue was that I needed a 5V PSU for the Servos and testing with a 5A PSU I realized that peak load was above 10A. I used 4 x 50 cent DC-DC adaptors in parallel to get sufficient juice. This makes the PSU part quite big. I have been considering something smarter for PSU, but the 50 cent breakout boards are hard to compete with in cost (and weight).
The control system on this prototype is an Arduino Uno with a Servo Shield. It works ok for testing, but it add up to some size (and weight).
My main concern is however the mechanics around the Servo’s. These small 9g/12g Servos are not made for continuous usage and they tend to break down during testing.
Looking at my Rx breakout board I realize I need to add a LED for status. I don’t like wasting pins, but not having a Status led will be a pain.
This is the current revision 1.0 of the Rx breakout board. I am trying to find a decent way to display schematics, but the EDA I use is a bit limited in that respect. I am not going to mention what I use because I intend to change that to an open source EDA soon.