Today we helped to set up the drive system sheet for Beck to fill in with the guide description. This involved dividing the steps into parts, and adding the images. The CAD models with the screws added helped tremendously to recount them all and add them too.
Drive sys instructions
Add in screws
Super bright lights kit wording
In addition to this, the super bright lights product description was added, and reviewed the arms sheet while starting on those pieces. The idea for the pieces will be to display it on a page where the 3D model is seen beside the quantity and print instruction. Additionally, we want to add in an AR quick look view, using the .usdz format. Step by step!
There was a bit of a problem being encountered after the Bowie rebuild. The XBees couldn’t communicate together. At first we were concerned this was going to be a hardware issue … that would be expensive parts. Alright, time to dive in to figuring out the bug.
First step was to see if any of the Xbees were receiving any data. Oh yeah, remember one of the previous issues with FTDI? This answer helped to fix the problem (from what we’ve seen, so far, until perhaps it will break again..).
Phew! What a relief! They were receiving data! Must be a code issue then. And wow, was it a code issue indeed. Meaning, there were sections of the code completely missing. The communications on that serial port were just vanished. What on earth! Well, anyway, we re-added it, and it was a huge relief to see the RSSI led from the XBee light up and to see Bowie move again, controlled by the Operator Interface.
Xbee comms are being seen through XCTU
Okay, the comms connection works, but no data is being seen.
This entire block of code was missing! How?! I’m fairly certain given this worked before that the code was there before!
Bowie has been disassembled since the summer when it was disassembled for the trip to France. With some of its pieces in different boxes, and sensors on different robots. It’s time to re-assemble a working Bowie again.
One of the pieces that broke was the front hinge, this was 3D printed and replaced.
The next piece that broke was a pad on the Teensy 3.6 lifted when trying to remove it. This is understandable, since the force of all the headers was much greater than that of a small copper footprint pour on some fibreglass. Alright, thanks to PJRC, we soldered new headers on and replaced this.
After that was fixing the Operator Interface on the green foam board Bowie. We ordered a replacement display, and all is displaying properly again.
There was a motor driver missing, but that was an easy find – it was in the prototype tree bot of course!
On the super bright lights board (version 1), some F headers are in place but the shrouding is missing. This was fixed by adding new F headers in place.
Alright, now it’s time to add everything back in place. All the electronics are in the main chassis now. Then, the air quality sensor on the back. Followed by the RPi on the top. We’re leaving the laser on the other side, because it’s still functional and cool. The claw is added too.
And now there is a working Bowie assembled again!
Added headers to new T3.6
This is what the alignment of the headers looked like
This is what broke, there should be 3 gold plated rectangles – not 2
New T3.6 installed
Comparing the lack of sand on the new one to the old one…
Display on the Operator Interface wasn’t working properly anymore
New one installed and working
It’s working again
Here’s a motor driver we were looking for
F header shrouding missing on the super bright lights board (v1.0)
To share the images that have a subject of interest, we created a page with a gallery on it. There’s a helpful description of the setup, robots used, and more. We decided to start simple first. In the future, we will need to have a better way of organising this so the tags can be seen. You can see the page here: Bowie Imagery.
Today we took a look at some of the old imagery data from Bowie from Summer 2018. There still needs to be work done on this, such as going through all the photos and tagging them if they include a subject of interest. There were two robots collecting imagery data that season. To start off, we worked on a dataset from OG Bowie’s groundcam: 09-08-2018_11-09 (2pm field test). This was Sept. 8th, 2018 – we had a Field Test, then had the beach closing party at Westboro Beach.
65 images were tagged out of a total of 2299. The items included bark, cigarette butts, feather, glass, leaf, misc, pebbles, plastic, seaweed, stick, stone, twig, and twigs.
Check out the video (not sure why the link doesn’t go properly, but the video is also embedded above)
Now we need to combine the test scripts we’ve been writing with Bowie API. The Bowie API takes a payload sent over serial from the microcontroller to the Raspberry Pi. It’s lightweight – just two key value pairs and some categories to help organise it. Here is how the messages are sent. Here is a look at the API, but it has since evolved since then.
Something we got stuck on is formatting the json dictionary to be proper for the updates. This is an example of what the json dictionary could look like. Eventually playing with the braces and quotes it worked out. The value has to be formatted as a string.
Integration time! Time to run the script on the Raspberry Pi. It was cool to boot up this Raspberry Pi again, it was entirely the same as Summer 2019. It will be fun to revisit some of those scripts at some point in time, but not right now. Installed the Python AWS IoT SDK.
Dun dun dun … and now a huge bug. We weren’t receiving serial data from the Teensy 3.6 to the Raspberry Pi. To debug it, we checked the function was being called in the Teensy. We made a simple test script that only prints out the data received on the Pi. We checked the port configuration and Serial was enabled. We rebooted it. The other thing to check was to verify the data was coming out of the Teensy. Tried to connect it to an FTDI adapter, but still the computer’s drivers issues were there, and rebooting was not an option to make it work. So it was searching endless forum posts to find any information or things to try…
The data is being received from Teensy to Pi!
Data on AWS IoT!
The bug ended up being the name of the serial port in the RPi code. Not entirely sure why this would have changed! But we had to change the serial port in the code from /dev/ttyAMA0 to /dev/ttyS0.