Meccano MAX and Arduino

Great! - so the start sequence (140 us LOW, 560 us HIGH, 140 us LOW ) needs to be repeated at the end.

I've attached my Excel spreadsheet for you to try out and check - should make it easier to come up with other face patterns. It includes the checksum calc. as per my algorithm. Hopefully, its operation is explained adequately. I might play with it a bit more to make it less likely to be tampered with. The password is Max.

I want to use the display to show dynamic patterns, and that's going to be quite hard on processor resources, so I;m thinking of getting hold of a Nano and using it as a dedicated processor - pass the Nano a pattern and it takes care of the updates etc.

Anyway, thanks for your help and I hope to have a few things to show you once I get back to base.

MAX Led Array design.zip (11.5 KB)

No need for the initial LOW as the previous bit will always end with a LOW. After sending the 18-byte pattern, just send a 550 us HIGH following by LOW and don't have to time the LOW, just set it to LOW

Let's have a quick calculation (4 x (6 + 1) + 18) bytes x 10 bits/byte x 430 us/bit = 197,800 us or roughly 200 ms to update the face pattern. This means that you can update the face at a maximum of 5 times/sec. Limitation is the protocol and not the speed of your microprocessor. Owing to the weird protocol, certain exchanges using HIGH/LOW to represent 1/0 and others using duration of the HIGH pulse to indicate 1/0, you can't use a comm port. I have to use bit-banging tying up all microprocessor resources. This means, yes, if you have to update the Face at more than twice a sec, you'll have to use a dedicated processor or don't have any resources left for other control functions.

I shall experiment with your images and do a scrolling text message on the Face and see how it goes during the weekend.

The Face is the only device in the chain. Maybe we can optimise a bit by communicating to 1 device instead of 4, no response from non-existent devices anyway. This means that: ((6 + 1) + 18) bytes x 10 bits/byte x 430 us/bit = 107,500 us or roughly 110 ms meaning you can update the Face 9.3 times/sec. With this optimisation, you may not need a dedicated microcontroller for the face if you only need to update the Face 2 or 3 times a second.

Tested it. The proposed optimization does not work. The devices will not respond with the device type unless all 4 potential modules on the chain have been polled even though there is only 1 device on the chain.

Here is a video on scrolling text to the left at the fastest achievable speed on the MAX. It ties up all resources on the Arduino UNO.

Video too big to upload here. Watch it here instead: Scrolling Text on a Meccano MAX Robot Display - YouTube

I wondered about the need to address all 4 positions on the chain ...

I'll need to look at the data stream when the default pattern is being displayed - that seems to update quite quickly. I on't remember there being any serial transmissions between the graphics. I'm using Serial1 and INT3 on a Mega - the Nano also has a serial part apart from the USB so may be able to use that.

Sending of image from Arduino to Face is not using serial connection. Serial connection can be used like you did in the 6-byte polling of the devices. You are using interrupts to receive data back from the devices. And you can also use interrupts to send data to the Face. Your Arduino Mega has 4 serials which are sufficient to communicate with 4 chains in the MAX. I don't have a Mega, only an UNO and I have to use bit-banging to do all 3: polling devices, reading 1-byte responses and sending image to Face. Using serials and interrupts is more efficient in using resources but more difficult to program and debug. On the other hand, using bit-banging is not making efficient use of the resources.

