Group Actions
Engagement
  • Author Author: Workshopshed
  • Date Created: Date Created
  • Views 887 views
  • Likes 3 likes
  • Comments 3 comments
Related
Recommended

Enchanted Objects Design Challenge - Testing

Workshopshed

There was a new version of the Arduino IDE, this week was not the best time to download it, so that was left until after the challenge.

 

Due to the modular nature of the design the boards and components could be tested as they were assembled. The boards were tested with modified versions of the example code that were originally used in the development. Prior to assembly the proto-shield was visually inspected for problems.

 

Test code and example: https://github.com/Workshopshed/EnchantedObjects/tree/master/Code/Examples

 

Powerup Test

All the plugged components were removed, the Arduino Yún and Protoshield were plugged together and it was powered up from the micro USB connector. This tests that there are no serious faults with either board. The LED light pipes were visually inspected and although there was a little bleeding of light between the outputs the overall result was acceptable.

 

Knock Knock and Top Panel Buttons

The knock knock sensor was plugged in and tested. This did not work as expected and was tracked to a dry joint on one of the power wires on the protoshield. Whilst trying to diagnose that issue a short sketch was written that output the button status to the serial port for monitoring and this was used to test the top panel buttons. A note was added to ensure connectors pushed on properly.

 

DHT22

This was not testing correctly, the MOSFET switch code was added to ensure that the DHT22 had power but I could not get this to read. I suspected the power switching so investigated that on it's own.

 

Mosfet Test

An LED was attached to the power connector normally used for the Infineon shield, it was a bit of a lashup as the cable was not very long. The problem was identified as a software issue, it was that the pin that turned on the MOSFET had been entered as 11 rather than 12. This was corrected in the test code and project code.

image

DHT22

Now that the MOSFET was working, the DHT22 tested correctly, the local temperature was 25.3°C and 43% relative humidity, very pleasant.

 

Mechanism test

The mechanism was tested to ensure that it moved freely and that the figures were running smoothly.

Servo

The servo was tested without the wire link to the mechanism using the slow sweep code.

 

Because the servo had been binding in the previous tests the springy connector was moved to the outer hole on the horn, this meant that the line to the mechanism was straighter eliminating that problem. However, the limits of the movement needed to be recalibrated from the original 50° - 100° values. A new sketch was created that used the top panel buttons to move the servo and output the angle, that allowed new values to be set.

 

 

Battery Test

The power was switched over to the battery to ensure that module was wired correct, that was all fine.

 

Infineon RGB test

image

The last shield was fitted and the wires added. The LED did not turn on and the code froze on LED.begin(), this was identified as the I2C pins connecting the protoshield headers as being open circuit. They were re-soldered and the LED worked.

 

 

Testing the code

RGB Shield

The RGB shield was behaving strangely. It was not flashing the LED correctly, it would go on and then stay off for ages, blink for a very short time and then stay off again. It was setting the intensity to zero that was confusing it. So the solution was to flash between brightness 1 and a larger value.

Serial Bridge

So that the state model and bridge could be tested, the code was scattered with messages to send back to the computer. The state model was working correctly but the weather returned was gibberish.

image

The SerialParse script was installed to send the request to the Linino. The weather-daemon was stopped and ran manually.

This returned the error.

 

ERR,[Errno 2] No such file or directory: '/etc/WeatherAPI.conf',3,10.00

 

The missing file was copied on and a new error appeared

OK!,Cloudy,3,26.00
Traceback (most recent call last):
  File "/mnt/sda1/Python/GetWeather.py", line 217, in <module>
    sys.exit(main())
  File "/mnt/sda1/Python/GetWeather.py", line 200, in main
    ser.write(w)
  File "/usr/lib/python2.7/site-packages/serial/serialposix.py", line 363, in write
    raise TypeError('expected str, got %s' % type(data))
TypeError: expected str, got <type 'unicode'>

 

This showed that the weather was being read correctly but the script was failing to send it back to bridge.

Googling showed that this was an encoding issue pyserial ser.write('string') TypeError in OS X | Python | Python

 

The change was made to the code and it correctly returned the weather to the Arduino.

 

        w = getWeather(l['humid'], l['temp'])
        print (w)              # Write to Console, for testing
        ser.write(w.encode('utf-8'))

 

The main code was still erroring, seemingly returning junk back to the Arduino. However, when it was left for a period, subsequent reads did successfully return the weather. This was repeatable.

 

A simple flush command was written to ensure that the serial buffer was cleared of any booting garbage before requesting the weather.

 

void CONTROLLER::flushserial() {
    while (_serial->available()) {
     int inByte = _serial->read();
   }
}

 

This did not help with the problem so a simple retry mechanism was added to the code.

image

That approach worked.

 

The code is not perfect but it's enough for a demo to be recorded.

 

I'm speculating that the handshaking line is going high too soon as it's fired off by a different process to the weather-daemon. Perhaps a resolution would be to toggle that GPIO line in the Python code instead.

 

Next: Enchanted Objects Design Challenge - And they all lived happily ever after

Parents Comment Children
No Data