Project Brainstorming
So, what do you all think about a processor choice? There are several options for ARM Processors. The Cortex-M series seems to be at the level at which we need our processor to be at, though I will need to read more on it and the other processors.
--Jason
We will use RTL 8181 SOC chip with two integrated Ethernet MACs and a WLAN 802.11b controller embedded onto a single chip.
This is Linux for This chip rtl8181.sourceforge.net/
RTL8181 Datasheet www.wireless.org.au/~jhecker/rtl8181/RTL8181_DataSheet_1.01.pdf
NXP SA2400ABE Transceiver datasheet pdf1.alldatasheet.com/datasheet-pdf/view/119823/PHILIPS/SA2400ABE.html
---Tan Pin Siang (HKUST)
I think we are leaning more toward connecting an ARM processor to a separate wifi module. We will be meeting on 9/23 to discuss this further. As we talked about in the teleconference, our teams don't have to have the same processors as long as we agree on the protocols. We will being doing some more research on the RTL8181, however.
--Jason
Hi everyone,
This could be one additional option for a processor http://www.ti.com/lsds/ti/microcontroller/arm_stellaris/overview.page?DCMP=Luminary&HQS=Other+OT+stellaris It's a TI microcontroller with an ARM Cortex M3 processor. I think that we may have looked at this during our meeting on Friday. It has embedded ethernet which would be nice. This is a development board for it as well - http://www.ti.com/tool/ek-lm3s6965
Also, we should probably agree on what the car should be able to do:
- Are we going to have both of the cars each host different web pages or will there be one central web page?
- video camera on board?
- other things such as sensors to check for imminent collisions?
-anything else that I didn't think of...
--Scott
Scott, that's what pretty much what I was thinking - the 9000 series has 8 PWM outputs, plenty for our needs
Many of the other processors in the M series have similar characteristics. What about a wireless module? There are a ton of options for that. That may be less important than the processor choice, as most wireless modules use a UART or something similar to communicate with the processor.
Something similar to http://www.ti.com/product/wl1271-tiwi, which has pre-integration with some ARM processor families may be of interst.
The processor family that you suggested has plenty of inputs for sensors, which I think would be a very appropriate add-on for the latency that will be involved.
The video camera on board is a very good question. That would take a lot of processing if went through our system. I'm not sure what I think about that at this point.
--Jason
Tan Pin Siang, Are you all set on your processor choice (RTL8181)? We are concerned about the support and availability, as in it is not available in the US. Our teams don't have to have the same processor, but it would be nice if we encounter problems.
--Jason
Hey guys, I haven't had a chance to look at the specs of all the different 9000 series processors, but from looking at them briefly i agree with you all that this looks like a good choice. Scott like you said, the embedded ethernet is really nice and i think the USB connection will be very handy too. As far as the questions that you brought up, i think for convenience sake that one central website would be ideal, but i don't think that it's necessary. I think it would be easier on us to just set up our own site. So i think a central website is desired, but not really a must have for us, at least for now. Maybe we can work on that once we get the majority of our goals reached. For the video camera on board, i'm not entirely sure how the processor works, but would we be able to just hook the webcam up to the on board USB? I can understand how if possible, that would take a lot of processing though. Maybe if that would take too much processing, we could just hook the webcam up to a computer and point it at an area that our vehicle can move and broadcast that on the website. That way we could see it moving, but the processor on the vehicle won't have to handle that load. And like you said Jason, since it has plenty of inputs, i don't see why we couldn't hook up some sensors on the vehicle. I'll keep looking into the processors and all that, but this is all i have for now.
--Chris
Everyone, please see the updated system diagram--> System Diagram This is obviously a simplification of the interconnections, but it at least presents our general ideas at this point. Please respond with your feedback.
--Jason
One topic brought up is the possibility of having a wireless camera on-board rather than integrating a camera through the wireless transceiver that will be receiving control information for the vehicle. If this is something that can be integrated into the website (as in we can feed that video to the site) I think this would be a nice alternative.
--Jason
This camera looks like it could be an option: http://foscam.us/foscam-fi8918w-wireless-ip-camera-11.html . I'm not sure how easy it would be to interface with our website though.
-Scott
I think we should use the MCBSTM32EXL develoment board. It has some things we don't need but it has the most online support and a ton of example programs. That camera may work if we can configure it to work with the site - also this one looks pretty good http://www.axis.com/products/cam_m1011w/index.htm
--Jason
Here are possible wireless transceivers:
http://www.sparkfun.com/categories/112
We just need to pick one or two to get and start prototyping.
http://www.raidentech.com/sptwo2aircta.html
^Vehicle Platform? haha
--Jason
The RN-XV WiFly Module on sparkfun looks like it might be a good option. It's really cheap and seems very easy to use. Love the vehicle platform haha. Did we pretty much decide that we're going to buy an existing car and take it apart? Also, that camera looks good. It looks as though it might be a bit easier to integrate into the website than the foscam one but I'm not really sure. I'm still working on getting the softaware for the development board on a VIP computer so we can start doing something.
--Scott
I agree about the WiFly. I don't remember who brought it up in one of our meetings, but i know that the WiFly module was mentioned and it looked pretty good then. And after checking it out on the link it still looks good to me. For the camera, i think the one that Jason linked to looks pretty good. Not to say the other one was bad, but like Scott said, it looks easier to integrate into the website. And i can't be sure just from looking at the pictures of it, but it kind of seems like, based on its shape and size, that that one would be easier to physically integrate onto the car as well. I'll check out some vehicle platforms before the meeting tomorrow, but that tank one is just too good haha, i mean, the gun actually works, i think we'd be wrong to not get it.
--Chris
I was checking out some RC cars this afternoon. This first site has a ton of different ones we could pick. http://www.hobbytron.com/RCCars.html A lot of the ones on there are pretty cheap so that's good and there's a good amount of them that are fairly big. But you guys can check that out too if you want because there are like 23 pages of cars so i know that i didn't get to them all.
Also, I think an RC truck might be a good idea so we can put what we need in the back and i found a good website for those too. http://www.nitrorcx.com/brrctr.html This site had more than just the trucks, but i linked it to the trucks. These are more expensive, $100-200, but they are also pretty big, ~16 inches with a ~11 inch wheelbase. The body is smaller than the wheelbase, but it's still pretty big. Plus they have super sweet paint jobs haha. However, it looks like a lot of these are four wheel drive, i know we were talking about a two wheel drive system, so i don't know we could mess with these to get them to work, or if that totally eliminates them as a possibility.
http://www.amainhobbies.com/index.php/cPath/1_44_1171/n/RC-Cars-Trucks-Kits-Electric-2wd-Short-Course-Kits This last site has a few trucks that look good. They are a little bit larger than the ones in the previous link, that makes them more expensive, but they are two wheel drive.
A lot of these sites have some pretty intense looking stuff on them though, i don't know what you guys were thinking, but would we need to go all out on something like one of these, or would something, as long as it's big enough, from radioshack or a store like that work just as well?
--Chris
PLEASE LOOK HERE FOR OUR CURRENT PERIPHERAL CHOICES: Vehicle platform, sensors, camera
--Jason
We really face some problems while trying to use the RTL8181 SOC. Therefore, we reconsider the choice of our MCU and Wifi Transceiver Module. We are using a router with Atheros SoC as our web server and wifi module. A web server program will run in this router, it will work like this: press the button on the web page >> server will run a cgi script >> output the serial data >> MCU. We are planning to add a webcam for video streaming on the website.
More information about the router and Openwrt OS. Fonera Router It cost about 14USD in China. Our MCU choice is 16-bit Freescale Microcontroller S12XS128. Thanks --Tan Pin Siang
Tan Pin,
Is the camera going to be mounted on the vehicle or near the vehicle connected to your router?
--Jason
The camera and the router will be on the vehicle. The router act as a client and receive Wifi signal from a wireless access point(another router).
--Tan Pin Siang
We have decided on a tank vehicle platform. It has a lot of space to mount boards without being visible. Our plan is to use our PCB to communicate with a wireless transceiver to connect to the site. The camera will be connected to another development board that converts raw data to compressed data to transmit. This means we will have two connections, two IP numbers, one for the control data and one for the video feed. The video feed will be in a web-friendly format to easily stream (mpeg,mjpeg,etc.). What we need to do is come up with a protocol for vehicle control. We have a tank, so forward is two motors going forward, turning is one going forward and one going backward, backward is both going backward. If we do not have a PWM controlling the motors this means that forward is all forward (but it really isn't fast), turning is only turning - meaning when you are going forward and hit right you will stop going forward and start spinning to the right, etc. We can change this if your vehicle choice is a rear wheel drive with servo steering. Either way, we need to come up with a system of control data, whether it be hex values sent to the vehicle or whatever. I would love to hear your opinions on this before the next video conference.
--Jason
We have 16-bit to sent, I will split it into BYTE1 and BYTE2
For BYTE1
1st - 4th bit is camera mount angle.
left mid right
0 127 255
5th - 8th bit is I/O control
For BYTE2
1st - 4th bit is vehicle speed.
reverse stop straight
0 127 255
5th bit is turn Left 0=don't turn; 1=turn
6th bit is turn Right 0=don't turn; 1=turn
7th-8th bit is turning speed (difference in speed of left and right wheel)
0 turn slowly -4 turn fast
any suggestion?
--Tan
Hey everyone,
We liked your protocol but we would like to revise the first byte so that we may incorporate more detailed commands to peripherals.
Here is what we came up with:
We think that this way we can leave more room for future peripheral additions that may require more that just turning them on and turning them off. Any comments or suggestions?
In terms of peripheral data being sent to the host site, a simple protocol that utilizes the two bytes could be one byte which identifies the sensor and the other byte sending the value of the sensor in an 8 bit resolution. For instance, a proximity sensor could be given the identity 00000001 and the micro could continue sending its value captured by the ADC to the controller to be displayed to the user.
Thanks
--Scott and Jason