Even with a Mega I think I'll need a dedicated processor for the LED array to get reasonable performance. The 140 us time interval isn't a lot to do much other processing for the array, and the 3 extra serial ports will allow a LED array and a maximum of 8 other devices. With 2 smart motors and the IR sensor (thanks for that - I don't know where I got the ultrasound idea from!) and 4 servos, the Mega is going to be a bit limited in what it can handle.

Never mind - at least we now know some of the limitations to be dealt with. I still think there is quite a bit of potential with the MAX, even with the mix of protocols. I think I'll have a look at what's involved in interfacing other devices to the protocol while I can't get my hands on the hardware.

Back to my optimization proposal: I found that initially you need to poll all devices until you get the Face to respond with a device type 6. After that, you can just poll the face by itself without polling the other 3 non-existent devices: 1, 2 and 3. The original savings calculation is still correct. The scrolling text is much smoother and twice as fast as before.

When you are back home having access to your hardware setup and oscilloscope/datascope, could you investigate the following please:

  1. IR - at one time, I was able to read the distance by issuing the 0xa0 command to the device and it responds with a value. And I can map the response using a formula to get the distance. I forgot which command has to precede that. But now, I cannot repeat it anymore. Command 0xa0 always returns the same value! Could you investigate what is the command sequence that gives a reliable reading? This one is not as important as the next item because I am planning to dump the MAX IR sensor and use more than 1 Sharp IR Sensors or Ultrasonic sensors in its place. It is such a simple sensor and I don't want the protocol overhead. The replacement sensors are easy to program using Arduino. And I am planning to add a camera to MAX to support computer vision control. Will talk more about this and remote control via WIFI later.

  2. The MAX motors - you identified the forward and backward commands. Are there other commands eg, controlling the speed, stop, etc. It appears that if you don't send them forward/backward commands for a while, the motors will stop. There seems to be several commands that stop the motor. I am using 0x30. I have to retest this.

Here is a video showing control of the Meccano MAX's Face, Motors and Servos using an Arduino UNO.

Submitted this project to hackaday.io. You may follow it to see my progress.

I've started to look at what's involved with the Nano for this application. One slight complication - the Nano doesn't have separate serial and monitor pots as I supposed, so I have to use Software Serial. I've modded the standard SS library to handle the 8N2 serial format and will try it out when I get home next week.

Or you can use your Nano and my Arduino Library for Meccano MAX which uses bit-banging instead of a com port to control MAX's face. The com port can then be used for the serial monitor. :wink:

And if you have time, have a look to see how to consistently get the IR sensor to report the distance (value returned by sensor and the distance is not a linear function but we can work it out). And also if there are commands to change the speed of the motors or keep the motors running without having to periodically send them a command.

Getting home sick?

Looks like I've got a month's worth of things to do when I get back ...

btw, I've just found GitHub - alexfrederiksen/MeccanoidForArduino: An improved library written in C++ to allow an Arduino to interface with the Meccanoid robot modules which might be worth looking into - haven't had a chance yet. Perhaps a joint effort may be in order.

I've seen it. You should look at my Arduino Library which is designed for the Meccano MAX instead of the Mecanoid. My library contains an example which exercises all devices except the IR sensor. Run it using your Nano and see how it works.

Hi mrdreambot,

I'm back in action.
My first activity has been to look at the signals at low level, and I've had a couple of surprises. I wrote an app for the Mega that just looks at the times between transitions on the signal line between the Meccabrain and the display module. I had to use the Mega as there is a LOT of data to be stored - upwards of 2000 items to get useful results.

I first ran the program looking at the start-up sequence - see the file. (I've deleted a lot of repeats to save space, but nothing of significance.) I can't see anywhere in there that is a true serial sequence of FF 00 FF 000 FF 00. There is also no serial transmission between the blank screen for startup and the default sequence. The different sequences for the various forms of the default follow on one from the other with no serial message between them, which is in line with what I see with the oscilloscope.

I also managed to get a printout for a change in display using the programming mode to go from LOL! to BYE. Again, there is no indication in the timing of any serial strings between the two.

I'm currently working on getting the Nano to go - so far I've managed to get a software serial port running with the 2 stop bits needed, and am looking at how to connect up the hardware.

LOL - BYE timimg.pdf (47.9 KB)

MAX face array startup timing.pdf (57.6 KB)

btw, your timings in #29 are based on 10 bits/bye. There are only 8 bits/byte in the face display. There are 6 'ticks' needed for the preamble: 18 8-bit bytes at 3 'ticks'/bit = 18 x 8 x 3 = 432 'ticks' for the display itself: and 4 more ticks needed for the stop bit - a total of 442 ticks. At 140 us /tick, that is 61 ms - about what I see on the oscilloscope display. The original has about 32 ms between successive writes to the display - so we should be able to get better than 10 updates/second.

Greater than 10 updates per seconds is good. What are the objectives of your project?

I can now report success with sending a display! Routine is attached.

It just sends the command string in the "configure" routine, then moves on to the wrtDisplay function. Without the diagnostic Serial.writes I'm getting less than 75 ms between updates - about 14 /sec.

I've set up the display bytes in an array so that I can scroll between them initially, to see if I can get some fairly rapid movement. The preamble, message, checksum flag and checksum are converted into bits in a bit array, which is then read on each timeout of the 140 us clock and sent to the output port.

This is running in a Mega at the moment - 5000 bytes of program memory, 938 bytes of dynamic memory. (I used the extra capabilities of the Mega to help with diagnostics - now to see if it'll run in a Nano ... )

At this stage, I'm exploring the capabilities of the system to see just what it can be made to do. Ultimately, I'd like to be able to add other non-Meccano sensors (using simpler interfaces) but use the servos and motors which are much easier to interface mechanically with the Meccano hardware. I have used my 3D printer to make up some servo mounts for RC-type servos which have the 1/2" mounting holes etc. I'm keeping an eye on TradeMe (NZ equivalent of eBay) for unwanted products so I can get some more of the smart servos etc.

Mega_write_display_working_0922.ino (9.91 KB)

Interesting. Which 3d printer would you recommended? I'd like to get one!