Meccano MAX and Arduino

Tried different variations and delays but still not able to get any LED on the Face to light up. Shall try some more tomorrow and keep you informed.

mrdreambot-

If you are using the program I wrote to write to the array, the csFlag array is wrong - it needs to be

boolean csFlag[] = { true, true, true, true, false, true, false, true };

The original was written when I was assuming that the message was sent lsb-first.

I'm going to go back to my original data stream tests and try to translate them into the correct format - but it's easy to make a mistake. I've written an Excel app to see if I can tidy it up but need to double-check the results against the hardware. (unfortunately, I can't attach an Excel file).

For the default horizontal bar, the correct sequence is:
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xF7
0xE3
0xF5 - checksum marker
0x9E - checksum

mrdreambot -

I've modified the list of face array data - see the attachment. I haven't completed it but have gone through my face array designer and verified the hex bytes and checksums. Try these and see if they work.

LED array messages.pdf (93.9 KB)

BMD1103,

Thanks for spending time on your trip to do this. I am using my own code. Using your new data, it is still not working for me. I have the following:

FF FF F1 E6 E4 B1 7F 7F 7F 7F F1 E6 E4 F1 FF FF F5 2D
Checksum: 2D vs EC
F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 E3 F5 9E
Checksum: 9E vs 9E
Starting Max Tests...
FE FE FE FE 0 - 0
FE FE FE FE 1 - 0
FE FE FE FE 2 - 0
FE FE FE FE 3 - 0
FE FE FE FE 0 - FE
FC FE FE FE 1 - 0
FC FE FE FE 2 - 0
FC FE FE FE 3 - 0
FC FE FE FE 0 - 6
Last device has been discovered...
Face: Connected at position: 0
Device #0: Face
0 FF 0 FF 1 - 0
0 FF 0 FF 2 - 0
0 FF 0 FF 3 - 0
0 FF 0 FF 0 - 0
Face: Connected at position: 0
Device #0: Face
0 FF 0 FF 1 - 0
0 FF 0 FF 2 - 0
0 FF 0 FF 3 - 0
0 FF 0 FF 0 - 0

This first array is the happy face in your latest pdf. Note that the checksum is different from using the algorithm you posted. The second array is the horizontal line. The checksums agree.

The exchange is similar to your working observation. After sending 0 FF 0 FF x - y 2 times, I waited for 30 ms before sending the array MSB first. I tried sending them MSB first and LSB first and no LED was lit. Just to confirm, there is a start bit consisting of -132 +564 -140 ie, 132 us low, 564 us high and 140us low, which is followed by the values of the array. And there is no stop bit. Is this correct?

BTW, don't ruin your holidays working on this. It can wait. I can work on other aspects of the project.

No problem- it's too hot here (in the UK) to do a lot ( - and my room is on the shady side of the house).

I'm working with a timing base of 140 us. The "preamble" is 1 time interval LOW, 4 HIGH, and 1 LOW. Then each message bit is made up from 1 HIGH, 1 HIGH or LOW depending on the data bit, and 1 LOW. There is something at the end of the message but I have not been able to resolve it - it looks as if there is possibly some tri-stating going on as there is a definite exponential charge curve from LOW to HIGH, followed by a LOW. It looks as if I'll have to check that out when I get home.

Success at last! All that is missing is a stop bit. After the start sequence followed by the data, you still have to send a stop bit consisting 550 us high and then low.

You have to precede the sending of the image data by the data stream (00 ff 00 ff) every time you want to update the Face:

Face: Connected at position: 0
Device #0: Face
0 FF 0 FF 1 - 0
0 FF 0 FF 2 - 0
0 FF 0 FF 3 - 0
0 FF 0 FF 0 - 0
Displaying happy face...

Here are photos displaying a happy face and a sad face.

BTW, the check sums of the faces in your latest pdf are not correct. Have to replace them with the check sums calculated using your algorithm posted.

Thanks for your help! Enjoy your stay in the UK :wink:

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.